CSAF: het Common Security Advisory Framework voor machineleesbare advisories

Wat is CSAF?

Het Common Security Advisory Framework (CSAF) is een standaard van het OASIS CSAF Technical Committee om security advisories als gestructureerde JSON te schrijven en ze zo te verspreiden dat ze automatisch kunnen worden gevonden en verwerkt. Een CSAF-document vertelt welke producten en versies een kwetsbaarheid raakt, welke niet zijn getroffen, welke zijn gerepareerd en wat gebruikers moeten doen.

De huidige versie is CSAF 2.0, op 18 november 2022 goedgekeurd als OASIS Standard. CSAF 2.1 komt eraan: het derde Committee Specification Draft is in september 2026 door de openbare consultatie gegaan, en in oktober 2026 is het nog geen goedgekeurde standaard.

Advisories worden geschreven door leveranciers, meestal door hun product security incident response team (PSIRT), en door coördinatoren zoals nationale CERT's. Zie voor het verschil tussen die twee soorten teams PSIRT vs CSIRT.

Van CVRF naar CSAF

CSAF is voortgekomen uit het Common Vulnerability Reporting Framework (CVRF), een XML-formaat. ICASI publiceerde CVRF 1.1 in mei 2012 en OASIS publiceerde CVRF 1.2 in september 2017. CSAF 2.0 verving het door een JSON-formaat, een JSON-schema voor validatie, profielen voor verschillende soorten documenten, en regels voor hoe advisories worden verspreid en gevonden. De specificatie definieert nog steeds hoe CVRF-documenten naar CSAF worden omgezet.

Opbouw van een CSAF-document

Een CSAF-document heeft drie onderdelen op het hoogste niveau:

• document: metadata. Vijf eigenschappen zijn verplicht: de categorie (welk profiel het document volgt), de CSAF-versie, de publisher, de titel en de trackinggegevens. Tracking bevat de advisory-ID, de status, de versie, de eerste en huidige releasedatum en een revisiegeschiedenis.
• product_tree: elk product dat het document noemt, meestal als takken van leverancier naar productnaam naar versie, met product-ID's waarnaar de rest van het document verwijst. Producten kunnen ook worden geïdentificeerd met een package URL (purl), CPE of hashes.
• vulnerabilities: één vermelding per kwetsbaarheid, met de CVE- of andere ID's, notities, scores en een productstatus die product-ID's in lijsten indeelt: known_affected, known_not_affected, fixed, first_affected, last_affected, first_fixed, recommended en under_investigation. Herstelmaatregelen worden ingedeeld als vendor_fix, workaround, mitigation, no_fix_planned of none_available.

De vijf CSAF-profielen

In CSAF als geheel zijn maar weinig velden verplicht. Profielen bepalen welke velden een bepaald soort document moet hebben, en de waarde van /document/category geeft aan welk profiel een document volgt:

Profiel	Categoriewaarde	Gebruik het voor
CSAF Base	csaf_base	Het minimum waaraan elk CSAF-document voldoet; de verzamelcategorie voor documenten die in geen ander profiel passen
Security incident response	csaf_security_incident_response	Reageren op een beveiligingsinbreuk of -incident, ook bij een andere organisatie
Informational advisory	csaf_informational_advisory	Problemen die geen kwetsbaarheid zijn, zoals een gevaarlijke misconfiguratie
Security advisory	csaf_security_advisory	Kwetsbaarheden en hun herstelmaatregelen; de klassieke advisory van een leverancier
VEX	csaf_vex	Vastleggen of, en waarom, elk product wel of niet door een kwetsbaarheid wordt geraakt

Een security advisory moet een productboom, de kwetsbaarheden, notities bij elke kwetsbaarheid en een productstatus hebben. Het VEX-profiel gaat verder: elk product dat als known_not_affected staat vermeld, heeft een impactverklaring nodig, als machineleesbare vlag of als tekst, en elk known_affected product heeft een herstelmaatregel nodig die gebruikers vertelt wat ze moeten doen.

CSAF VEX

VEX (Vulnerability Exploitability eXchange) vertelt gebruikers welke kwetsbaarheden in de componenten van een product het product daadwerkelijk raken. CSAF VEX is een van de drie gangbare VEX-formaten, naast OpenVEX en CycloneDX VEX. De vlaggen gebruiken dezelfde vijf rechtvaardigingen voor 'niet getroffen' als de VEX-eisen van CISA, zoals component_not_present en vulnerable_code_not_in_execute_path. Trivy en Grype lezen allebei CSAF VEX en laten bevindingen vallen die het als niet getroffen markeert. Red Hat publiceert zijn CSAF VEX-documenten bijvoorbeeld in een aparte map naast zijn CSAF-advisories.

Hoe CSAF-advisories worden verspreid

Een standaardformaat helpt alleen als tools de documenten kunnen vinden. Sectie 7 van CSAF 2.0 legt vast hoe:

