CSAF: Common Security Advisory Framework pro strojově čitelná bezpečnostní upozornění

Co je CSAF?

Common Security Advisory Framework (CSAF) je standard technické komise OASIS CSAF Technical Committee pro zápis bezpečnostních upozornění jako strukturovaného JSON a jejich distribuci tak, aby je bylo možné automaticky najít a zpracovat. Dokument CSAF uvádí, které produkty a verze zranitelnost ovlivňuje, které nejsou dotčeny, které jsou opraveny a co by uživatelé měli udělat.

Aktuální verzí je CSAF 2.0, schválená jako OASIS Standard 18. listopadu 2022. CSAF 2.1 je na cestě: její čtvrtý Committee Specification Draft prošel veřejným připomínkováním od 23. října do 6. listopadu 2026 a zatím nejde o schválený standard.

Upozornění píší dodavatelé, obvykle jejich tým pro reakci na bezpečnostní incidenty produktů (PSIRT), a koordinátoři, například národní CERT. Jak se tyto dva druhy týmů liší, najdete v článku PSIRT vs CSIRT.

Od CVRF k CSAF

CSAF vyrostl z Common Vulnerability Reporting Framework (CVRF), formátu v XML. ICASI vydala CVRF 1.1 v květnu 2012 a OASIS vydala CVRF 1.2 v září 2017. CSAF 2.0 ho nahradil formátem JSON, schématem JSON pro validaci, profily pro různé druhy dokumentů a pravidly pro distribuci a vyhledávání upozornění. Specifikace stále definuje, jak převést dokumenty CVRF na CSAF.

Struktura dokumentu CSAF

Dokument CSAF má tři části nejvyšší úrovně:

• document: metadata. Pět vlastností je povinných: kategorie (kterým profilem se dokument řídí), verze CSAF, vydavatel, název a sledovací údaje. Sledovací údaje obsahují ID upozornění, jeho stav, verzi, datum prvního a aktuálního vydání a historii revizí.
• product_tree: každý produkt, který dokument zmiňuje, obvykle jako větve od dodavatele přes název produktu k verzi, s ID produktů, na která se odkazuje zbytek dokumentu. Produkty lze identifikovat také pomocí package URL (purl), CPE nebo hashů.
• vulnerabilities: jedna položka pro každou zranitelnost s jejím CVE nebo jinými ID, poznámkami, skóre a stavem produktů, který řadí ID produktů do seznamů: known_affected, known_not_affected, fixed, first_affected, last_affected, first_fixed, recommended a under_investigation. Nápravy se kategorizují jako vendor_fix, workaround, mitigation, no_fix_planned nebo none_available.

Pět profilů CSAF

V CSAF jako celku je povinných jen málo polí. Profily určují, která pole musí mít daný druh dokumentu, a hodnota /document/category říká, kterým profilem se dokument řídí:

Profil	Hodnota kategorie	Použití
CSAF Base	csaf_base	Minimum, které splňuje každý dokument CSAF; univerzální profil pro dokumenty, které se nehodí do žádného jiného
Reakce na bezpečnostní incident	csaf_security_incident_response	Reakce na bezpečnostní průnik nebo incident, včetně incidentu v jiné organizaci
Informativní upozornění	csaf_informational_advisory	Problémy, které nejsou zranitelnostmi, například nebezpečná chybná konfigurace
Bezpečnostní upozornění	csaf_security_advisory	Zranitelnosti a jejich nápravy; klasické upozornění dodavatele
VEX	csaf_vex	Prohlášení, zda a proč je či není každý produkt zranitelností dotčen

Bezpečnostní upozornění musí mít strom produktů, zranitelnosti, poznámky ke každé zranitelnosti a stav produktů. Profil VEX jde dál: každý produkt uvedený jako known_not_affected potřebuje prohlášení o dopadu, buď jako strojově čitelný příznak, nebo jako text, a každý produkt known_affected potřebuje nápravu, která uživatelům řekne, co dělat.

CSAF VEX

VEX (Vulnerability Exploitability eXchange) uživatelům říká, které zranitelnosti v komponentách produktu produkt skutečně ovlivňují. CSAF VEX je jedním ze tří běžných formátů VEX vedle OpenVEX a CycloneDX VEX. Jeho příznaky používají stejných pět zdůvodnění nedotčenosti jako požadavky CISA na VEX, například component_not_present a vulnerable_code_not_in_execute_path. Trivy i Grype CSAF VEX čtou a nálezy, které označuje jako nedotčené, vypouštějí. Red Hat například zveřejňuje své dokumenty CSAF VEX v samostatném adresáři vedle svých upozornění CSAF.

