Co jsou bug bounty programy a proč je firmy spouštějí
Bug bounty program je organizovaný rámec, ve kterém firma legálně a řízeně zve nezávislé výzkumníky (ethical hackery) k hledání bezpečnostních nedostatků a za kvalifikovaná hlášení vyplácí odměny. Cílem je zkrátit čas do odhalení, snížit náklady na incidenty a systematicky zvyšovat úroveň zabezpečení – doplňkově k interním testům, penetračním testům a bezpečnostním auditům. Tento článek vysvětluje principy fungování, rozsah, pravidla, právní a etické aspekty, rozhodování o odměnách, triáž, metriky i osvědčené postupy – bez technických exploitů.
Bug bounty vs. VDP: kde je hranice
- VDP (Vulnerability Disclosure Policy): otevřený kanál „nahlas chybu“ bez slibu odměny. Cílem je mít bezpečný a legální způsob reportování nálezů (security.txt, kontaktní formulář, PGP klíč).
- Bug bounty: rozšířené VDP s finančními odměnami, explicitním rozsahem, pravidly testování a SLA triáže. Očekává se aktivní, motivované testování vymezených cílů.
- Kdy začít: firmy často spouštějí VDP jako minimum a po dozrání procesů (triáž, opravy, rozpočet) přecházejí na private bounty (pozvánky) a později public bounty.
Modely programů: private, public a managed
- Private: jen pozvaní výzkumníci; nižší šum, kontrolovaný tok reportů, vhodné na start.
- Public: otevřené pro každého; vyšší diverzita nálezů i reportů, vyžaduje zralou triáž a automatizaci.
- Managed (přes platformu): externí partner (např. triážní tým platformy) pomáhá filtrovat duplikáty, ověřovat dopad a udržovat kvalitu komunikace.
Rozsah (scope): co je „v hře“ a co ne
Dobře definovaný rozsah je základ úspěchu. Měl by být konkrétní a stabilní, s možností průběžné aktualizace:
- In-scope: domény/eTLD+1, mobilní aplikace (platformy a verze), API, cloudová prostředí, hardware či IoT komponenty, pokud jsou připraveny k testování.
- Out-of-scope: služby třetích stran mimo kontrolu, sociální inženýrství, fyzické útoky, DoS/stres testy, credential stuffing na reálných účtech, manipulativní nákupy s reálnými škodami, přístup k osobním údajům mimo explicitní rámec.
- Citlivé zóny: produkční data a PII – preferovaný je sandbox nebo „Safe Data Program“ (syntetické účty). Pokud není k dispozici, pravidla musí přísně definovat limity interakce s daty.
Pravidla bezpečného testování (do no harm)
- Minimální dopad: zákaz nástrojů a technik způsobujících výpadky či degradaci služby; zákaz automatizovaného agresivního skenování produkce.
- Žádné prohlížení reálných PII: pokud narazíte na citlivá data, je přípustný jen důkaz existence bez čtení obsahu (např. částečný redigovaný výstřižek) a okamžité přerušení testu.
- Žádné sdílení nebo zveřejnění mimo kanál programu; respektování embarga až do potvrzené opravy a schválené koordinované publikace.
Safe harbor: právní ochrana pro výzkumníky
Kvalitní program obsahuje klauzuli „safe harbor“, která deklaruje, že organizace nebude podnikat právní kroky vůči výzkumníkovi, který:
- jednal v dobré víře a držel se pravidel programu,
- překročil jen minimální nutné hranice k doložení zranitelnosti,
- nepracoval s daty nad rámec demonstrace, nic neměnil ani neexfiltroval,
- bezodkladně reportoval a nezveřejnil bez koordinace.
Safe harbor často obsahuje geografické a legislativní specifika; firma by jej měla konzultovat s právníkem a jasně komunikovat v politice.
Životní cyklus reportu: od nahlášení po odměnu
- Podání: výzkumník odešle report přes platformu/portál. Povinná pole: cíl, popis problému, dopad, krok-za-krokem reprodukce, důkazy (redigované).
- Triáž: tým ověří reprodukovatelnost, vliv, rozsah a duplicitnost. Výsledkem je kategorizace a předběžná závažnost.
- Potvrzení: report se označí jako triaged/confirmed nebo se zamítne (out-of-scope, info, nedohledatelné, duplikát).
- Remediace: vlastník systému (produkt/engineer) dostane ticket s detaily, doporučením a SLA podle závažnosti.
- Ověření opravy: re-test; pokud je oprava účinná, report se uzavře (resolved/fixed).
- Odměna: výpočet podle pravidel (viz níže), odeslání platby; případně zápis do „hall of fame“.
- Koordinovaná publikace (volitelná): po opravě může být publikován technický blog či poradné oznámení.
Závažnost a priorita: jak se rozhoduje bez emocí
- CVSS (standardizované skórování dopadu a pravděpodobnosti) a interní P1–P5 priority. Příklady:
- P1/Kritická: dálkový neautentizovaný přístup k citlivým údajům nebo převzetí účtu v produkci.
- P2/Vysoká: eskalace oprávnění po přihlášení, obcházení silných bezpečnostních kontrol.
- P3/Střední: omezené úniky metaúdajů, business logic issue s částečným dopadem.
- P4/Nízká: informační nálezy bez přímého dopadu, malé chyby konfigurace.
- Kritéria dopadu: rozsah (kolik uživatelů/dat), snadnost zneužití, přítomnost mitigací, viditelnost a reálnost scénáře.
Odměňování: transparentní zásady a tabulky
Program by měl předem zveřejnit bounty table a pravidla eskalace odměn:
- Rozpětí odměn podle priority (např. P1: 3 000–10 000 €, P2: 1 000–3 000 €, P3: 200–1 000 €, P4: do 200 € nebo „kudos“).
- Multiplikátory za řetězení více oblastí nebo cross-tenant dopad; de-multiplikátory u okrajových podmínek a těžko replikovatelných situací.
- Duplikáty: odměna patří prvnímu kvalifikovanému reportu; pozdější reporty jsou „duplicate“ bez bounty, ale mohou obdržet thanks.
- Platby a daně: metoda (SEPA, platforma, krypto podle politiky), KYC/daňové náležitosti a lhůty vyplácení.
Kvalitativní laťka reportu: co očekává triáž
- Reprodukce: jasné, minimální kroky, žádné „magické“ proměnné; uvedení testovacího účtu a prostředí.
- Dopad: popis, co konkrétně může útočník udělat a v jakém rozsahu (nejen „je to špatné“).
- Důkazy: redigované snímky, logy a identifikátory transakcí; žádné zbytečné exfiltrace či čtení reálných PII.
- Minimalismus: jen tolik interakce se systémem, aby se potvrdila existence problému; žádné škody.
Komunikace s výzkumníkem: etika a profesionalita
- Průběžné aktualizace: potvrzení přijetí, stav triáže, ETA na opravu/ověření; vyhýbat se mlčení.
- Jazyk: věcný, bez defenzivity; uznání přínosu i při zamítnutí, pokud report posunuje porozumění rizika.
- Zpětná vazba: u „informational“ reportů vysvětlit, co chybělo a jak zvýšit šanci na kvalifikaci příště.
Organizační připravenost: co mít hotové před startem
- Proces oprav (kdo má vlastnit fix, jaká SLA, jak se deployuje záplata).
- Ownership map cílů v scope (product owners, SRE, security champions).
- Bezpečné testovací účty, seedovaná data bez PII a logování přístupů výzkumníků.
- Incident playbook pro případ, že test odhalí kritickou díru v produkci.
- Rozpočet a schvalování odměn (finance, právní, DPO), spolu s daňovou a účetní evidencí.
Právní a regulační aspekty
- Smluvní podmínky programu (T&C): definice povoleného testování, safe harbor, IP práva k reportům, pravidla publikace.
- Ochrana osobních údajů: minimalizace práce s PII; pokud k ní dojde, výzkumník je instruován, jak okamžitě zastavit a nahlásit.
- Exportní a sektorové regulace: některé země/odvětví mohou mít omezení pro odměny nebo výzkumníky z určitých jurisdikcí.
Měření úspěchu: KPI a metriky zralosti
- MTTT/MTTR: čas do triáže a čas do opravy.
- Podíl kritických nálezů z externího programu vs. interní detekce.
- Duplicity a šum: procento zamítnutých reportů; trend po úpravě rozsahu a pravidel.
- Úspora proti incidentům: odhad nákladů ušetřených díky odhaleným chybám před jejich zneužitím.
- Retence výzkumníků: kolik kvalitních reportérů se vrací a jaká je jejich spokojenost s komunikací a odměňováním.
Nejčastější chyby firem a jak se jim vyhnout
- Nejasný scope: vede k frustrujícím zamítnutím a ztrátě důvěry. Řešení: precizní seznam cílů, verzování a changelog.
- Mlčení po reportu: výzkumníci migrují jinam. Řešení: SLA na odpověď (např. 72 hod), automatizované potvrzení.
- Nekonzistentní odměny: pocit nespravedlnosti. Řešení: tabulky odměn a interní review board.
- Závislost pouze na bounty: program není náhradou bezpečného SDLC, code review a testů; je doplňkem.
Nejčastější chyby výzkumníků a profesionální standardy
- Agresivní testování (DoS, bruteforce) bez povolení – vede k blokacím. Držte se pravidla minimálního dopadu.
- Nedostatečné reporty bez jasné reprodukce – snižují šance na kvalifikaci.
- Předčasné zveřejnění – poškozuje uživatele i reputaci, může vést k diskvalifikaci.
Programová ekonomie: náklady, přínosy a plánování rozpočtu
- Fixní náklady: interní triážní tým, tooling, čas inženýrů na opravy.
- Proměnné náklady: odměny a poplatky platformám.
- ROI: srovnání s náklady na tradiční testy a s rizikem incidentů; pravidelné vyhodnocování a úprava bounty tabulek.
Koordinovaná zveřejněnost (CVD) a publikace
- Embargo a termíny: typicky 60–120 dní podle složitosti opravy a koordinace s třetími stranami.
- Obsah: zaměřit se na poučení a změny procesů; vyhnout se detailním exploit krokům, pokud není nezbytné k pochopení rizika.
Checklist pro spuštění bug bounty programu
- Máme VDP a funkční kanál hlášení?
- Je definován scope (in/out), kontakty, safe harbor a pravidla testování?
- Existuje triážní proces, SLA a vlastníci oprav?
- Máme bounty tabulku, rozpočet a mechanismus plateb?
- Jsou připraveny testovací účty, syntetická data a logging?
- Interní review board pro spory o závažnost a odměny?
Checklist pro výzkumníky před podáním reportu
- Je cíl v scope a dodržuji pravidla (žádný DoS, žádné PII)?
- Mám reprodukční kroky a minimální důkaz dopadu?
- Jsou důkazy redigované a neobsahují citlivá data?
- Komunikuji výhradně přes oficiální kanál a respektuji embargo?
FAQ: stručné odpovědi
- Potřebuji speciální licenci na testování? Ne, pokud testujete
