CSAF and VEX

What are CSAF and VEX?

CSAF (Common Security Advisory Framework) is an OASIS standard for machine-readable security advisories in JSON, and VEX (Vulnerability Exploitability eXchange) is a type of advisory that states, per product, whether a known vulnerability can actually be exploited. Together they replace the PDF or web page that an engineer has to read by hand with a structured document that software can retrieve, verify and compare against the installed base. In OT environments, where a single vendor may release dozens of advisories a month, that is the difference between keeping up and falling behind.

🧠 What does CSAF actually do?

CSAF describes a security advisory as a JSON document with a fixed structure. Every advisory has three main blocks:

• document — publisher, title, version, revision history, TLP classification and status (draft, interim or final)
• product_tree — a tree of vendor, product family, product name and version, so a tool knows exactly which firmware or software is meant
• vulnerabilities — for each vulnerability the CVE identifier, a CVSS score, the product status and the remediation (vendor fix, workaround, mitigation or no fix planned)

CSAF 2.0 has been an OASIS Standard since 18 November 2022. It replaces the XML-based CVRF 1.2 from 2017, which in turn built on work by the industry consortium ICASI. In May 2025, CSAF 2.0 was also approved as the international standard ISO/IEC 20153. Its successor, CSAF 2.1, is not yet an OASIS Standard: the third committee draft (CSD03) went out for public review in September 2026.

📋 Which types of CSAF document exist?

CSAF 2.0 defines five profiles. The /document/category field determines which profile applies and which fields become mandatory.

An informational advisory must not contain a vulnerabilities block. As soon as a CVE is involved, the document belongs in the security advisory or VEX profile.

🔍 What does a VEX document tell you?

VEX grew out of the US software transparency working groups run by NTIA and later CISA; in April 2023 CISA published the Minimum Requirements for VEX. VEX is a concept with several implementations: CSAF, CycloneDX and OpenVEX. At its core is one of four statuses for each combination of product and vulnerability:

For not affected, CSAF offers five machine-readable justifications: component_not_present (the component is not in the product), vulnerable_code_not_present (the component is, the vulnerable code is not), vulnerable_code_not_in_execute_path (the code is never executed), vulnerable_code_cannot_be_controlled_by_adversary (an attacker cannot reach or steer the code) and inline_mitigations_already_exist (built-in controls prevent exploitation).

🔄 How do VEX and SBOM fit together?

An SBOM tells you which components a product contains, but not whether a vulnerability in one of those components is reachable in that product. Run the SBOM of an HMI panel through a scanner and you will quickly see hundreds of CVEs in libraries such as OpenSSL or BusyBox, most of which cannot be exploited in practice. VEX is the vendor’s answer to that noise: “this CVE sits in a library we ship, but the vulnerable function is never called.”

SBOM and VEX therefore form the basis of risk-driven vulnerability management: the SBOM supplies the contents, VEX supplies the context, and CISA’s Known Exploited Vulnerabilities catalogue shows which vulnerabilities are already being exploited in the wild.

🏭 Who publishes CSAF advisories?

A growing number of OT vendors and government bodies publish their advisories in CSAF:

• Siemens ProductCERT — publishes every Siemens Security Advisory as a CSAF feed as well, discoverable through the provider-metadata.json on its CERT portal
• Schneider Electric — offers its security notifications in a CSAF version alongside the PDF
• CISA — has shipped a CSAF document with every ICS advisory since 29 September 2023, back-filled to 2017 and also available on GitHub
• BSI / CERT-Bund — Germany is one of the main drivers; the BSI set up the world’s first CSAF lister (a public directory of CSAF providers) and requires CSAF in its technical guideline TR-03183-3
• NCSC — the Dutch NCSC has used CSAF as the primary source format for its security advisories since 15 May 2024; organisations under NIS2 and Dutch central government bodies also get access through a secured API

The standard also defines distribution roles. A CSAF provider publishes documents at a fixed location (/.well-known/csaf/provider-metadata.json) through a ROLIE feed or a directory structure; a trusted provider adds hashes and OpenPGP signatures. A lister keeps a list of providers and an aggregator mirrors their documents, so you do not have to query every vendor separately.

🔐 What does the Cyber Resilience Act mean for CSAF and VEX?