Jak se upozornění CSAF distribuují

Standardní formát pomůže jen tehdy, když nástroje dokumenty najdou. Oddíl 7 CSAF 2.0 stanoví jak:

• provider-metadata.json popisuje vydavatele a umístění jeho upozornění. Nástroje ho najdou alespoň jednou ze tří cest: pole CSAF v souboru security.txt domény, well-known URL /.well-known/csaf/provider-metadata.json nebo název DNS csaf.data.security. před doménou.
• Upozornění se uvádějí buď ve složkách podle roku se souborem index.txt a changes.csv, nebo ve feedech ROLIE, poskytovaných přes TLS bez přesměrování.
• Každý soubor je pojmenován podle svého sledovacího ID. Upozornění TLP:WHITE musí být volně přístupná a upozornění TLP:AMBER nebo TLP:RED musí být za řízením přístupu.
• Integrita: důvěryhodní poskytovatelé přidávají ke každému dokumentu hash a podpis OpenPGP a zveřejňují svůj veřejný klíč.

Standard definuje pět rolí, které si distribuující strana může nárokovat:

Role	Co dělá
CSAF publisher	Zveřejňuje platné dokumenty CSAF, pouze vlastním jménem, přes TLS
CSAF provider	Publisher, který navíc nabízí provider-metadata.json, způsob objevení a adresář nebo ROLIE feed
CSAF trusted provider	Provider, který navíc zveřejňuje hashe, podpisy OpenPGP a svůj veřejný klíč
CSAF lister	Vede seznam míst, kde najít dokumenty CSAF jiných stran, aniž by je kopíroval
CSAF aggregator	Zrcadlí dokumenty alespoň dvou nezávislých vydávajících stran na jednom místě, s hashi a podpisy

Odběratelé jednou nastaví stahovací nástroj a pak stahují nová upozornění od všech poskytovatelů, na nichž jejich produkty závisejí, místo aby sledovali desítky webových stránek dodavatelů.

Kdo CSAF zveřejňuje

CSAF je nejrozšířenější mezi dodavateli pro průmysl, podniky a infrastrukturu a mezi národními CERT:

• Cisco poskytuje provider-metadata.json na své well-known URL pro CSAF.
• Siemens ProductCERT zveřejňuje svá upozornění jako ROLIE feed CSAF.
• Red Hat zveřejňuje upozornění CSAF a samostatně dokumenty CSAF VEX.
• CERT-Bund úřadu BSI, německý národní CERT, zveřejňuje feedy CSAF se svými upozorněními.
• CISA v září 2023 oznámila, že její upozornění ICS jsou doplněna dokumenty CSAF, zpětně až do roku 2017, a vyzvala dodavatele, aby standard přijali.

Dodavatelé pro průmysl, kteří pracují podle IEC 62443-4-1, potřebují proces pro informování uživatelů o bezpečnostních problémech ve svých produktech a strojově čitelná upozornění jsou běžným způsobem, jak splnit očekávání jejich zákazníků.

Nástroje pro CSAF

• Secvisogram je webový editor dokumentů CSAF od BSI s formulářovým editorem, editorem JSON, náhledem HTML a validací.
• Nástroje csaf od BSI a Intevation (gocsaf/csaf, často nazývané csaf_distribution) implementují trusted provider, checker, aggregator a downloader, přičemž verze pro CSAF 2.1 je ve vývoji.
• Skenery jako Trivy a Grype zpracovávají dokumenty CSAF VEX.

Přechod z webových stránek a RSS feedů na CSAF

Většina dodavatelů přechází na CSAF v pěti krocích: dá do pořádku seznam produktů a verzí, zvolí potřebnou roli CSAF, zveřejní soubory pro objevení a feed, upozornění generuje místo ručního psaní a nakonec přidá VEX a archiv. Přechod na CSAF většinou není o JSON. Jde o to mít seznam produktů, na který mohou vaše upozornění odkazovat, a cestu, po které je stroje najdou.

Kde většina dodavatelů začíná

