Reference

CSAF 2.1 Coverage Differences

This page is not normative

This page is not considered a core part of the Vultron Protocol as proposed in the main documentation. Although within the page we might provide guidance in terms of SHOULD, MUST, etc., the content here is not normative.

This page lists the concepts that only one of two models has: the Vultron Protocol, or the Common Security Advisory Framework (CSAF) 2.1 draft. It is for readers who need to know what a conversion between the two models cannot carry. The concept mapping gives the concepts that both models have, and the overview explains why the two models differ.

CSAF version in this crosswalk

This crosswalk compares Vultron with one revision of the Common Security Advisory Framework (CSAF) 2.1 draft. The revision is Committee Specification Draft 04 (CSD04), dated 21 October 2026. The source text is commit 29b1e27 of the oasis-tcs/csaf repository. At that commit, the full draft text is csaf_2.1/prose/share/csaf-v2.1-draft.md, and the schema is csaf_2.1/json_schema/csaf.json. CSAF 2.1 is a draft, and the CSAF Technical Committee (TC) of the Organization for the Advancement of Structured Information Standards (OASIS) can change it before it becomes a standard. Statements about CSAF on this page apply to that revision only.

Most items on this page need no change. They come from the different purposes of the two models: CSAF records a disclosure, and Vultron controls how it proceeds. An item that is also a proposal has a Proposal mark, and the proposals page gives it in full. An item that Vultron could change has a Vultron could mark, and the conclusions page links the issue that tracks it. A gap in the Vultron object model is not always a design choice. Some areas of the Vultron object model are not yet defined in detail, and an item says so when that is the reason.

Concepts that Vultron has and CSAF does not

Authority and entitlement

Vultron concept	What it does	Note
Case Owner and Case Manager	The Case Owner makes the case decisions. The Case Manager is the one writer of the case, and it keeps the case ledger.	A CSAF document has one issuing party, and only that party revises it.
Ledger admission	The Case Manager admits or refuses each claim that a participant sends, before it changes the case.	CSAF has no step that accepts or refuses a statement in a document.
Entitlement to case content, with Active and Inert Participants	Only an entitled participant receives the case content. An invitee becomes entitled when it joins and, while an embargo is active, agrees to that embargo (CM-10-004).	CSAF controls distribution of each document with a Traffic Light Protocol (TLP) label, not with entitlement.
Joining and removal: invitation, acceptance, suggest-actor-to-case, and removal (§11 Participant Lifecycle Within a Case)	The case changes its list of participants only through these flows.	A CSAF projection can record a join as a `notification` or `coordination` action, but CSAF has no rules for it.
Case Ownership Transfer	The Case Owner role moves from one participant to a different participant.	No counterpart.

Rules for change

Vultron concept	What it does	Note
Transitions and guards of the Report Management (RM), Embargo Management (EM), and Case State (CS) state machines (§6 Report Management (RM) State Machine, §7 Embargo Management (EM) State Machine, §8 Case State (CS) Dimensions)	The state machines say which change is permitted from each state.	CSAF enforces no order between action status values. The draft gives only an informative common order for a `notification`, and the design proposal calls the status "descriptive and observational".
Model interactions and cascade rules	A change in one state machine can cause a change in a different one, for example an embargo end when the vulnerability becomes known to be public.	No counterpart.
Two times for each event: the time that the sender claims, and the commit time of the Case Manager	Vultron keeps the claim and the record apart (CLP-14-002, CLP-15-005).	CSAF has one `date` for each action.

Embargo detail

Vultron concept	What it does	Note
Versions in the embargo register	The register keeps each proposed, revised, and ended embargo.	Proposal. A CSAF document holds one disclosure date for each vulnerability, so the dates of earlier versions are lost. See proposal 1.
Early termination of an embargo (Early Termination)	An embargo can end before its end time.	Proposal. CSAF has no way to record it. See proposal 2.
Consent of each participant to each version, with deadlines to answer (RSVP deadlines) and the pocket veto (§9 Participant Embargo Consent (PEC) State Machine)	Vultron records who agreed to which version, and what occurs when an invitee does not answer.	A projection records agreement as `confirmation` and refusal as `dispute`. CSAF has no deadline for an answer.
Embargo policies and default embargoes	An actor publishes its preferred embargo terms, and a case can start with a default embargo.	No counterpart.
Embargo end apart from publication (Embargo Termination is Not the Same as Publication)	The end of an embargo and the public disclosure of the vulnerability are two events.	Proposal. CSAF uses `disclosure_date` for both. See proposal 1.

Case structure and integrity

