Koordinované zveřejňování zranitelností: jak provozovat program pro zveřejňování

Co je koordinované zveřejňování zranitelností?

Koordinované zveřejňování zranitelností (CVD) je postup, při kterém se nově nalezená zranitelnost řeší důvěrně mezi nálezcem a dodavatelem, dokud není k dispozici oprava nebo zmírnění, a teprve poté se zveřejní. CERT Guide to Coordinated Vulnerability Disclosure ho popisuje jako shromažďování informací od nálezců zranitelností, koordinaci sdílení těchto informací mezi příslušnými zúčastněnými stranami a zveřejnění zranitelnosti a jejích zmírnění, včetně zveřejnění pro veřejnost.

Pro dodavatele produktů má CVD dvě poloviny. Vnější polovinu, přijímání hlášení a zveřejňování bezpečnostních oznámení, pokrývá tato stránka. Vnitřní polovina, ověření, oprava a vydání, je životní cyklus správy zranitelností. Obě obvykle zajišťuje tým PSIRT.

CVD vs úplné zveřejnění vs bug bounty

	Koordinované zveřejnění	Úplné zveřejnění	Bug bounty
Co to je	Důvěrné hlášení, oprava a poté zveřejnění v dohodnutém termínu	Nálezce zveřejní podrobnosti okamžitě, s informováním dodavatele nebo bez něj	Program, který platí za platné nálezy
Kdo určuje načasování	Dodavatel a nálezce společně, někdy s koordinátorem	Nálezce	Podmínky programu, obvykle podle CVD
Riziko pro uživatele	Nejnižší: podrobnosti jsou veřejné, až existuje oprava nebo uplyne lhůta	Nejvyšší: útočníci se o ní dozvědí současně s obránci	Stejné jako u CVD
Náklady	Čas zaměstnanců na triáž a reakci	Neplánovaná krizová práce	Čas zaměstnanců plus odměny a často poplatky za platformu

Bug bounty není alternativou k programu pro zveřejňování zranitelností (VDP). Je to pobídka, která se k němu přidává. Každý dodavatel potřebuje způsob, jak může kdokoli nahlásit zranitelnost; bounty jen rozhoduje o tom, zda se za některá hlášení platí.

Co patří do politiky zveřejňování zranitelností

Politika zveřejňování zranitelností je veřejný dokument, který stanoví podmínky vašeho programu. ISO/IEC 29147, mezinárodní norma pro zveřejňování zranitelností, jeden prvek vyžaduje, a to preferovaný kontaktní mechanismus, a několik dalších doporučuje. Úplná politika pokrývá:

• Jak hlásit. Vyhrazenou adresu nebo webový formulář a způsob, jak bezpečně poslat citlivé podrobnosti, například zveřejněný šifrovací klíč.
• Co uvést. Dotčený produkt a verzi, kroky k reprodukci, dopad a jak kontaktovat oznamovatele.
• Rozsah. Které produkty, verze a služby jsou pokryty a které testovací metody jsou zakázané, například odepření služby nebo přístup k datům jiných uživatelů.
• Bezpečný přístav (safe harbor). Závazek nepodnikat právní kroky proti výzkumu v dobré víře, který se politikou řídí.
• Co mohou oznamovatelé očekávat. Kdy hlášení potvrdíte, jak je budete průběžně informovat a jaká je vaše cílová doba do opravy.
• Lhůta pro zveřejnění. Kdy se podrobnosti zveřejní a co se stane, když oprava trvá déle.
• Zveřejnění. Kde se bezpečnostní oznámení objevují a zda přidělujete CVE ID.
• Uznání. Zda a jak oznamovatele uvádíte a zda vyplácíte odměny (bounty).

Politiku držte stručnou a konkrétní. Oznamovatelé ji čtou, aby se rozhodli, zda je hlášení vám bezpečné a stojí za námahu.

Šablona politiky, kterou můžete převzít