• provider-metadata.json beschrijft de publisher en waar zijn advisories staan. Tools vinden het via ten minste een van drie routes: een veld CSAF in de security.txt van het domein, de well-known URL /.well-known/csaf/provider-metadata.json, of de DNS-naam csaf.data.security. vóór het domein.
• Advisories worden vermeld in mappen per jaar met een index.txt en changes.csv, of in ROLIE-feeds, geleverd via TLS zonder redirects.
• Elk bestand is vernoemd naar zijn tracking-ID. TLP:WHITE-advisories moeten vrij toegankelijk zijn, en TLP:AMBER- of TLP:RED-advisories moeten achter toegangscontrole staan.
• Integriteit: trusted providers voegen aan elk document een hash en een OpenPGP-handtekening toe en publiceren hun publieke sleutel.

De standaard definieert vijf rollen die een verspreidende partij kan claimen:

Rol	Wat die doet
CSAF publisher	Publiceert geldige CSAF-documenten, alleen namens zichzelf, via TLS
CSAF provider	Een publisher die ook een provider-metadata.json, een ontdekkingsroute en een map of ROLIE-feed biedt
CSAF trusted provider	Een provider die ook hashes, OpenPGP-handtekeningen en zijn publieke sleutel publiceert
CSAF lister	Houdt een lijst bij van waar de CSAF-documenten van andere partijen te vinden zijn, zonder ze te kopiëren
CSAF aggregator	Spiegelt de documenten van ten minste twee onafhankelijke uitgevende partijen op één plek, met hashes en handtekeningen

Afnemers stellen eenmalig een downloader in en halen daarna nieuwe advisories op bij elke provider waarvan hun producten afhankelijk zijn, in plaats van tientallen webpagina's van leveranciers in de gaten te houden.

Wie CSAF publiceert

CSAF komt het meest voor bij industriële, enterprise- en infrastructuurleveranciers en bij nationale CERT's:

• Cisco biedt een provider-metadata.json aan op zijn well-known CSAF-URL.
• Siemens ProductCERT publiceert zijn advisories als CSAF ROLIE-feed.
• Red Hat publiceert CSAF-advisories en, apart daarvan, CSAF VEX-documenten.
• CERT-Bund van het BSI, de nationale CERT van Duitsland, publiceert CSAF-feeds van zijn advisories.
• CISA kondigde in september 2023 aan dat zijn ICS-advisories vergezeld gaan van CSAF-documenten, terug tot 2017, en drong er bij leveranciers op aan de standaard over te nemen.

Industriële leveranciers die werken volgens IEC 62443-4-1 hebben een proces nodig om gebruikers te informeren over beveiligingsproblemen in hun producten, en machineleesbare advisories zijn een gangbare manier om aan de verwachtingen van hun klanten te voldoen.

CSAF-tools

• Secvisogram is de webeditor van het BSI voor CSAF-documenten, met een formuliereditor, een JSON-editor, een HTML-voorbeeld en validatie.
• De csaf-tools van het BSI en Intevation (gocsaf/csaf, vaak csaf_distribution genoemd) implementeren een trusted provider, een checker, een aggregator en een downloader, met een CSAF 2.1-versie in ontwikkeling.
• Scanners zoals Trivy en Grype verwerken CSAF VEX-documenten.

Een goede security advisory schrijven

Met of zonder CSAF beantwoordt een bruikbare advisory dezelfde vragen. Dit is het sjabloon waar de meeste PSIRT's op uitkomen, met het CSAF-veld dat elk antwoord bevat:

Onderdeel van de advisory	Wat u schrijft	In CSAF
ID en titel	Een stabiele advisory-ID en een titel die het product en het soort probleem noemt	tracking/id, title
Datums en revisies	Eerste publicatie, laatste update en wat er in elke revisie is veranderd	tracking-datums en revision_history
Getroffen producten	Exacte producten en versiebereiken, niet "oudere versies"	product_tree, known_affected
Niet getroffen en gerepareerd	Welke producten en versies niet zijn getroffen, en welke versies de fix bevatten	known_not_affected, fixed, first_fixed
Kwetsbaarheid	CVE-ID's, een heldere beschrijving, de impact en hoe de kwetsbaarheid wordt misbruikt, zonder recept voor aanvallers	cve, ids, notes
Ernst	Een CVSS-score met zijn vector, zodat lezers die kunnen controleren	scores
Herstel	De gerepareerde versie, een workaround of mitigatie, of een duidelijke verklaring dat er geen fix is gepland	remediations
Vermeldingen en referenties	Wie het heeft gemeld, links naar gerelateerde advisories en fixes	acknowledgments, references
Contact	Waar men problemen kan melden en vragen kan stellen	publisher/contact_details

Een paar gewoonten maken het verschil tussen een advisory waarop mensen actie ondernemen en een die ze negeren:

