Engineers with a laptop at automation test rigs in a bright production hall

SBOM

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

Last updated: 2026-11-10

CSAF 2.0 (Common Security Advisory Framework), approved as an OASIS Standard on 18 November 2022, is the machine-readable format built to answer the question a plain CVE list cannot: which of your product versions a vulnerability actually affects. Customers, scanners and downstream integrators need that answer in structured form, not prose. 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.

By SoftWSP Firmware Security Desk11 min read

Key takeaways

CSAF Version 2.0 was approved as an OASIS Standard on 18 November 2022.
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.
Section 4.5 of the CSAF 2.0 standard lists the conditions, and /document/category must be csaf_vex.
Every product is defined once in product_tree with a product_id that status lists and flags refer to.

What is CSAF 2.0, and is 2.1 replacing it?

CSAF Version 2.0 was approved as an OASIS Standard on 18 November 2022. According to the OASIS specification, 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 is also published internationally 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 technical committee is drafting a successor. On 10 November 2026 the CSAF 2.1 latest-stage page shows Committee Specification Draft 04, dated 21 October 2026: a committee draft, not an OASIS Standard. CSAF 2.0 is the version to publish against today. The BSI-backed gocsaf tools keep their CSAF 2.1 work on a separate development branch.

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

What does VEX inside CSAF actually state?

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	Still being assessed; 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 (defined in 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; OpenVEX is the smallest of the four. CSAF is the stronger choice once you also want machine-discoverable, standalone advisories, not just VEX attached to a BOM.

What must a CSAF document contain to count as VEX?

Section 4.5 of the CSAF 2.0 standard lists the conditions, and /document/category must be csaf_vex. A validator that runs the profile tests rejects a VEX document that misses any of them:

Requirement (CSAF 2.0, section 4.5)	Where it lives in the JSON
Everything the CSAF Base profile requires: category, CSAF version, publisher, title, tracking data	`/document`
A product tree that lists every product referenced later, whatever its status	`/product_tree`
At least one status list: fixed, known affected, known not affected or under investigation	`/vulnerabilities[]/product_status`
At least one way to name the vulnerability: a CVE, another tracking ID, or notes	`/vulnerabilities[]/cve`, `ids` or `notes`
For each known-not-affected product, an impact statement: a machine-readable flag, or a threat of category `impact` whose details say why the vulnerability cannot be exploited	`/vulnerabilities[]/flags` or `threats`
For each known-affected product, an action statement	`/vulnerabilities[]/remediations`

The flags[].label field takes exactly five values. They are the same five justifications CISA uses, and the standard defines each one:

Flag label	Use it when (CSAF 2.0 definition, paraphrased)
`component_not_present`	The vulnerable component is not in the product
`vulnerable_code_not_present`	The component is present, but the code behind the vulnerability is not, for example because of compiler options
`vulnerable_code_cannot_be_controlled_by_adversary`	The vulnerable code is present, but it is used in a way that no anticipated attack can reach
`vulnerable_code_not_in_execute_path`	The affected code cannot be reached when the product runs, including unanticipated states
`inline_mitigations_already_exist`	Built-in controls or mitigations stop an attacker from using the vulnerability

For known-affected products, the remediation category is one of vendor_fix, workaround, mitigation, none_available or a fifth value for products that will receive no fix. The standard explicitly allows the last two as action statements, so "no fix exists for this version" is a valid VEX answer as long as you say it.

How do you identify a device and its firmware in the product tree?

Every product is defined once in product_tree with a product_id that status lists and flags refer to. For hardware, a three-level tree of branches works well: vendor, then product_name (the device model), then product_version (the firmware release). Categories such as product_family and architecture cover models that ship several builds.

Each product can carry a product_identification_helper, so a customer's asset tool can match your entry against what it sees on the network. CSAF 2.0 offers these fields:

cpe and purl: the identifiers vulnerability databases and SBOM tools use; see our purl guide for the purl syntax. The validator checks every purl (mandatory test 6.1.13).
model_numbers, serial_numbers and skus: the identifiers on a device label or in a purchase order.
hashes: file hashes of the firmware image, so a customer can prove which build they run.
sbom_urls: a link to the SBOM of that exact release.
x_generic_uris: other identifiers in URI form.

A module inside a device, such as a Wi-Fi module in a gateway, is expressed with relationships (for example default_component_of).

Worked example: what does a minimal CSAF VEX document for one firmware release look like?

The document below is synthetic: Example Devices Ltd, the GW-200 gateway and its firmware are made up, CVE-0000-0001 is a placeholder ID, and the URLs use example.com. It records an engineer's conclusion that a bundled TLS library's vulnerable parser was compiled out of firmware 3.4.1:

{
  "document": {
    "category": "csaf_vex",
    "csaf_version": "2.0",
    "publisher": { "category": "vendor", "name": "Example Devices Ltd", "namespace": "https://example.com" },
    "title": "GW-200 firmware 3.4.1: status for CVE-0000-0001",
    "tracking": {
      "id": "EXD-VEX-2026-0007",
      "status": "final",
      "version": "1",
      "initial_release_date": "2026-11-10T09:00:00.000Z",
      "current_release_date": "2026-11-10T09:00:00.000Z",
      "revision_history": [
        { "date": "2026-11-10T09:00:00.000Z", "number": "1", "summary": "Initial release." }
      ]
    }
  },
  "product_tree": {
    "branches": [{ "category": "vendor", "name": "Example Devices Ltd", "branches": [
      { "category": "product_name", "name": "GW-200", "branches": [
        { "category": "product_version", "name": "3.4.1", "product": {
          "name": "Example Devices GW-200 firmware 3.4.1",
          "product_id": "GW200-FW-3.4.1",
          "product_identification_helper": {
            "model_numbers": ["GW-200"],
            "sbom_urls": ["https://example.com/sbom/gw-200-3.4.1.cdx.json"]
          }
        } }
      ] }
    ] }]
  },
  "vulnerabilities": [{
    "cve": "CVE-0000-0001",
    "notes": [{ "category": "description", "text": "Heap overflow in the TLS session-resumption parser of a bundled library." }],
    "product_status": { "known_not_affected": ["GW200-FW-3.4.1"] },
    "flags": [{ "label": "vulnerable_code_not_present", "product_ids": ["GW200-FW-3.4.1"] }],
    "threats": [{ "category": "impact", "product_ids": ["GW200-FW-3.4.1"],
      "details": "The library is built without session resumption, so the vulnerable parser is not in this firmware." }]
  }]
}

Three details matter in practice:

The filename comes from the tracking IDSection 5.1 lowercases /document/tracking/id and replaces other characters with underscores, so this file must be published as exd-vex-2026-0007.json.
The flag and the threat are deliberate duplicatesOne flag passes the profile test; the impact threat gives a human reader the reason.
A later change is a new revision, not a new documentIf firmware 3.5.0 re-enables the feature and is affected, add the new product to the tree, list it under known_affected with a vendor_fix remediation, raise version to 2, and append a revision-history entry.

The free VEX generator writes a statement of this kind in the browser from a status and justification you choose.

How do customers' tools find your CSAF files?

Section 7 of the standard defines 23 distribution requirements and five roles. A device maker starting out usually aims for the CSAF provider role, then adds signatures to become a trusted provider. The steps, with the requirement numbers from section 7.1:

Serve every document over TLS(requirement 3), make TLP:WHITE documents freely accessible (4), protect TLP:AMBER and TLP:RED documents (5), and do not redirect (6).
Publish one `provider-metadata.json`describing your publisher and where the documents live (7).
Make it discoverablein at least one of three ways: a CSAF: line in your security.txt pointing to it (8; see RFC 9116 for the file format), the path /.well-known/csaf/provider-metadata.json (9), or the DNS name csaf.data.security.<your domain> (10).
Lay out the documentseither as folders per year with index.txt and changes.csv (11–14), or as a ROLIE feed (15–17).
For trusted-provider status, add hash files (18), OpenPGP signatures (19) and the public key (20).

Role (section 7.2)	What it means
CSAF publisher	Meets requirements 1–4 and distributes only its own documents
CSAF provider	A publisher that also meets 5–7, one of 8–10, and either 11–14 or 15–17
CSAF trusted provider	A provider that also meets 18–20
CSAF lister	Lists other parties' provider-metadata locations
CSAF aggregator	Collects and mirrors other providers' documents

The SoftWSP security.txt generator builds the base file; add the CSAF: line yourself. The Apache-2.0 gocsaf tools include a checker to run against your set-up, and CISA publishes its ICS advisories as CSAF 2.0 JSON in the cisagov/CSAF repository, useful real documents to compare against.

Why does this matter 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. No harmonised standard or Commission implementing act had specified CSAF for the SBOM or reporting format as of 10 November 2026.
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.

What is a workable starting process?

Pick one profile to start: VEXIt 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.
Draft VEX statements from your existing SBOM and vulnerability matchesFor each CVE matched against a component version, an engineer records a status and, for "not affected", one of the five flags plus the evidence behind it.
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.
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.
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.

What are the common pitfalls?

Statuses that point at nothing. Every product ID in a status list must be defined in product_tree; mandatory test 6.1.1 fails otherwise.
Contradictory lists. The same product ID in both known_affected and known_not_affected for one vulnerability fails test 6.1.6.
"Not affected" without a flag or impact threat. The document is valid CSAF but not a valid VEX document.
"Affected" without a remediation. Use none_available if there is no fix on the publication date, rather than leaving the field out.
A final document with version 0.x. Test 6.1.17 requires status to be draft for a 0 or 0.y.z version.
Changing a status silently. If the status changes, raise version, update current_release_date and add a revision-history entry, so consumers that read changes.csv pick it up.
A justification with no evidence behind it. A flag is a claim to customers; keep the build configuration, code reference or test that supports it in the PSIRT case file.

Where does AI fit, and what does SoftWSP do?

Choosing a VEX status is an engineering judgement: whether vulnerable code is present, reachable or mitigated in one specific build needs evidence a person has to weigh. SoftWSP does not write VEX statements and does not analyse reachability or exploitability. Its platform extracts an SBOM from a firmware image, writes it as CycloneDX JSON, and matches the components against NVD, CISA KEV, FIRST EPSS and CISA's CSAF ICS advisories, which it reads from the public CISA repository named above. AI then drafts an analysis report from those matches; every claim in the draft cites its component, CVE record, KEV or EPSS entry, and an engineer reviews it. The matched list is the input an engineer triages into VEX statuses; once they have chosen a status and flag, the VEX generator writes CSAF 2.0 VEX or CycloneDX VEX from it.

For hands-on help, see device firmware security and PSIRT as a service.

This guide is general information, not legal advice.

Put this guide to work

ServiceMachine BuildersMachine SBOM and vulnerability report per line.See the service

SBOM & VEXSBOM viewerOpen a CycloneDX or SPDX JSON SBOM and browse its components in a table. Parsing happens in your browser only.Free

Frequently asked questions

What is CSAF 2.0?

The Common Security Advisory Framework (CSAF) Version 2.0 is an OASIS Standard, approved on 18 November 2022, that defines a JSON language for publishing and exchanging machine-readable security advisories. It replaces the older Common Vulnerability Reporting Framework (CVRF) 1.2.

What is VEX and how does it relate to CSAF?

VEX (Vulnerability Exploitability eXchange) is a statement of whether a product is affected by a specific vulnerability. CSAF 2.0 defines VEX as one of its five built-in document profiles, Profile 5: VEX, so a VEX statement can be published as a CSAF document without any extra format.

Does the Cyber Resilience Act require CSAF or VEX?

No. The CRA (Regulation (EU) 2024/2847) requires an SBOM in a commonly used machine-readable format and a vulnerability handling process, but Annex I does not name CSAF, CVRF or VEX specifically. Whether the Commission or ENISA will require or recommend CSAF for the Article 14 reporting channel is to be confirmed.

Which VEX format should a device maker use?

CISA's SBOM resources list four VEX implementations in use: the CSAF VEX profile, OpenVEX, OWASP CycloneDX and SPDX 3.0. Pick the one your SBOM tooling and your customers' scanners already consume; CSAF VEX is the choice if you already publish, or plan to publish, CSAF advisories.

Who already publishes CSAF documents?

Vendors with mature PSIRTs, including several named in OASIS's own CSAF 2.0 statements of use such as Oracle, TIBCO and Germany's BSI, publish CSAF advisories today. Many national CERTs and large software vendors also run a CSAF provider endpoint that can be discovered automatically, per the CSAF 2.0 distribution rules.