Obvyklé uspořádání je stránka HTML pro každé upozornění, někdy PDF, RSS nebo Atom feed a e-mailová konference. Lidé si to přečíst mohou. Nástroj na straně zákazníka s tím ale moc nesvede: chybějí stabilní identifikátory produktů, stav dotčeno/nedotčeno pro každou verzi, způsob, jak objevit všechna upozornění dodavatele, i kontrola integrity. BSI popisuje stejný problém: buď existuje RSS feed, který lze odebírat, nebo se nová upozornění objevují jen na webu, který musí někdo navštívit. Každá část starého uspořádání má svůj protějšek v CSAF:

Původní prvek	Ekvivalent v CSAF
Webová stránka s upozorněním	Dokument CSAF s profilem csaf_security_advisory
„Dotčené verze“ v textu	product_tree a product_status
RSS feed	ROLIE feed nebo adresář se soubory index.txt a changes.csv
Stránka „Odebírat“	provider-metadata.json a způsob objevení
Podpis PDF, nebo žádný	Hashe a podpisy OpenPGP (trusted provider)
Text „Naposledy aktualizováno“	tracking a revision_history

RSS feed je doručovací kanál; CSAF je formát. FIRST PSIRT Services Framework uvádí „webový dokument, RSS feed nebo odběr“ jako způsoby doručení upozornění a zvlášť doporučuje zveřejňovat upozornění „ve strojově čitelném formátu, jako je Common Security Advisory Framework (CSAF)“, aby je zákazníci mohli zpracovávat automatizovaně. Feed si můžete ponechat.

Krok 1: nejdřív dejte do pořádku seznam produktů

Na product_tree migrace selhávají. Ještě před prvním dokumentem CSAF potřebujete kanonický seznam produktů a verzí, který odpovídá tomu, co zákazníci vidí na svých zařízeních a ve svých inventářích aktiv, ideálně s CPE nebo package URL pro každou položku. Je to tentýž seznam, který PSIRT potřebuje, aby věděl, kterých verzí se CVE týká, a proto škálování PSIRT začíná inventářem po verzích. Větev vede od dodavatele přes produktovou řadu a produkt k verzi:

"product_tree": {
  "branches": [{
    "category": "vendor",
    "name": "Example Networks",
    "branches": [{
      "category": "product_family",
      "name": "EX Series",
      "branches": [{
        "category": "product_name",
        "name": "EX-200",
        "branches": [{
          "category": "product_version",
          "name": "4.2.1",
          "product": {
            "product_id": "EX200-4.2.1",
            "name": "Example Networks EX-200 4.2.1",
            "product_identification_helper": {
              "cpe": "cpe:2.3:o:example:ex-200_firmware:4.2.1:*:*:*:*:*:*:*"
            }
          }
        }]
      }]
    }]
  }]
}

U produktu, který obsahuje open source komponenty, upozornění jmenuje verze vašeho produktu. Inventář komponent, o který se rozhodnutí opírá, tedy které verze obsahují zranitelnou knihovnu, je SBOM (co je SBOM?).

Krok 2: zvolte svou roli

Pět rolí je popsáno výše. Pro dodavatele se volba zužuje na tři:

Role	Zvolte ji, když	Co přidává
CSAF publisher	Na svém webu potřebujete jen platné dokumenty CSAF, jako výchozí bod	Platné dokumenty přes TLS; nástroje je samy objevit nedokážou
CSAF provider	Zákazníci by si měli vaše upozornění stahovat automaticky: realistické minimum	provider-metadata.json, způsob objevení a adresář nebo ROLIE feed
CSAF trusted provider	Zákazníci nebo úřady očekávají podepsaná upozornění	Hashe, podpisy OpenPGP a zveřejněný veřejný klíč

Lister a aggregator jsou určeny koordinátorům, ne dodavatelům. Nástroje gocsaf/csaf zahrnují csaf_provider, který implementuje trusted provider, a csaf_checker, který testuje nastavení poskytovatele vůči oddílu 7 standardu. Checker spusťte dřív, než feed ohlásíte.

Krok 3: objevení a feed

• Zveřejněte provider-metadata.json v /.well-known/csaf/ na své doméně.
• Odkažte na něj ze security.txt. RFC 9116 definuje tento soubor a požadavek 8 CSAF 2.0 přidává pole CSAF:, jehož URL musí začínat https://.

Contact: mailto:[email protected]
Expires: 2027-11-11T00:00:00.000Z
# Our security advisories
CSAF: https://www.example.com/.well-known/csaf/provider-metadata.json