Vultron concept	What it does	Note
Case ledger with a hash chain and a genesis hash	Each entry includes the hash of the entry before it, so a participant can detect a change to the history.	CSAF protects a whole document with signatures and hashes at distribution. It does not link the actions in a timeline.
Participant case replicas	Each participant keeps a copy of the case that the ledger keeps current.	A CSAF document is a copy at one time. It is not kept current.
Parent, child, and sibling cases: split and merge (Case Splitting and Merging)	The protocol defines how a case divides into child cases or joins a different case (ADR-0105, and ADR-0125, which is proposed). The implementation is planned (#3702, #4242).	CSAF documents can refer to other documents, but CSAF has no concept of a split or a merge.
Report and case as different objects	One case can hold many reports, and one report can describe many vulnerabilities (CM-05-006).	One CSAF document holds all of its vulnerabilities.

Concepts that CSAF has and Vultron does not

Products and remediation

CSAF concept	What it does	Note
`product_tree`: branches, full product names, relationships, and product groups	Identifies each product and version that a document refers to.	Vultron does not describe products. A description of products is the purpose of CSAF.
`vulnerabilities[].product_status`, with lists such as `known_affected`, `known_not_affected`, `fixed`, `under_investigation`, `recommended`, and `unknown`	Gives the status of each product for each vulnerability.	Vultron tracks whether a fix is ready (F) and deployed (D) once for each participant, not for each product. Concern #5140 asks whether Vultron could track F for each vendor and product, and D for each vendor, product, and deployer.
`vulnerabilities[].remediations[]`, with categories such as `vendor_fix`, `workaround`, `mitigation`, `no_fix_planned`, and `optional_patch`	Describes each fix or workaround and the products it applies to.	Vultron records that a fix is ready, not what the fix is.
`vulnerabilities[].flags[]`, with the Vulnerability Exploitability eXchange (VEX) justifications	Tells why a product is not affected.	No counterpart.

Vulnerability detail

CSAF concept	What it does	Note
`vulnerabilities[]` as a structured object	Holds identifiers, dates, notes, references, metrics, threats, and product status for each vulnerability.	Vultron could add vulnerability records to the case, with CSAF or Common Vulnerabilities and Exposures (CVE) content. The Vultron object model has not yet reached this depth, and this gap is recognized. See the concept mapping. Issue #5132 tracks this change.
`vulnerabilities[].metrics[]`: Common Vulnerability Scoring System (CVSS), Exploit Prediction Scoring System (EPSS), Stakeholder-Specific Vulnerability Categorization (SSVC), and qualitative severity	Gives scores and ratings for each vulnerability.	Vultron does not record scores. The SSVC Exploitation value maps to the CS model, as the concept mapping shows.
`vulnerabilities[].threats[]` with `impact` and `target_set`	Describes the effect of a vulnerability and the products or users at risk.	No counterpart. The `exploit_status` category maps to Exploit Public (X).
`document.aggregate_severity`	Gives one severity for the whole document.	No counterpart.
`document.acknowledgments` and `vulnerabilities[].acknowledgments`	Names the people and organizations that receive public credit. In the Vulnerability Report profile, no acknowledgments means that the discoverer does not want public credit.	Undecided: Vultron could record which participants want public credit (#5135). CSAF acknowledgments are not linked to involvement entities.

Parties and events

CSAF concept	What it does	Note
Entity category `adversary`, and the `exploitation` action	Names a party that acts against the others, identified or not, and records its use of the vulnerability.	An attacker is never a Vultron participant. Vultron records only that attacks were observed (A).
Entity category `multiplier`	Names a party that uses or distributes data about a vulnerability.	No counterpart.
Entity category `public`	Names the general public as a party.	In Vultron, public awareness is the P dimension, not a party.
Entity category `reporting_authority`	Names a party that receives or requires a report, such as a national Computer Security Incident Response Team (CSIRT).	No counterpart. Such an authority can be a Vultron participant with a different role, or the recipient of a projection.
Action status `planned` and `attempted`	`attempted` records an action that did not reach its recipient. The draft gives `planned` the same definition as `outstanding`: a party waits for the action.	Vultron records completed acts only. A failed delivery is a fact about the outbox, not about the case.

Documents and distribution

CSAF concept	What it does	Note
Profiles: CSAF Base, Security Incident Response, Informational Advisory, Security Advisory, VEX, Deprecated Security Advisory, Withdrawn, Superseded, and Vulnerability Report	Each profile sets the required fields for one type of document.	Vultron has no document types. A projection selects a profile.
TLP labels on each document	Tells the recipient how far it can share the document.	Vultron has no labels. The way TLP could appear in Vultron data and logic is an open concern (#5133). See the overview.
Document language and translations	Gives the language of a document and links to its translations.	No counterpart.
Distribution requirements: provider metadata, feeds, signatures, and access control for restricted labels	Tells how an issuing party publishes documents and how a reader finds and verifies them.	Vultron delivers messages to inboxes. Publication of a projection is outside the protocol.
CSAF Modifier and converters	A party that changes a document of a different party makes a new document with a new tracking ID and refers to the original.	No counterpart.