CSAF v2.0 for the CRA: Publishing Machine-Readable Security Advisories

From PDF Advisories to Machine-Readable Ones

CRA Annex I Part II requires manufacturers to share information about fixed vulnerabilities once a security update is available, so that users can act on it. Historically, vendors published security advisories as web pages or PDFs — unstructured, hard to consume at scale, and easy for downstream users to miss.

CSAF v2.0 — the Common Security Advisory Framework, an OASIS standard — replaces that with a machine-readable JSON format. Customers' software composition analysis and vulnerability management tools can ingest CSAF documents automatically and determine, without human effort, whether they are affected.

What CSAF Gives You

A CSAF v2.0 document is structured JSON describing one or more vulnerabilities, the products affected, and their status. Its most valuable capability for CRA compliance is the VEX profile (Vulnerability Exploitability eXchange), which lets you state, per product and version, whether a given CVE is:

• Not affected — with a machine-readable justification
• Affected — with recommended remediation
• Fixed — the version where it was resolved
• Under investigation

This dramatically reduces false positives in customer scans. When a CVE appears in a component in your SBOM but your product is not actually exploitable, a VEX "not affected" statement tells every downstream scanner to stop alerting on it.

The CSAF Document Structure

Each CSAF document contains:

• Document metadata — publisher, tracking ID, version, TLP classification, revision history
• Product tree — the products and versions the advisory covers, ideally identified by Package URL (PURL) or CPE
• Vulnerabilities — CVE IDs, CVSS scores, affected/fixed product status, and remediation guidance

Because products are identified with machine-readable identifiers, consumers can match advisories against their own SBOMs automatically.

Publishing: The CSAF Provider Model

CSAF defines how to distribute advisories so tools can discover them. As a CSAF provider you publish:

• Advisory JSON files under a well-known path — conventionally /.well-known/csaf/
• A provider-metadata.json index describing where your advisories live and how they are organised
• Directory listings or a ROLIE feed so automated clients can enumerate and fetch new advisories

Once this is in place, a customer's tooling can poll your CSAF endpoint, pull new advisories, and cross-check them against their deployed versions with no manual step.

How CSAF Connects to Article 14

Article 14 is about reporting actively exploited vulnerabilities to ENISA and national CSIRTs. CSAF is about telling your customers about vulnerabilities and fixes. They are complementary: when you resolve a vulnerability, the final-report obligation to authorities runs in parallel with your duty to disseminate remediation information to users. Publishing a CSAF advisory is the cleanest way to discharge the customer-facing side of that duty, and it feeds directly from the same data — CVE, CVSS, affected versions, fixed version — you already assembled for the regulator.

Getting Started

1. Adopt CycloneDX or SPDX SBOMs so you have machine-readable product and component identifiers to reference.
2. Choose CSAF tooling — the OASIS CSAF project provides open reference tools for generating and validating documents.
3. Stand up a CSAF provider endpoint at /.well-known/csaf/ with a valid provider-metadata.json.
4. Integrate CSAF generation into your vulnerability disclosure workflow so that every published fix produces both a human-readable advisory and a CSAF document.

Enterprise buyers increasingly expect CSAF, and it is fast becoming a marker of CRA maturity. Building the capability now means it is routine — not a scramble — when your first post-CRA advisory has to go out.