• Nahraďte RSS feed ROLIE feedem, nebo provozujte oba. ROLIE (Resource-Oriented Lightweight Information Exchange, RFC 8322) je postaven na Atomu, takže je přirozeným nástupcem feedu, který už zveřejňujete. Funguje i adresář se soubory index.txt a changes.csv.
• Každý feed označte úrovní TLP. CSAF 2.0 používá štítky TLP 1.0 WHITE, GREEN, AMBER a RED. TLP 2.0 od FIRST, platný od srpna 2022, používá CLEAR, GREEN, AMBER a RED, s AMBER+STRICT jako rozšířením AMBER, a návrhy CSAF 2.1 tyto štítky přebírají. Veřejná upozornění jsou v CSAF 2.0 TLP:WHITE.

Krok 4: generujte, nepište ručně

Nová upozornění generujte ze záznamu, který už o každé zranitelnosti vedete, z případu ve svém trackeru nebo v databázi zranitelností, a každé před vydáním ověřte vůči schématu a testům ve standardu. Secvisogram se hodí pro malý objem a pro úpravy. Stránku pro lidi vykreslujte ze stejného dokumentu JSON, aby si webová stránka a soubor CSAF nikdy neodporovaly. Revize aktualizuje tracking/version a revision_history ve stejném dokumentu; nový dokument nezveřejňujete.

Krok 5: VEX a archiv

Prohlášení o nedotčenosti zveřejňujte jako CSAF VEX pro CVE, na která se zákazníci ptají nejčastěji, protože každé z nich zastaví opakovaný dotaz. Starší upozornění doplňte až nakonec, počínaje produkty, které jsou stále v podpoře. Pokud jsou vaše stará upozornění v CVRF, pokrývají je pravidla převodu ze specifikace.

CSAF 2.0, nebo 2.1?

Zveřejňujte 2.0 hned. Je to schválený OASIS Standard a vyšel také jako mezinárodní norma ISO/IEC 20153:2025. CSAF 2.1 je stále Committee Specification Draft: čtvrtý návrh byl schválen 21. října 2026 a jeho veřejné připomínkování skončilo 6. listopadu 2026. Nástroje se připravují: Secvisogram už dokumenty 2.1 upravuje, zatímco podpora 2.1 v nástrojích gocsaf/csaf se vyvíjí pro jejich příští hlavní verzi.

Co očekávají CRA a BSI

• Cyber Resilience Act CSAF nejmenuje. Čl. 14 odst. 8 vyžaduje, aby výrobce, který se dozví o aktivně zneužívané zranitelnosti nebo závažném incidentu, informoval dotčené uživatele, a případně všechny uživatele, „případně ve strukturovaném, strojově čitelném formátu, který lze snadno automaticky zpracovat“. Příloha I část II požaduje, aby výrobci po zpřístupnění bezpečnostní aktualizace veřejně zveřejnili informace o opravených zranitelnostech a měli zavedenou politiku koordinovaného zveřejňování zranitelností. CSAF je jedním ze způsobů, jak splnit strojově čitelnou část.
• BSI zveřejňuje svá vlastní upozornění CERT-Bund ve formátu CSAF. Jeho technická směrnice TR-03183-3 (Vulnerability Reports and Notifications, v1.0.0, srpen 2025) uvádí zveřejnění na webu výrobce ve formátu CSAF jako doporučený způsob distribuce upozornění (oddíl 3.1.5). Vyžaduje soubor security.txt (oddíl 4.2) a uvádí, že výrobce by v něm měl uvést svůj provider-metadata.json v poli CSAF: (oddíl 4.2.8). Technická směrnice je doporučení, nikoli zákon.
• Single Reporting Platform agentury ENISA (jednotná platforma pro podávání zpráv) slouží k oznámením úřadům podle CRA, ne k upozorněním pro uživatele. Zveřejnění upozornění CSAF nenahrazuje oznámení a oznámení vaše uživatele neinformuje.

Minimální funkční nastavení CSAF

• Seznam produktů a verzí s identifikátory CPE nebo package URL tam, kde je máte
• Metadata vydavatele: název, kategorie, jmenný prostor a kontaktní údaje
• První upozornění v profilu csaf_security_advisory
• Validace vůči schématu a testům ve standardu
• provider-metadata.json v /.well-known/csaf/
• Řádek CSAF: v security.txt
• ROLIE feed nebo adresář se soubory index.txt a changes.csv
• TLS na každé URL, bez přesměrování
• Stránka pro lidi vykreslená z JSON
• Zveřejněný podpisový klíč, jakmile přejdete na trusted provider

Jak napsat dobré bezpečnostní upozornění