Níže uvedená šablona vlastními slovy sleduje strukturu šablony politiky zveřejňování zranitelností, kterou vydala americká agentura Cybersecurity and Infrastructure Security Agency (CISA). Nahraďte části v hranatých závorkách a před zveřejněním nechte oddíl o oprávnění zkontrolovat svým právním týmem.

Politika zveřejňování zranitelností, [Společnost]
Poslední aktualizace: [datum]

Vítáme hlášení bezpečnostních zranitelností v našich produktech
a službách. Tato politika vysvětluje, jak zranitelnost nahlásit
a co od nás můžete očekávat.

Oprávnění
Pokud se v dobré víře snažíte tuto politiku dodržovat, považujeme
váš výzkum za oprávněný. Nebudeme proti vám kvůli němu podnikat ani
doporučovat právní kroky. Pokud proti vám třetí strana podnikne
právní kroky kvůli výzkumu, který se touto politikou řídil, dáme
najevo, že váš výzkum byl oprávněný.

Zásady
- Informujte nás co nejdříve poté, co najdete možnou zranitelnost.
- Vyhněte se porušení soukromí, narušení produkčních systémů
  a jakémukoli zničení nebo manipulaci s daty.
- Exploit používejte jen v rozsahu nutném k potvrzení zranitelnosti.
  Nepoužívejte ho k přístupu k datům ani k jejich vynesení,
  k udržování trvalého přístupu ani k přesunu do jiných systémů.
- Před zveřejněním nám dejte přiměřený čas na opravu.

Rozsah
V rozsahu: [produkty, verze a domény].
Mimo rozsah: odepření služby, sociální inženýrství, fyzické útoky
a [další výjimky].

Jak hlásit
Hlášení pošlete na [[email protected]] nebo přes [webový formulář].
Citlivé podrobnosti zašifrujte pomocí [odkaz na veřejný klíč].
Uveďte dotčený produkt a verzi, kroky k reprodukci a dopad.

Co můžete očekávat od nás
- Hlášení potvrdíme do [3] pracovních dnů.
- Potvrdíme, zda zranitelnost existuje, a budeme vás informovat až
  do její opravy, včetně všeho, co opravu zdržuje.
- Bezpečnostní oznámení zveřejníme [do 90 dnů] a pokud si to
  přejete, uvedeme vás jako nálezce.

security.txt: usnadněte nalezení svého kontaktu

Politika funguje jen tehdy, když ji výzkumníci najdou. RFC 9116, vydané v dubnu 2022, definuje security.txt, malý textový soubor poskytovaný na adrese /.well-known/security.txt přes HTTPS.

Contact: mailto:[email protected]
Expires: 2027-09-30T23:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security/disclosure-policy
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

• Povinné: Contact a Expires. RFC 9116 doporučuje platnost kratší než jeden rok dopředu, aby soubor nezastaral.
• Volitelné: Policy, Encryption, Acknowledgments, Preferred-Languages, Canonical a Hiring.
• Podpis: RFC doporučuje podpis OpenPGP v čitelném textu (cleartext) s nastaveným Canonical.

Před datem Expires si nastavte připomínku v kalendáři. Soubor s prošlou platností výzkumníkům říká, že ho nikdo nečte.

Embarga a lhůty pro zveřejnění

Embargo je období mezi hlášením a zveřejněním. Nejčastěji citovanou normou je politika Google Project Zero: dodavatelé mají 90 dnů na zpřístupnění opravy a podrobnosti se zveřejní 30 dnů po vydání opravy. Dodavatel, který potřebuje o něco víc času, může požádat o odklad, celkem nejvýše na 104 dnů. Pokud je zranitelnost už aktivně zneužívána, lhůta se zkracuje na 7 dnů.

Vaše vlastní politika může stanovit jiné podmínky a mnoho oznamovatelů je přijme. Důležité je, aby byla lhůta písemně stanovená, abyste oznamovatele průběžně informovali a abyste o prodloužení požádali před uplynutím lhůty, ne až po něm. Bezpečnostní oznámení zveřejněné včas a se zmírněním je lepší než mlčení.

CVE ID a CNA

