CSAF en VEX

Wat zijn CSAF en VEX?

CSAF (Common Security Advisory Framework) is een OASIS-standaard voor machineleesbare beveiligingsadviezen in JSON, en VEX (Vulnerability Exploitability eXchange) is een type advies dat per product vastlegt of een bekende kwetsbaarheid daadwerkelijk misbruikt kan worden. Samen vervangen ze de PDF of webpagina die een beheerder handmatig moet lezen door een gestructureerd document dat software kan ophalen, controleren en vergelijken met de eigen installaties. Voor OT-omgevingen, waar één fabrikant soms tientallen adviezen per maand uitbrengt, maakt dat het verschil tussen bijhouden en achterlopen.

🧠 Wat doet CSAF precies?

CSAF beschrijft een beveiligingsadvies als een JSON-document met een vaste structuur. Een advies bevat drie hoofdblokken:

• document — uitgever, titel, versie, revisiegeschiedenis, TLP-classificatie en status (draft, interim of final)
• product_tree — een boomstructuur van leverancier, productfamilie, productnaam en versie, zodat een tool exact weet over welke firmware of software het gaat
• vulnerabilities — per kwetsbaarheid het CVE-nummer, een CVSS-score, de productstatus en de remediatie (update, workaround, mitigatie of geen oplossing gepland)

CSAF 2.0 is sinds 18 november 2022 een OASIS-standaard en vervangt het XML-formaat CVRF 1.2 uit 2017, dat weer voortbouwde op werk van het industrieconsortium ICASI. In mei 2025 is CSAF 2.0 ook goedgekeurd als internationale norm ISO/IEC 20153. De opvolger CSAF 2.1 is nog geen OASIS-standaard: in september 2026 lag de derde conceptversie (CSD03) ter publieke consultatie.

📋 Welke soorten CSAF-documenten bestaan er?

CSAF 2.0 kent vijf profielen. Het veld /document/category bepaalt welk profiel geldt en welke velden verplicht zijn.

Het informational advisory mag geen kwetsbaarhedenblok bevatten; zodra er een CVE in het spel is, hoort het document in het security advisory- of VEX-profiel.

🔍 Wat vertelt een VEX-document?

VEX is ontstaan in de Amerikaanse SBOM-werkgroepen van NTIA en CISA; in april 2023 publiceerde CISA de Minimum Requirements for VEX. VEX is een concept dat in meerdere formaten bestaat: CSAF, CycloneDX en OpenVEX. Kern is één van vier statussen per combinatie van product en kwetsbaarheid:

Voor not affected kent CSAF vijf machineleesbare rechtvaardigingen: component_not_present (het onderdeel zit er niet in), vulnerable_code_not_present (het onderdeel wel, de kwetsbare code niet), vulnerable_code_not_in_execute_path (de code wordt nooit uitgevoerd), vulnerable_code_cannot_be_controlled_by_adversary (een aanvaller kan de code niet aansturen) en inline_mitigations_already_exist (ingebouwde maatregelen voorkomen misbruik).

🔄 Hoe hangen VEX en SBOM samen?

Een SBOM vertelt welke componenten in een product zitten, maar niet of een kwetsbaarheid in zo’n component in dat product ook bereikbaar is. Wie een SBOM van een HMI-paneel door een scanner haalt, krijgt al snel honderden CVE’s in bibliotheken als OpenSSL of BusyBox, waarvan het merendeel in de praktijk niet misbruikt kan worden. VEX is het antwoord van de fabrikant op die ruis: “deze CVE zit in een bibliotheek die wij meeleveren, maar de kwetsbare functie wordt niet gebruikt.”

Zo vormen SBOM en VEX samen de basis voor risicogestuurd kwetsbaarheidsbeheer: de SBOM levert de inhoud, VEX de context, en de catalogus Known Exploited Vulnerabilities van CISA geeft aan welke kwetsbaarheden al actief worden misbruikt.

🏭 Wie publiceert CSAF-adviezen?

Steeds meer OT-fabrikanten en overheidsorganisaties leveren hun adviezen in CSAF:

• Siemens ProductCERT — publiceert alle Siemens Security Advisories ook als CSAF-feed, vindbaar via de provider-metadata.json op het eigen certportaal
• Schneider Electric — biedt security notifications naast de PDF ook in een CSAF-versie aan
• CISA — levert sinds 29 september 2023 bij elk ICS-advies een CSAF-document, met terugwerkende kracht tot 2017, ook via GitHub
• BSI / CERT-Bund — Duitsland is een van de grootste aanjagers; het BSI zette ‘s werelds eerste CSAF-lister op (een openbaar overzicht van CSAF-providers) en eist CSAF in de technische richtlijn TR-03183-3
• NCSC — het Nederlandse NCSC gebruikt sinds 15 mei 2024 CSAF als primair bronformaat voor zijn beveiligingsadviezen; organisaties onder NIS2 en de Rijksoverheid krijgen daarnaast toegang via een beveiligde API

De standaard definieert ook rollen voor de distributie. Een CSAF provider zet documenten op een vaste plek (/.well-known/csaf/provider-metadata.json) met een ROLIE-feed of een directorystructuur; een trusted provider voegt hashes en OpenPGP-handtekeningen toe. Een lister houdt een lijst van providers bij en een aggregator spiegelt hun documenten, zodat u niet elke fabrikant apart hoeft te bevragen.

🔐 Wat betekent de Cyber Resilience Act voor CSAF en VEX?

