CSAF 2.0 and VEX: machine-readable security advisories for device makers

A CVE list is not an advisory. Customers, scanners and downstream integrators want to know, in a machine-readable form, which of your product versions a vulnerability actually affects. CSAF 2.0 (Common Security Advisory Framework), an OASIS Standard, is the format built for that. Its built-in VEX profile lets a PSIRT state, per product and per vulnerability, whether it is affected, not affected, fixed, or under investigation, so a scanner can stop flagging code your firmware never runs.

What CSAF 2.0 actually is

CSAF Version 2.0 was approved as an OASIS Standard on 18 November 2022. It is "a language to exchange Security Advisories formulated in JSON" that supports creating, updating and exchanging security advisories as structured data about products, vulnerabilities, and remediation status. It replaces the earlier Common Vulnerability Reporting Framework (CVRF) 1.2, which the CSAF technical committee was chartered to revise. The standard also achieved international recognition as ISO/IEC 20153:2025.

Beyond the document schema, CSAF 2.0 specifies how advisories are distributed and discovered: a CSAF "provider" publishes documents at a predictable location, and a machine-readable index (provider-metadata.json) lets consumers and aggregators find new advisories automatically, without screen-scraping a vendor's security page.

The five CSAF 2.0 profiles

CSAF 2.0 defines five document profiles, each a different use of the same base schema:

Profile	Purpose
1. CSAF Base	The underlying schema all other profiles build on
2. Security Incident Response	Describes an incident, not necessarily tied to a published CVE
3. Informational Advisory	General security information without a specific remediation
4. Security Advisory	A full advisory: vulnerability, affected products, remediation
5. VEX	A statement of product/vulnerability status: affected, not affected, fixed or under investigation

VEX inside CSAF: what it actually states

VEX (Vulnerability Exploitability eXchange) closes a gap that a plain SBOM leaves open: an SBOM lists the components in a product, but not whether a known vulnerability in one of them is actually reachable. CISA's VEX guidance defines four statuses a VEX document can assert for a product against a given vulnerability:

Status	Meaning
Not affected	The product is not affected; a justification must be given
Affected	The product is affected; remediation or mitigation is recommended
Fixed	The named product version contains a fix
Under investigation	Not yet determined; the document will be updated

CISA's Minimum Requirements for VEX (April 2023) sets out what a VEX statement needs to be useful to an automated consumer: clear product identification, the vulnerability identifier, the status, a timestamp, and, for "not affected", one of the accepted justifications (for example: component not present, vulnerable code not present, vulnerable code not in the execute path, or inline mitigations already exist). Because CSAF 2.0's Profile 5 already carries all of these fields, a PSIRT does not need a second document format to publish VEX; a CSAF VEX document is a VEX statement.

VEX is not only a CSAF thing

CISA's own SBOM resources describe four VEX implementations in active use, not just the CSAF profile:

Format	Where VEX lives
CSAF 2.0 Profile 5: VEX	Native CSAF document
OpenVEX	Minimal, standalone JSON format
OWASP CycloneDX	VEX fields embedded in a CycloneDX BOM
SPDX 3.0	Security profile fields (to be confirmed against the finalised SPDX 3.0 security profile)

If you already produce a CycloneDX SBOM, as described in our firmware SBOM guide, adding CycloneDX's native VEX fields may be less work than standing up a separate CSAF provider. CSAF is the stronger choice once you also want machine-discoverable, standalone advisories, not just VEX attached to a BOM.

Why this matters for device makers specifically

• Cuts scanner noise. A legacy embedded Linux image can match hundreds of CVEs in an SBOM scan. A VEX statement per component lets customers' tools suppress the ones that do not apply, instead of re-triaging the same false positives every release.
• Speeds up your own PSIRT. A CSAF Security Advisory (Profile 4) issued alongside a fix gives customers a single machine-readable record of affected versions, instead of a prose PDF they have to parse by hand.
• Fits the vulnerability-handling duties device makers already have. The CRA requires manufacturers to identify components (SBOM), fix vulnerabilities without delay and publish information on fixed vulnerabilities (Annex I Part II); see the Cyber Resilience Act guide. CSAF and VEX are a practical way to meet the "publish information" and "machine-readable" parts of that duty, even though the CRA text itself does not name CSAF, CVRF or VEX. Whether a future harmonised standard or Commission implementing act (CRA Art. 13(24)) specifies CSAF for the SBOM or reporting format is to be confirmed.
• Complements your VDP. A vulnerability disclosure policy tells people how to report a bug; CSAF/VEX is how you publish the outcome once you have triaged it, including against KEV and EPSS data.

A workable starting process

1. Pick one profile to start: VEX. It is the highest-value, lowest-effort profile for a device maker already building an SBOM, because it attaches directly to components you have already inventoried.
2. Draft VEX statements from your existing SBOM and vulnerability matches. For each CVE matched against a component version, record a status and, for "not affected", a justification from CISA's accepted list.
3. Publish as CSAF or alongside your SBOM format, depending on what your main customers already parse: a CSAF provider endpoint for customers with CSAF tooling, CycloneDX-embedded VEX if your SBOM pipeline is already CycloneDX-based.
4. Add Profile 4 Security Advisories once VEX is routine, so a fixed vulnerability gets both a VEX "fixed" statement and a full advisory with remediation steps.
5. Re-publish on every release and every new CVE match, not just at launch; a CSAF document without a current timestamp is as stale as a PDF advisory nobody updates.

SoftWSP matches firmware SBOMs against KEV and EPSS and can help a PSIRT structure its advisory output: see device firmware security and PSIRT as a service.

This guide is general information, not legal advice.