Wiki · Concept · Last reviewed June 25, 2026

Common Security Advisory Framework

The Common Security Advisory Framework is a structured, machine-readable format for publishing security advisories about products, vulnerabilities, impact, and remediation.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: AI security, supply chain, CSAF, VEX, SBOM, vulnerability management

Definition

Common Security Advisory Framework (CSAF) Version 2.0 is an OASIS standard for exchanging security advisories as structured information. The OASIS specification describes CSAF as a language for creating, updating, and interoperably exchanging advisory data about products, vulnerabilities, impact status, and remediation. In May 2025, OASIS announced that CSAF v2.0 had also been approved as ISO/IEC 20153.

CSAF belongs near Common Vulnerabilities and Exposures, Common Vulnerability Scoring System, Open Source Vulnerabilities, Vulnerability Exploitability eXchange, CycloneDX, and SPDX. Those artifacts answer adjacent but different questions. A CVE names a vulnerability, CVSS estimates severity, an SBOM names components, VEX states affected status, and CSAF carries advisory evidence in JSON form.

How It Works

A CSAF document is a JSON security advisory. The CSAF 2.0 schema has one mandatory top-level property, document, and two optional top-level properties, product_tree and vulnerabilities. The document section carries metadata, revision history, references, and distribution rules. Product trees identify product names, versions, relationships, groups, and identifiers. Vulnerability entries can include CVE IDs, CWEs, product status, remediations, scores, threats, flags, notes, acknowledgments, and references.

The standard defines profiles so producers and consumers can know which fields are expected for a use case. The profiles include CSAF Base, Security Advisory, and VEX. The VEX profile matters because it lets a supplier or another party assert whether a product is affected by a specific vulnerability, which is useful when SBOM data says a component exists but the actual exploitability depends on configuration, code path, mitigation, or product packaging.

CSAF also includes distribution and discovery rules. CISA's public CSAF repository provides machine-readable Information Technology, Operational Technology, and partner advisories using the OASIS CSAF 2.0 standard. It points to provider metadata and says some partner CSAFs retain original dates and revision history.

Agent Context

AI systems increasingly depend on ordinary software supply chains: Python packages, container images, browser engines, vector databases, orchestration services, MCP servers, APIs, CI runners, identity libraries, and cloud services. When an agent installs a package, edits a lockfile, updates a container, or invokes a tool server, the security question includes whether surrounding components have known vulnerabilities, whether a vendor issued an advisory, and whether the deployed configuration is affected.

CSAF gives agent platforms a cleaner input for vulnerability-aware automation. A dependency bot, coding agent, procurement tool, or AI bill-of-materials system can ingest structured advisory data instead of scraping prose bulletins. That does not make the agent safe. It makes the evidence less ambiguous.

Governance and Safety

Governance should treat CSAF as evidence infrastructure, not as a final verdict. A valid CSAF document can still be stale, incomplete, out of scope, or irrelevant to a particular deployment. A vendor advisory can be authoritative for the vendor's product while saying little about a customer's modified image, private fork, prompt-tool wrapper, model-serving stack, or agent permission set.

A governance-grade CSAF workflow should preserve the advisory URL, publisher, provider metadata, document version, revision history, product identifiers, vulnerability identifiers, product status, remediation text, references, signatures or hashes where available, ingestion time, and the local decision made from it. If an agent acts on a CSAF record, that action should appear in the audit trail.

Defense Pattern

Source Discipline

Claims about CSAF should cite the OASIS standard, the ISO/IEC designation when relevant, and the provider's own advisory repository or metadata. CSAF should not be collapsed into VEX, SBOM, CVE, CVSS, EPSS, KEV, OSV, or a vendor blog post. It can carry or link some of those signals, but the advisory container is not the same as the evidence item inside it.

Spiralist Reading

Spiralism reads CSAF as a repair to advisory prose. A human bulletin can warn and explain. A structured advisory can travel through scanners, procurement systems, agent tools, patch queues, and audit ledgers without asking every intermediary to reinterpret the same paragraph. The point is to make the machine-readable trail strong enough that human judgment can find the right object.

Open Questions

Sources

Return to Wiki