CSAF & VEX Standards#

Without VEX, customers see your scan results and assume you are vulnerable. You answer the same "does CVE-X affect you?" email every quarter, and each of your customers repeats analysis you already did. With VEX, you publish that assessment once, in a form their tooling consumes automatically.

VEX is a concept: a machine-readable statement about whether a vulnerability affects a specific product. It is implemented by three different specifications, and they are not interchangeable. This page explains what distinguishes them, so you can choose what to publish and know what to expect when consuming someone else's.

If you have not yet met the concept, start with What is a VEX Report — sharing vulnerability assessments so downstream consumers don't have to repeat your analysis is the whole point of VEX, and that page covers the four statuses and the five justifications that all three formats share.

What is CSAF?#

A security advisory is a structured statement about a vulnerability: which product it affects, how severe it is, and what to do about it. CSAF (Common Security Advisory Framework)¹ is an OASIS standard for machine-readable security advisories. Where earlier advisories were prose in an HTML page or a PDF, CSAF defines a strict JSON schema so that a consumer's tooling can process an advisory without a human reading it.

CSAF and VEX are two distinct document types within the same CSAF space, and it is worth being precise about which one you mean. CSAF in general is about sharing security advisories — disclosing that a vulnerability exists in a product, at all. A CSAF document consists of:

• Document metadata — publisher identity, TLP classification, tracking id, and a full revision history
• A product tree — the products and versions the advisory concerns, and how they relate to each other
• Vulnerabilities — CVE identifiers, per-product status, remediations, and scores

A formal disclosure of a vulnerability in your own software uses the csaf_security_advisory document category. VEX is a special CSAF profile for a narrower purpose: not disclosing a vulnerability, but stating whether one that is already known affects your product. This profile is indicated by the csaf_vex document category. DevGuard produces both.

The part of CSAF that has no counterpart in the other formats is its distribution model: a vendor publishes a provider-metadata.json at a well-known location, aggregators discover it, and every advisory is served alongside an OpenPGP signature and checksums. Consumers can therefore verify not only the content but its authorship. For example, DevGuard serves a repository's advisories at …/assets/{asset}/csaf/white/{year}/{cve}.json, alongside a detached .asc signature and .sha256/.sha512 checksums, so a consumer's aggregator can fetch, verify and archive them without ever talking to a human. This is what makes CSAF the format regulators reach for.

How the three formats differ#

The essential difference is what a statement is about.

CSAF VEX is product-centric#

CSAF models products and the relationships between them, so a statement can refer to this component as it is used inside that product — an exact dependency path.

Note CSAFPID-0003: it identifies not prismjs in general, but prismjs as reached through this specific chain. Two different paths to the same package get two different product ids and can carry two different statuses. The flags.label carries the machine-readable justification. This makes CSAF the only one of the three standards that keeps a finding's rich, path-based dependency information intact end to end — the same model that shapes how DevGuard itself does vulnerability management. See Transitive Vulnerability Path Analysis.

CycloneDX VEX is component-centric#

CycloneDX attaches the assessment to the component itself, inside the SBOM structure. Like a CSAF document, it is a JSON file — CycloneDX just uses a different structure, one built to travel alongside an SBOM rather than to stand alone. It is the most widely used of the three formats for exchanging vulnerability assessments today, largely because tooling that already produces CycloneDX SBOMs can attach VEX data to them directly.

This is simpler and more widely supported, but the PURL is the whole identity — there is no way to say "affected via one path, not affected via another". Where DevGuard holds two different decisions for one component — say, not affected via one dependency path and accepted risk via another — the CycloneDX export cannot represent both against the same purl. It collapses them into a single entry and keeps whichever decision reflects the higher remaining risk, so a consumer never under-reports.

OpenVEX is minimal#

OpenVEX carries statements as a flat list, designed to be small and embeddable anywhere. Like CycloneDX, it models products and subcomponents, so in terms of functional expressiveness the two are roughly equal. The practical difference is scope: a CycloneDX document can carry the SBOM and the VEX statements together, so you can hand a consumer one file for both. OpenVEX is VEX-only — there is no OpenVEX equivalent of an SBOM, so it always travels alongside a separate inventory document.

Choosing#

The point of publishing any of them#

Publishing the assessment once, in a form your customers' tooling consumes automatically, means the analysis happens where the knowledge is — with you — and propagates downstream instead of being re-derived at every step of the supply chain.

This works in both directions. Your suppliers' VEX documents relieve you of the same redundant analysis, which is why DevGuard consumes upstream sources as well as publishing your own.

What DevGuard does with these standards#

Related Documentation#

• What is a VEX Report — the statuses and justifications all three formats share
• Working with VEX in DevGuard — the practical workflow
• SBOM Standards — CycloneDX and SPDX, the inventory side of the picture
• Open Standards — why DevGuard commits to standard formats
• Why Compliance Matters — the regulatory case for machine-readable disclosure
• Audit Trails — how assessments become evidence

References#

Footnotes#

1. OASIS, Common Security Advisory Framework Version 2.0, https://docs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html ↩