• Wees exact over versies. Op het getroffen bereik baseren klanten hun actie. Noem per productlijn de eerste getroffen en de eerste gerepareerde versie.
• Zeg wat niet is getroffen. Klanten met producten die u hebt uitgesloten, stoppen met vragen, en hun scanners stoppen met markeren als u ook VEX publiceert.
• Werk bij, vervang niet. Houd één advisory per probleem aan en voeg revisies toe naarmate er fixes worden geleverd.
• Publiceer op de afgesproken datum. Advisories zijn het eindpunt van gecoördineerde openbaarmaking van kwetsbaarheden en verschijnen wanneer de fix beschikbaar is en de melder is geïnformeerd.

De stappen vóór de advisory, van intake en triage tot de fix, komen aan bod in de levenscyclus van kwetsbaarheidsbeheer, en de mensen die dit werk doen, in de PSIRT-rol.

Het moeilijke deel is weten wat is getroffen

Elke advisory, in CSAF of in welk ander formaat ook, hangt af van één antwoord: welke producten en versies de kwetsbare component bevatten. Voor software die uit open-sourcepakketten is opgebouwd, betekent dat precies weten welke versies van afhankelijkheden in elke release zijn terechtgekomen, inclusief transitieve.

CRACI draait GitHub Actions-builds op zijn eigen runners en legt de pakketten vast die elke job daadwerkelijk heeft opgehaald, inclusief transitieve afhankelijkheden, pakketten die uit caches zijn teruggezet en afhankelijkheden die in geen enkele lockfile staan. Wanneer er een nieuwe kwetsbaarheid wordt gepubliceerd, worden gemonitorde SBOM's opnieuw beoordeeld, en de buildgeschiedenis toont welke eerdere builds en releases de kwetsbare afhankelijkheid direct of transitief bevatten, zodat u weet in welke periode u getroffen was. De inventarisweergave toont welke versies op welke producten zijn uitgerold, en triage stuurt elke bevinding naar het team dat verantwoordelijk is voor de fix. SBOM's worden geëxporteerd als CycloneDX of SPDX, en CRACI ondersteunt VEX. Zie het volgen van kwetsbaarheden.

CSAF: veelgestelde vragen

Waar staat CSAF voor?

In de beveiliging staat CSAF voor Common Security Advisory Framework, een OASIS-standaard om security advisories als machineleesbare JSON-documenten te schrijven en ze zo te verspreiden dat tools ze automatisch kunnen vinden en verwerken.

Wat is de huidige versie van CSAF?

CSAF 2.0, op 18 november 2022 goedgekeurd als OASIS Standard. CSAF 2.1 is in de maak: het derde Committee Specification Draft heeft de openbare consultatie op 29 september 2026 afgerond, en in oktober 2026 is het nog geen goedgekeurde OASIS Standard.

Wat is het verschil tussen CSAF en CVE?

Een CVE-record identificeert één kwetsbaarheid en beschrijft die in algemene termen. Een CSAF-advisory wordt gepubliceerd door een leverancier of coördinator en vertelt hoe die kwetsbaarheid, en vaak nog andere, specifieke producten en versies raakt en wat u eraan moet doen. CSAF-advisories verwijzen naar CVE-ID's.

Wat is CSAF VEX?

CSAF VEX is het profiel csaf_vex van CSAF. Het bevat VEX-verklaringen: per product of het is getroffen, niet is getroffen, is gerepareerd of wordt onderzocht, met een impactverklaring voor producten die niet zijn getroffen en een herstelmaatregel voor producten die dat wel zijn. Trivy en Grype kunnen het lezen om bevindingen te onderdrukken.

Wat is een CSAF-provider?

Een CSAF-provider is een organisatie die haar eigen CSAF-documenten zo publiceert dat tools ze kunnen ontdekken: een bestand provider-metadata.json, vindbaar via security.txt, een well-known URL of een DNS-naam, en een map of ROLIE-feed met advisories. Een trusted provider voegt daar hashes, OpenPGP-handtekeningen en een gepubliceerde publieke sleutel aan toe.

Wat heeft CSAF vervangen?

Het Common Vulnerability Reporting Framework (CVRF), een XML-formaat. CVRF 1.1 werd in 2012 gepubliceerd door ICASI en CVRF 1.2 in 2017 door OASIS. CSAF 2.0 stapte over op JSON en voegde profielen, productbomen en distributieregels toe.

Hoe schrijf ik een CSAF-advisory?

De meeste teams beginnen in een editor zoals Secvisogram, de webeditor van het BSI voor CSAF, of genereren de JSON vanuit hun eigen kwetsbaarheidstracking. Kies een profiel, meestal csaf_security_advisory, vul de publisher, de trackinggegevens, de productboom en de kwetsbaarheden in, valideer het document tegen het schema en publiceer het via een provider.