S CSAF i bez něj odpovídá užitečné upozornění na stejné otázky. Toto je šablona, ke které většina týmů PSIRT dospěje, s polem CSAF, které nese každou odpověď:

Prvek upozornění	Co napsat	V CSAF
ID a název	Stabilní ID upozornění a název, který jmenuje produkt a druh problému	tracking/id, title
Data a revize	První zveřejnění, poslední aktualizace a co se v každé revizi změnilo	Data v tracking a revision_history
Dotčené produkty	Přesné produkty a rozsahy verzí, ne „starší verze“	product_tree, known_affected
Nedotčené a opravené	Které produkty a verze nejsou dotčeny a které verze obsahují opravu	known_not_affected, fixed, first_fixed
Zranitelnost	ID CVE, srozumitelný popis, dopad a způsob zneužití, bez návodu pro útočníky	cve, ids, notes
Závažnost	Skóre CVSS s vektorem, aby si ho čtenáři mohli ověřit	scores
Náprava	Opravená verze, nebo náhradní řešení či zmírnění, nebo jasné prohlášení, že oprava se neplánuje	remediations
Poděkování a odkazy	Kdo problém nahlásil, odkazy na související upozornění a opravy	acknowledgments, references
Kontakt	Kam hlásit problémy a klást otázky	publisher/contact_details

Několik návyků rozhoduje o tom, zda lidé podle upozornění jednají, nebo ho ignorují:

• Buďte přesní ve verzích. Podle dotčeného rozsahu zákazníci jednají. Pro každou produktovou řadu uveďte první dotčenou a první opravenou verzi.
• Uveďte, co dotčeno není. Zákazníci, kteří provozují vámi vyloučené produkty, se přestanou ptát a jejich skenery je přestanou označovat, pokud zveřejníte i VEX.
• Aktualizujte, nenahrazujte. Ke každému problému veďte jedno upozornění a s vydáváním oprav přidávejte revize.
• Zveřejněte v dohodnutý den. Upozornění jsou koncovým bodem koordinovaného zveřejňování zranitelností a vydávají se, když je oprava k dispozici a nahlašovatel byl informován.

Kroky před upozorněním, od přijetí a triáže po opravu, popisuje článek životní cyklus správy zranitelností a lidi, kteří tuto práci dělají, stránka role PSIRT.

Nejtěžší je vědět, co je dotčeno

Každé upozornění, v CSAF i v jakémkoli jiném formátu, závisí na jedné odpovědi: které produkty a verze obsahují zranitelnou komponentu. U softwaru sestaveného z open source balíčků to znamená přesně vědět, které verze závislostí vstoupily do každého vydání, včetně tranzitivních.

CRACI bezpečnostní upozornění nepíše ani nezveřejňuje. Dodává záznam, ze kterého se sestavuje stav produktů v upozornění. CRACI spouští 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 a závislostí, které neuvádí žádný lockfile. Když je zveřejněna nová zranitelnost, monitorované SBOM se znovu vyhodnotí a historie buildů ukáže, které minulé buildy a vydání obsahovaly zranitelnou závislost, přímo nebo tranzitivně, a od kdy. Inventář ukazuje, které verze jsou nasazeny ve kterých produktech, a triáž předá každý nález týmu, který opravu vlastní. SBOM se exportují jako CycloneDX nebo SPDX a CRACI podporuje VEX. Viz sledování zranitelností.

CSAF: časté dotazy

Co znamená zkratka CSAF?

V bezpečnosti CSAF znamená Common Security Advisory Framework, standard OASIS pro zápis bezpečnostních upozornění jako strojově čitelných dokumentů JSON a jejich distribuci tak, aby je nástroje mohly automaticky najít a zpracovat.

Jaká je aktuální verze CSAF?

CSAF 2.0, schválená jako OASIS Standard 18. listopadu 2022 a vydaná také jako ISO/IEC 20153:2025. CSAF 2.1 se připravuje: její čtvrtý Committee Specification Draft byl schválen 21. října 2026 a veřejné připomínkování skončilo 6. listopadu 2026. Zatím nejde o schválený OASIS Standard.

Jaký je rozdíl mezi CSAF a CVE?

Záznam CVE identifikuje jednu zranitelnost a popisuje ji obecně. Bezpečnostní upozornění CSAF vydává dodavatel nebo koordinátor a uvádí, jak tato zranitelnost, a často i několik dalších, ovlivňuje konkrétní produkty a verze a co s tím dělat. Upozornění CSAF odkazují na identifikátory CVE.