De Cyber Resilience Act verplicht fabrikanten van producten met digitale elementen in bijlage I, deel II tot het bijhouden van een SBOM in een gangbaar, machineleesbaar formaat en tot het openbaar maken van informatie over verholpen kwetsbaarheden: beschrijving, getroffen producten, impact, ernst en oplossing. De CRA schrijft geen specifiek formaat voor, maar CSAF dekt precies die velden af. De CRA-meldplicht geldt sinds 11 september 2026; de overige verplichtingen volgen op 11 december 2027.

Duitsland maakt die koppeling expliciet: de BSI-richtlijn TR-03183 deel 3 eist dat beveiligingsadviezen in CSAF 2.0 worden gepubliceerd. Voor leveranciers die al werken volgens IEC 62443-4-1 (secure development lifecycle, inclusief een proces voor responsible disclosure en security updates) is CSAF de logische uitvoervorm van dat proces.

🛠️ Hoe gebruikt u als OT-assetowner CSAF-feeds?

1. Zorg voor een actuele assetinventaris — zonder inventaris met leverancier, typenummer en firmwareversie valt er niets te matchen; een CMDB of OT-monitoringplatform is de bron
2. Breng de leveranciers in kaart — controleer per fabrikant of die een CSAF-provider is (zoek naar CSAF: in de security.txt of naar provider-metadata.json), of gebruik een aggregator
3. Haal de documenten automatisch op — met een open-source downloader of een commercieel platform; controleer bij trusted providers altijd hash en handtekening
4. Match op productniveau — vergelijk de product_tree met uw inventaris, bij voorkeur via gestructureerde identificatoren zoals CPE of PURL in plaats van vrije tekst
5. Verwerk VEX-statussen — sluit known_not_affected met rechtvaardiging af, zet under_investigation op een volglijst en geef known_affected prioriteit
6. Prioriteer — combineer CVSS, de KEV-catalogus en de eigen context (bereikbaarheid, zone, kritikaliteit van het proces) tot één werkvoorraad
7. Plan de remediatie — leg updates vast in patchmanagement en onderhoudsstops; waar patchen niet kan, documenteert u de compenserende maatregel

Een uitgewerkt voorbeeld: een waterbedrijf heeft vijftig PLC’s van twee leveranciers. Een nieuw advies noemt twaalf firmwareversies known_affected en acht versies fixed. Automatische matching laat zien dat slechts drie PLC’s een getroffen versie draaien, en dat alle drie in een zone zonder toegang op afstand staan. In plaats van een brede handmatige beoordeling plant het team één gerichte update in de eerstvolgende onderhoudsstop.

❓ Veelgestelde vragen

Wat is het verschil tussen CSAF en VEX?

CSAF is het overkoepelende formaat voor machineleesbare beveiligingsadviezen, en VEX is een van de vijf profielen binnen CSAF. Een CSAF-security-advisory meldt een kwetsbaarheid en de oplossing; een VEX-document legt per product vast of die kwetsbaarheid er daadwerkelijk misbruikt kan worden. VEX bestaat daarnaast ook in de formaten CycloneDX en OpenVEX.

Is CSAF 2.1 al een officiële standaard?

Nee, CSAF 2.1 was begin oktober 2026 nog geen OASIS-standaard. De derde conceptversie (CSD03) lag in september 2026 ter publieke consultatie. De geldende versie is CSAF 2.0, sinds november 2022 een OASIS-standaard en sinds 2025 ook ISO/IEC 20153.

Publiceert het NCSC zijn adviezen in CSAF?

Ja, het Nederlandse NCSC gebruikt CSAF sinds 15 mei 2024 als primair bronformaat voor zijn beveiligingsadviezen. De CSAF-bestanden zijn openbaar beschikbaar naast de leesbare adviezen. Daardoor kunt u NCSC-adviezen net als fabrieksadviezen automatisch verwerken.

Is CSAF verplicht onder de Cyber Resilience Act?

De Cyber Resilience Act noemt CSAF niet bij naam, maar verplicht fabrikanten wel tot een machineleesbare SBOM en tot openbare informatie over verholpen kwetsbaarheden. CSAF is het formaat dat daar het best op aansluit, omdat het precies die velden machineleesbaar vastlegt. In Duitsland eist de BSI-richtlijn TR-03183-3 CSAF 2.0 expliciet.

Waarom is VEX belangrijk bij een SBOM?

Een SBOM-scan levert vaak honderden CVE’s op in meegeleverde bibliotheken, terwijl de meeste in het product niet bereikbaar zijn. Een VEX-document van de fabrikant verklaart per CVE of het product wel of niet geraakt wordt en waarom. Zonder VEX besteedt u veel tijd aan valse positieven.

Hoe ziet u of een leverancier CSAF-adviezen publiceert?

Een CSAF-provider publiceert een provider-metadata.json op een vaste locatie onder /.well-known/csaf/ en verwijst daar meestal naar in zijn security.txt. Daarnaast houden CSAF-listers en -aggregators, zoals die van het BSI, overzichten bij van providers. Staat een leverancier er niet tussen, neem CSAF dan op in uw inkoopvoorwaarden.

📌 Samengevat

CSAF maakt beveiligingsadviezen machineleesbaar en VEX vertelt per product of een kwetsbaarheid echt misbruikt kan worden; samen met een SBOM en een actuele assetinventaris maken ze automatisch kwetsbaarheidsbeheer in OT mogelijk. Siemens, Schneider Electric, CISA, het BSI en het NCSC publiceren al in CSAF 2.0, en de Cyber Resilience Act maakt machineleesbare kwetsbaarheidsinformatie de norm.