Bug bounty

Čo sú bug bounty programy a prečo ich firmy spúšťajú

Bug bounty program je organizovaný rámec, v ktorom firma legálne a riadene pozýva nezávislých výskumníkov (ethical hackerov) hľadať bezpečnostné nedostatky a za kvalifikované nahlásenia vypláca odmeny. Cieľom je skrátiť čas do odhalenia, znížiť náklady na incidenty a systematicky zvyšovať úroveň zabezpečenia – doplnkovo k internému testovaniu, penetračným testom a bezpečnostným auditom. Tento článok vysvetľuje princípy fungovania, rozsah, pravidlá, právne a etické aspekty, rozhodovanie o odmenách, triáž, metriky i osvedčené postupy – bez technických exploitov.

Bug bounty vs. VDP: kde je hranica

• VDP (Vulnerability Disclosure Policy): otvorený kanál „nahlás chybu“ bez sľubu odmeny. Cieľom je mať bezpečný a legálny spôsob reportovania nálezov (security.txt, kontaktný formulár, PGP kľúč).
• Bug bounty: rozšírené VDP s finančnými odmenami, explicitným rozsahom, pravidlami testovania a SLA triáže. Očakáva sa aktívne, motivované testovanie vymedrených cieľov.
• Kedy začať: firmy často spúšťajú VDP ako minimum a po dozretí procesov (triáž, opravy, rozpočet) prechádzajú na private bounty (pozvánky) a neskôr public bounty.

Modely programov: private, public a managed

• Private: len pozvaní výskumníci; nižší šum, kontrolovaný prietok reportov, vhodné na štart.
• Public: otvorené pre každého; vyššia diverzita nálezov aj reportov, vyžaduje zrelú triáž a automatizáciu.
• Managed (cez platformu): externý partner (napr. triážny tím platformy) pomáha filtrovať duplikáty, overovať dopad a udržiavať kvalitu komunikácie.

Rozsah (scope): čo je „v hre“ a čo nie

Dobre definovaný rozsah je základ úspechu. Mal by byť konkrétny a stabilný, s možnosťou priebežnej aktualizácie:

• In-scope: domény/eTLD+1, mobilné aplikácie (platformy a verzie), API, cloudové prostredia, hardvér či IoT komponenty, ak sú pripravené na testovanie.
• Out-of-scope: služby tretích strán mimo kontroly, sociálne inžinierstvo, fyzické útoky, DoS/stres testy, credential stuffing na reálnych účtoch, manipulatívne nákupy s reálnymi škodami, prístup k osobným údajom mimo explicitného rámca.
• Citlivé zóny: produkčné dáta a PII – preferovaný je sandbox alebo „Safe Data Program“ (syntetické účty). Ak nie je k dispozícii, pravidlá musia prísne definovať limity interakcie s údajmi.

Pravidlá bezpečného testovania (do no harm)

• Minimálny dopad: zákaz nástrojov a techník spôsobujúcich výpadky či degradáciu služby; zákaz automatizovaného agresívneho skenu produkcie.
• Žiadne prezeranie reálnych PII: ak narazíte na citlivé údaje, je prípustný len dôkaz existencie bez čítania obsahu (napr. čiastočný redigovaný výstrelok) a okamžité prerušenie testu.
• Žiadne zdieľanie alebo zverejnenie mimo kanála programu; rešpektovanie embarga až do potvrdeného fixu a schválenej koordinovanej publikácie.

Safe harbor: právna ochrana pre výskumníkov

Kvalitný program obsahuje klauzulu „safe harbor“, ktorá deklaruje, že organizácia nebude podnikat právne kroky voči výskumníkovi, ktorý:

• konal v dobrej viere a držal sa pravidiel programu,
• prekročil len minimálne nutné hranice na dôkaz zraniteľnosti,
• nepracoval s dátami nad rámec demonštrácie, nič nemenil ani neexfiltroval,
• bezodkladne reportoval a nezverejnil bez koordinácie.

Safe harbor má často geografické a legislatívne špecifiká; firma by ho mala konzultovať s právnikom a jasne komunikovať v politike.

Životný cyklus reportu: od nahlásenia po odmenu