Většina bezpečnostních oznámení nese ID CVE, aby je zákazníci i nástroje mohli spárovat. ID přidělují CVE Numbering Authorities (CNA), organizace oprávněné přidělovat ID v dohodnutém rozsahu. Mnoho dodavatelů softwaru je CNA pro své vlastní produkty, takže mohou ID přidělit a záznam zveřejnit podle vlastního harmonogramu. Pokud CNA nejste, přidělí ho CNA, jejíž rozsah pokrývá váš produkt, nebo CNA of Last Resort.

Koordinace více stran

Některé zranitelnosti zasahují mnoho dodavatelů najednou: chyba v široce používané knihovně, v protokolu nebo v čipu. Pak koordinátor pomáhá oslovit všechny dotčené dodavatele a dohodnout jedno datum zveřejnění.

• CERT/CC při Software Engineering Institute na Carnegie Mellon University koordinuje případy s více dodavateli a vydává průvodce CERT CVD.
• Národní týmy CSIRT v EU. Podle NIS2 určí každý členský stát CSIRT jako svého koordinátora CVD. Ten působí jako důvěryhodný prostředník mezi oznamovateli a dodavateli, vyjednává lhůty pro zveřejnění, řeší zranitelnosti, které se týkají více subjektů, a přijímá anonymní hlášení.
• Evropská databáze zranitelností agentury ENISA (EUVD), zřízená podle NIS2, je v provozu od května 2025 a zveřejňuje informace o veřejně známých zranitelnostech, včetně těch koordinovaných v rámci EU.

ISO/IEC 29147 pokrývá i případ, kdy jste obojím: dodavatelem, jehož produkt obsahuje zranitelnou komponentu jiného dodavatele, a musíte tedy hlásit směrem k němu a zároveň informovat vlastní zákazníky.

Když hlášení dorazí

1. Potvrďte přijetí v době, kterou slibuje vaše politika, a dejte oznamovateli sledovací ID.
2. Ověřte hlášení a ohodnoťte jeho závažnost.
3. Zjistěte, co je dotčeno: každý produkt, vydání a podporovanou větev, které obsahují zranitelný kód nebo komponentu.
4. Opravte a vydejte pro každou dotčenou větev a oznamovatele průběžně informujte.
5. Zveřejněte bezpečnostní oznámení s CVE ID, dotčenými verzemi, nápravou a uvedením nálezce. Strojově čitelná bezpečnostní oznámení používají CSAF a VEX zákazníkům sděluje, kterých produktů se zranitelnost netýká.

Celý proces včetně rolí, lhůt a metrik popisuje životní cyklus správy zranitelností.

Regulace dělá politiky CVD povinnými

Evropský Cyber Resilience Act vyžaduje, aby výrobci „zavedli a prosazovali politiku koordinovaného zveřejňování zranitelností“ a poskytli kontaktní adresu pro hlášení zranitelností, včetně zranitelností v komponentách třetích stran (příloha I, část II). Tyto povinnosti platí od 11. prosince 2027; viz co CRA požaduje. Čl. 21 odst. 2 písm. e) NIS2 uvádí řešení a zveřejňování zranitelností mezi bezpečnostními opatřeními, která musí přijmout základní a důležité subjekty. V USA nařídil Executive Order 14028 vypracování pokynů pro softwarový dodavatelský řetězec, které zahrnují účast v programu pro zveřejňování zranitelností.

Hlášení orgánům je samostatná povinnost a platí už nyní: od 11. září 2026 musí výrobce, který se dozví o aktivně zneužívané zranitelnosti ve svém produktu, do 24 hodin odeslat včasné varování prostřednictvím jednotné platformy pro podávání zpráv podle CRA (Single Reporting Platform). Celý harmonogram najdete v článku co CRA požaduje.

Hlášení je jen tak užitečné jako váš záznam o tom, co jste vydali