In Annex I, Part II, the Cyber Resilience Act requires manufacturers of products with digital elements to maintain an SBOM in a commonly used, machine-readable format and to publish information about fixed vulnerabilities: a description, the affected products, the impact, the severity and the remediation. The CRA does not prescribe a format, but CSAF covers exactly those fields. The CRA reporting obligations have applied since 11 September 2026; the remaining obligations follow on 11 December 2027.

Germany makes the link explicit: BSI guideline TR-03183 Part 3 requires security advisories to be published in CSAF 2.0. For suppliers that already work to IEC 62443-4-1 (a secure development lifecycle that includes a process for responsible disclosure and security updates), CSAF is the natural output format of that process.

🛠️ How do you consume CSAF feeds as an OT asset owner?

1. Keep an up-to-date asset inventory — without an inventory of vendor, type number and firmware version there is nothing to match against; a CMDB or OT monitoring platform is the source
2. Map your suppliers — check for each vendor whether it is a CSAF provider (look for a CSAF: line in its security.txt or for a provider-metadata.json), or use an aggregator
3. Retrieve documents automatically — with an open-source downloader or a commercial platform; for trusted providers, always verify the hash and signature
4. Match at product level — compare the product_tree with your inventory, preferably through structured identifiers such as CPE or PURL rather than free text
5. Process VEX statuses — close known_not_affected items that carry a justification, put under_investigation on a watch list and prioritise known_affected
6. Prioritise — combine CVSS, the KEV catalogue and your own context (reachability, zone, criticality of the process) into a single work queue
7. Plan remediation — schedule updates through patch management and maintenance shutdowns; where patching is impossible, document the compensating control

A worked example: a water utility runs fifty PLCs from two vendors. A new advisory lists twelve firmware versions as known_affected and a further eight as fixed. Automated matching shows that only three PLCs run an affected version, and that all three sit in a zone without remote access. Instead of an all-hands review, the team plans one targeted update in the next maintenance window.

❓ Frequently asked questions

What is the difference between CSAF and VEX?

CSAF is the overarching format for machine-readable security advisories, and VEX is one of the five profiles within CSAF. A CSAF security advisory reports a vulnerability and its fix; a VEX document states for each product whether that vulnerability can actually be exploited there. VEX also exists in the CycloneDX and OpenVEX formats.

Is CSAF 2.1 already an official standard?

No, as of early October 2026 CSAF 2.1 was not yet an OASIS Standard. Its third committee specification draft (CSD03) went out for public review in September 2026. The version in force is CSAF 2.0, an OASIS Standard since November 2022 and ISO/IEC 20153 since 2025.

Does the Dutch NCSC publish its advisories in CSAF?

Yes, the Dutch NCSC has used CSAF as the primary source format for its security advisories since 15 May 2024. The CSAF files are publicly available alongside the human-readable advisories. This lets you process NCSC advisories automatically, just like vendor advisories.

Is CSAF mandatory under the Cyber Resilience Act?

The Cyber Resilience Act does not name CSAF, but it does require manufacturers to keep a machine-readable SBOM and to publish information about fixed vulnerabilities. CSAF is the format that fits that requirement best, because it captures exactly those fields in machine-readable form. In Germany, BSI guideline TR-03183-3 explicitly requires CSAF 2.0.

Why does VEX matter when you have an SBOM?

An SBOM scan often returns hundreds of CVEs in bundled libraries, while most of them are not reachable in the product. A VEX document from the vendor states for each CVE whether the product is affected and why. Without VEX, you spend a great deal of time chasing false positives.

How can you tell whether a supplier publishes CSAF advisories?

A CSAF provider publishes a provider-metadata.json at a fixed location under /.well-known/csaf/ and usually points to it from its security.txt. CSAF listers and aggregators, such as the one run by the BSI, also keep directories of providers. If a supplier is missing, add CSAF to your procurement requirements.

📌 In summary

CSAF makes security advisories machine-readable and VEX tells you, per product, whether a vulnerability can really be exploited; combined with an SBOM and an up-to-date asset inventory they make automated vulnerability management in OT possible. Siemens, Schneider Electric, CISA, the BSI and the NCSC already publish in CSAF 2.0, and the Cyber Resilience Act is making machine-readable vulnerability information the norm.