1. Podanie: výskumník odošle report cez platformu/portál. Povinné polia: cieľ, opis problému, dopad, krok-za-krokom reprodukcia, dôkazy (redigované).
2. Triáž: tím overí reprodukovateľnosť, vplyv, rozsah a duplicitnosť. Výsledkom je kategorizácia a predbežná závažnosť.
3. Potvrdenie: report sa označí ako triaged/confirmed alebo sa zamietne (out-of-scope, info, nedohľadateľné, duplikát).
4. Remediácia: vlastník systému (product/engineer) dostane ticket s detailmi, odporúčaním a SLA podľa závažnosti.
5. Overenie fixu: re-test; ak je oprava účinná, report sa uzavrie (resolved/fixed).
6. Odmena: výpočet podľa zásad (viď nižšie), odoslanie platby; prípadne „hall of fame“ zápis.
7. Koordinovaná publikácia (voliteľná): po oprave môže byť publikovaný technický blog/poradné oznámenie.

Závažnosť a priorita: ako sa rozhoduje bez emócií

• CVSS (štandardizované skórovanie dopadu a pravdepodobnosti) a interné P1–P5 priority. Príklady:
  • P1/Kritická: diaľkový neautentizovaný prístup k citlivým údajom alebo prevzatie účtu na produkcii.
  • P2/Vysoká: eskalácia oprávnení po prihlásení, obchádzka silných bezpečnostných kontrol.
  • P3/Stredná: obmedzené úniky metaúdajov, business logic issue s čiastočným dopadom.
  • P4/Nízka: informačné nálezy bez priameho dopadu, malé chyby konfigurácie.
• Kritériá dopadu: rozsah (koľko používateľov/dát), ľahkosť zneužitia, prítomnosť mitigácií, viditeľnosť a reálnosť scenára.

Odmeňovanie: transparentné zásady a tabuľky

Program by mal vopred zverejniť bounty table a pravidlá eskalácie odmien:

• Rozpätia odmien podľa priority (napr. P1: 3 000–10 000 €, P2: 1 000–3 000 €, P3: 200–1 000 €, P4: do 200 € alebo „kudos“).
• Multiplikátory za reťazenie viacerých oblastí alebo cross-tenant dopad; de-multiplikátory pri okrajových podmienkach a ťažko replikovateľných situáciách.
• Duplikáty: odmena patrí prvému kvalifikovanému reportu; neskoršie reporty sú „duplicate“ bez bounty, no môžu dostať thanks.
• Platby a dane: metóda (SEPA, platforma, krypto podľa politiky), KYC/daňové náležitosti a termíny vyplatenia.

Kvalitatívna latka reportu: čo očakáva triáž

• Reprodukcia: jasné, minimálne kroky, žiadne „magické“ premenné; uvedenie testovacieho účtu a prostredia.
• Dopad: popis, čo konkrétne môže útočník urobiť a v akom rozsahu (nie iba „je to zlé“).
• Dôkazy: redigované snímky, logy a identifikátory transakcií; žiadne zbytočné exfiltrácie či čítanie reálnych PII.
• Minimalizmus: len toľko interakcie so systémom, aby sa potvrdila existencia problému; žiadne škody.

Komunikácia s výskumníkom: etika a profesionalita

• Priebežné aktualizácie: potvrdenie prijatia, stav triáže, ETA na fix/overenie; vyhnúť sa tichu.
• Jazyk: vecný, bez defenzívnosti; uznanie prínosu aj pri zamietnutí, ak report posúva pochopenie rizika.
• Spätná väzba: pri „informational“ reportoch vysvetliť, čo chýbalo, a ako zvýšiť šancu na kvalifikáciu nabudúce.

Organizačná pripravenosť: čo mať hotové pred štartom

• Proces opráv (kto má vlastniť fix, aké SLA, ako sa deployuje záplata).
• Ownership map cieľov v scope (product owners, SRE, security champions).
• Bezpečné testovacie účty, seedované dáta bez PII a logovanie prístupov výskumníkov.
• Incident playbook pre prípad, že test odhalí kritický otvor v produkcii.
• Rozpočet a schvaľovanie odmien (financie, právne, DPO), spolu s daňovou a účtovnou evidenciou.

Právne a regulačné aspekty

• Zmluvné podmienky programu (T&C): definícia povoleného testovania, safe harbor, IP práva k reportom, pravidlá publikácie.
• Ochrana osobných údajov: minimalizácia práce s PII; ak k nej dôjde, výskumník je poučený, ako okamžite zastaviť a nahlásiť.
• Exportné a sektorové regulácie: niektoré krajiny/odvetvia môžu mať obmedzenia pre odmeny alebo výskumníkov z určitých jurisdikcií.