Každé hlášení vyvolá stejnou první otázku: která z našich vydání to obsahují? CRACI spouští vaše buildy GitHub Actions na vlastních runnerech a zaznamenává balíčky, které každý job skutečně stáhl, včetně tranzitivních závislostí, balíčků obnovených z cache CI a závislostí, které neuvádí žádný lockfile. Historie buildů ukazuje, které dřívější buildy obsahovaly zranitelnou závislost, takže víte, po jakou dobu jste byli zasaženi, a pohled inventáře ukazuje, které verze softwaru jsou nasazeny ve kterých produktech.

CRACI agreguje SBOM napříč buildy a repozitáři a monitorované SBOM průběžně znovu vyhodnocuje, takže jakmile se zveřejní zranitelnost v open source komponentě, uvidíte všechna místa, kde se vyskytuje. Bezpečnostní týmy provádějí triáž nálezů a posílají je týmům, které odpovídají za opravu, CRACI podporuje VEX a kontrolní brány politik mohou zablokovat buildy, které obsahují konkrétní CVE, jakmile je opravená. Viz sledování zranitelností.

Koordinované zveřejňování zranitelností: časté dotazy

Co je koordinované zveřejňování zranitelností?

Koordinované zveřejňování zranitelností (CVD) je postup, při kterém ten, kdo zranitelnost najde, ji důvěrně nahlásí dodavateli, dodavatel ji opraví a podrobnosti se zveřejní, jakmile se uživatelé mohou chránit, obvykle v termínu, na kterém se strany dohodnou. Koordinátoři jako CERT/CC nebo národní CSIRT vstupují do hry, když je dodavatel nedostupný nebo když je dotčeno více dodavatelů.

Jaký je rozdíl mezi VDP a bug bounty?

Program pro zveřejňování zranitelností (VDP) komukoli sděluje, jak zranitelnost nahlásit a co očekávat, aniž by se za nálezy platilo. Bug bounty platí výzkumníkům za platné nálezy, obvykle v definovaném rozsahu a často přes bounty platformu. Většina organizací začíná s VDP; bounty je volitelný doplněk navíc, ne náhrada.

Co by měla obsahovat politika zveřejňování zranitelností?

Minimálně to, jak hlásit: kontaktní adresu nebo formulář. ISO/IEC 29147 dále doporučuje uvést, co má hlášení obsahovat, jak bezpečně komunikovat, co a kdy mohou oznamovatelé očekávat, co je v rozsahu, jak zveřejňujete bezpečnostní oznámení a jak oznamovatele uvádíte. Většina politik přidává prohlášení o bezpečném přístavu (safe harbor) a lhůtu pro zveřejnění.

Co je security.txt?

security.txt je prostý textový soubor definovaný v RFC 9116 a poskytovaný na adrese /.well-known/security.txt. Říká výzkumníkům, kam hlásit zranitelnosti. Musí obsahovat pole Contact a Expires a může odkazovat na vaši politiku, šifrovací klíč a stránku s poděkováním.

Jak dlouhá bývá lhůta pro zveřejnění?

Nejčastěji citovanou normou je 90 dnů. Google Project Zero dává dodavatelům 90 dnů na zpřístupnění opravy a podrobnosti zveřejňuje 30 dnů po opravě, se 7denní lhůtou, pokud je zranitelnost už aktivně zneužívána. Vaše vlastní politika může stanovit jiné podmínky a koordinátoři je vyjednávají případ od případu.

Je politika koordinovaného zveřejňování zranitelností povinná?

Stále častěji ano. Evropský Cyber Resilience Act vyžaduje, aby výrobci produktů s digitálními prvky zavedli a prosazovali politiku CVD a poskytli kontaktní adresu pro hlášení, a NIS2 uvádí řešení a zveřejňování zranitelností mezi povinnými bezpečnostními opatřeními. Jinde ji často požadují zákazníci a pravidla zadávání zakázek.

Musím být CNA, abych získal CVE ID?

Ne. CVE Numbering Authority (CNA) přiděluje CVE ID ve svém vlastním rozsahu a mnoho dodavatelů se stává CNA pro své vlastní produkty. Pokud CNA nejste, může ID přidělit CNA, jejíž rozsah pokrývá váš produkt, nebo CNA of Last Resort.