Co je CSAF VEX?

CSAF VEX je profil csaf_vex standardu CSAF. Nese prohlášení VEX: pro každý produkt, zda je dotčen, není dotčen, je opraven nebo se prošetřuje, s prohlášením o dopadu u nedotčených produktů a s nápravou u dotčených. Trivy a Grype ho umí číst a potlačit podle něj nálezy.

Co je poskytovatel CSAF (CSAF provider)?

Poskytovatel CSAF je organizace, která své vlastní dokumenty CSAF zveřejňuje tak, aby je nástroje mohly objevit: soubor provider-metadata.json, dohledatelný přes security.txt, well-known URL nebo název DNS, a adresář nebo ROLIE feed s upozorněními. Důvěryhodný poskytovatel (trusted provider) přidává hashe, podpisy OpenPGP a zveřejněný veřejný klíč.

Co CSAF nahradil?

Common Vulnerability Reporting Framework (CVRF), formát v XML. CVRF 1.1 vydala ICASI v roce 2012 a CVRF 1.2 OASIS v roce 2017. CSAF 2.0 přešel na JSON a přidal profily, stromy produktů a pravidla distribuce.

Jak napsat bezpečnostní upozornění CSAF?

Většina týmů začíná v editoru, jako je Secvisogram, webový editor CSAF od BSI, nebo JSON generuje z vlastního sledování zranitelností. Zvolte profil, obvykle csaf_security_advisory, vyplňte vydavatele, sledovací údaje, strom produktů a zranitelnosti, ověřte dokument vůči schématu a zveřejněte ho přes poskytovatele.

Jak převést naše bezpečnostní upozornění z webové stránky na CSAF?

Začněte kanonickým seznamem produktů a verzí a pak se staňte poskytovatelem CSAF: zveřejněte provider-metadata.json, odkažte na něj ze security.txt a upozornění uveďte v ROLIE feedu nebo v adresáři. Nová upozornění generujte ze svých záznamů o zranitelnostech, webovou stránku vykreslujte ze stejného JSON a stará upozornění doplňte až nakonec.

Můžeme si při zveřejňování CSAF ponechat RSS feed?

Ano. RSS feed je doručovací kanál a CSAF je formát, takže mohou existovat vedle sebe. Pokud chcete jeden feed pro lidi i stroje, ROLIE feed je postavený na Atomu a RSS feed může nahradit. Oba generujte ze stejných dat upozornění, aby si nikdy neodporovaly.

Jakou roli CSAF potřebujeme: publisher, provider, nebo trusted provider?

Většina dodavatelů potřebuje být poskytovatelem CSAF (provider): platné dokumenty, provider-metadata.json, způsob objevení a adresář nebo ROLIE feed, aby si zákazníci mohli upozornění stahovat automaticky. Samotný publisher je výchozí bod, který nástroje nedokážou objevit. Důvěryhodným poskytovatelem (trusted provider) s hashi, podpisy OpenPGP a veřejným klíčem se staňte, když zákazníci nebo úřady očekávají podepsaná upozornění.

Vyžaduje Cyber Resilience Act CSAF?

Ne. CRA žádný formát nejmenuje. Čl. 14 odst. 8 požaduje, aby výrobci informovali dotčené uživatele o aktivně zneužívané zranitelnosti nebo závažném incidentu, a to případně ve strukturovaném, strojově čitelném formátu, který lze snadno automaticky zpracovat. CSAF je jedním ze způsobů, jak to splnit, a formátem, který doporučuje BSI.

Co BSI očekává od výrobců ohledně CSAF?

BSI TR-03183-3, technická směrnice, nikoli zákon, uvádí zveřejnění na webu výrobce ve formátu CSAF jako doporučený způsob distribuce upozornění. Vyžaduje soubor security.txt a uvádí, že výrobci by v něm měli uvést svůj provider-metadata.json v poli CSAF:. BSI zveřejňuje svá vlastní upozornění CERT-Bund ve formátu CSAF.

Máme zveřejňovat CSAF 2.0, nebo počkat na 2.1?

Zveřejňujte 2.0 hned. Je to schválený OASIS Standard a ISO/IEC 20153:2025 a nástroje ho podporují. CSAF 2.1 je stále Committee Specification Draft, jehož čtvrtý návrh se připomínkoval v říjnu a listopadu 2026. Pozdější přechod na 2.1 znamená aktualizaci nástrojů, ne důvod čekat.