Meranie úspechu: KPI a metriky zrelosti

• MTTT/MTTR: čas do triáže a čas do opravy.
• Podiel kritických nálezov z externého programu vs. interné detekcie.
• Duplicity a šum: percento zamietnutých reportov; trend po úprave rozsahu a pravidiel.
• Úspora proti incidentom: odhad nákladov ušetrených vďaka odhaleným chybám pred ich zneužitím.
• Retencia výskumníkov: koľko kvalitných reportérov sa vracia a aká je ich spokojnosť s komunikáciou a odmeňovaním.

Najčastejšie chyby firiem a ako sa im vyhnúť

• Nejasný scope: vedie k frustrujúcim zamietnutiam a k strate dôvery. Riešenie: precízny zoznam cieľov, verzovanie a changelog.
• Ticho po reporte: výskumníci migrujú inde. Riešenie: SLA na odpoveď (napr. 72 h), automatizované potvrdenia.
• Nekonzistentné odmeny: pocit nespravodlivosti. Riešenie: tabuľky odmien a interný review board.
• Závislosť len na bounty: program nie je náhradou bezpečného SDLC, code review a testov; je doplnkom.

Najčastejšie chyby výskumníkov a profesionálne štandardy

• Agresívne testovanie (DoS, bruteforce) bez povolenia – vedie k blokáciám. Držte sa pravidla minimálneho dopadu.
• Nedostatočné reporty bez jasnej reprodukcie – znižujú šance na kvalifikáciu.
• Predčasné zverejnenie – poškodzuje používateľov aj reputáciu, môže viesť k diskvalifikácii.

Programová ekonómia: náklady, prínosy a plánovanie rozpočtu

• Fixné náklady: interný triážny tím, tooling, čas inžinierov na opravy.
• Premenné náklady: odmeny a poplatky platformám.
• ROI: porovnanie s nákladmi na tradičné testy a s rizikom incidentov; pravidelné vyhodnocovanie a úprava bounty tabuliek.

Koordinovaná zverejnenosť (CVD) a publikácie

• Embargo a termíny: typicky 60–120 dní podľa zložitosti fixu a koordinácie s tretími stranami.
• Obsah: zamerať sa na poučenia a zmeny procesov; vyhnúť sa detailným exploit krokom, ak to nie je nevyhnutné pre pochopenie rizika.

Checklist pre spustenie bug bounty programu

• Máme VDP a funkčný kanál nahlasovania?
• Je definovaný scope (in/out), kontakty, safe harbor a pravidlá testovania?
• Existuje triážny proces, SLA a vlastníci oprav?
• Máme bounty tabuľku, rozpočet a mechanizmus platieb?
• Pripravené testovacie účty, syntetické dáta a logging?
• Interný review board pre spory o závažnosť a odmeny?

Checklist pre výskumníkov pred podaním reportu

• Je cieľ v scope a dodržiavam pravidlá (žiadny DoS, žiadne PII)?
• Mám reprodukčné kroky a minimálny dôkaz dopadu?
• Sú dôkazy redigované a neobsahujú citlivé dáta?
• Komunikujem výhradne cez oficiálny kanál a rešpektujem embargo?

FAQ: stručné odpovede

• Potrebujem špeciálnu licenciu na testovanie? Nie, ak testujete len podľa pravidiel programu a v jeho rozsahu. Safe harbor to má explicitne pokryť.
• Môžem žiadať odmenu pred potvrdením? Nie. Odmena sa schvaľuje po triáži a potvrdení dopadu.
• Čo ak je chybný komponent tretích strán? Program zvyčajne smeruje report k vendorovi; odmena sa rieši podľa politiky (často goodwill odmena).

Bug bounty ako trvalý proces zlepšovania

Bug bounty programy fungujú najlepšie, keď sú súčasťou širšej bezpečnostnej stratégie: bezpečný SDLC, threat modeling, automatizované testy, interná edukácia a incident response. Transparentné pravidlá, kvalitná komunikácia, férové odmeny a dôraz na do no harm vytvárajú prostredie, v ktorom výskumníci pomáhajú chrániť používateľov a firma získava robustnejšiu, overiteľnú bezpečnosť – bez potreby siahať po technických exploit príručkách.