Explanation

CSAF 2.1 and Vultron

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 explains how the Common Security Advisory Framework (CSAF) 2.1 draft and the Vultron Protocol relate to each other. It is for readers who know one of the two models and want to know how the other one fits with it. These readers include members of the CSAF Technical Committee (TC) of the Organization for the Advancement of Structured Information Standards (OASIS). It describes three relations between a CSAF document and a Vultron case, and it gives a summary of each area where the two models meet. Three other pages give the detail: the concept mapping, the coverage differences, and the proposals. The conclusions page gives the result and the follow-up work.

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.

Why this comparison exists

CSAF is a machine-readable format for security advisories, published by OASIS. CSAF 2.0 recorded the parties in a disclosure with a short involvements list on each vulnerability. CSAF 2.1 replaces that list with one document.involvement object: a list of entities, optional entity groups, and a timeline of actions between the entities.

The TC started this change from Vultron. The issue that opened the work, oasis-tcs/csaf#1486, says: "As a starting point, we can use Vultron". The TC meeting of 29 July 2026 recorded the approach: study the Vultron project and its states, then design the involvement model from the start. Because the TC used Vultron as an input, many concepts on the two sides are close, and a crosswalk can show where they agree and where they do not.

Different levels of abstraction

CSAF and Vultron work at different levels of abstraction. CSAF records what happened in a disclosure. Vultron controls how a disclosure proceeds.

A design proposal for the CSAF 2.1 involvement model, by a TC member, states this difference itself. Its informative appendix "Comparison with Vultron" (comment on #1486, 14 August 2026) says:

The CSAF involvement model has a different purpose. It is a documentation model: it records interactions that were observed to occur, so that a reader of an advisory can reconstruct who coordinated with whom about what.

A later comment by the same author (25 August 2026) adds that the purpose of involvement "is not to describe all involvements, but to allow a publishing party to describe selected involvements they consider relevant for their audience."

Vultron has the other purpose. Its state machines for Report Management (RM), Embargo Management (EM), and Case State (CS) state which changes are permitted and who can make them. Its case ledger records every change to the case, not a selection. Neither purpose is better than the other. The difference explains most of the gaps on the other pages, and it tells which gaps to keep.

How a CSAF document relates to a Vultron case

A CSAF document can relate to a Vultron case in three ways:

Relation	In Vultron
A CSAF document replaces the case	Not used.
A CSAF document travels inside the case	Used today. A report can carry a CSAF document, and a participant can read it and use it. The participant reads the content as claims by the sender, and the content changes the case only through Vultron's own activities.
The case produces a CSAF document	Planned.

A CSAF document does not replace the case

A CSAF document is not the case of record in Vultron. The reasons come from the CSAF design.

CSAF property	Consequence for a case of record
The action `status` has no state machine. The design proposal calls it "descriptive and observational", and the draft gives only an informative common order for a `notification`.	CSAF cannot hold the rules that decide which change is permitted.
The involvement timeline holds selected events.	A case of record holds all events.
One issuing party publishes each document.	A case has many participants, and each one writes to it through the Case Manager.
Entity identifiers, action identifiers, and the `dl_vuln_id` of a vulnerability are local to one document.	A case needs identifiers that stay the same in all messages.
CSAF has no rule to merge documents from different issuing parties.	A case combines the contributions of all participants.
Only the issuing party revises a CSAF document. A different party that changes it issues a new document (CSAF Modifier).	A case has shared authority to change it, which Vultron gives to the Case Owner and the Case Manager.

For a small case between two parties, an exchange of CSAF documents can be sufficient without Vultron. Vultron becomes necessary when more parties, an embargo, or a disagreement make the rules for change important.

A CSAF document can travel inside a case

A participant can send a CSAF document as the content of a Vultron report, for example Offer(VulnerabilityReport) with the CSAF document in content. The CSAF 2.1 Vulnerability Report profile is made for this use. That profile "SHALL be used to exchange a vulnerability report during the Coordinated Vulnerability Disclosure (CVD) process", and its Traffic Light Protocol (TLP) label SHOULD be TLP:AMBER.

Some fields of such a document describe the process, for example involvement, disclosure_date, the TLP label, and the Stakeholder-Specific Vulnerability Categorization (SSVC) exploitation value. This crosswalk proposes three rules for those fields:

A receiving participant SHOULD read these fields as claims by the sender.
A receiving participant MUST NOT change the case state from the document content, except through Vultron's own activities.
A receiving participant MAY make the change from a claim to an activity automatic.

For example, a disclosure_date in a received report can cause an embargo proposal with that date. The proposal then goes through the normal embargo process, and the case ledger records the result. These rules are proposals for Vultron, not current requirements. The concept mapping gives them as "Vultron could" rows, and issue #5131 tracks them.

A case can produce a CSAF document

A Vultron participant could produce a CSAF document from its copy of the case. This crosswalk calls such a document a projection. A projection can occur at two times:

Time	Example	Use
At publication	A CSAF Security Advisory or a CSAF Vulnerability Exploitability eXchange (VEX) document	The public record of the vulnerability. The publication pipeline (ADR-0030) defines a draft, review, and submit pipeline for advisory artifacts, and a CSAF document can be one output of its draft step.
During coordination	A CSAF Vulnerability Report for a party that does not use Vultron	A bridge to a vendor, a national Computer Security Incident Response Team (CSIRT), or a reporting authority outside the case.

A projection during coordination copies embargoed information out of the protocol. For this reason, a projection SHOULD NOT include information that the recipient is not entitled to see. Each projection also states the ledger position that it shows, because the case continues to change after the projection. The involvement timeline of a projection is a filtered view of the case ledger. That agrees with the CSAF design, in which the issuing party selects the events that its audience needs. These rules are proposals for Vultron, not current requirements. Issue #5134 tracks the work to produce projections.

TLP marks a projection, not a case

Vultron has no TLP labels. It controls who sees what through the participants that are entitled to the case and through the embargo. This crosswalk takes the position that TLP becomes necessary only when information goes out of Vultron, which occurs in a projection. Concern #5133 tracks that position, and Idea #2564 asks whether Vultron messages could carry TLP fields.

For this reason, a TLP label belongs to one projection. Its value depends on the content of the projection, on the recipient, and on the case state. Different recipients can receive different projections of the same case at the same time. For example, an observer can receive a projection marked TLP:RED, a coordinator one marked TLP:AMBER, and a vendor one marked TLP:AMBER+STRICT.

TLP label	Fit for a projection
`TLP:AMBER+STRICT`	The usual fit before public disclosure. The recipient can share only inside its own organization.
`TLP:AMBER`	Fits only when the recipient can also share with its clients on a need-to-know basis. That sharing occurs outside the case, so Vultron cannot record it. One Vultron way to add a party is the suggest-actor-to-case flow. The CSAF Vulnerability Report profile recommends `TLP:AMBER` "to promote sharing on a need-to-know basis within the vendor's or coordinator's organization and, where appropriate, their clients". The default label of CSAF is `CLEAR`.
`TLP:RED`	Fits only an observer. A `TLP:RED` recipient cannot tell its own team to act on the information.
`TLP:CLEAR`	Fits a projection with the content of a public advisory, after the vulnerability is known to be public.

A projection can be TLP:CLEAR because it selects its content. The full case history, with each message between participants and its time, can stay restricted after the advisory is public. A more detailed projection of the same case can need a stricter label at the same time.

Terminology for TLP and public status

A TLP label applies to a document, not to a case. The correct statement is "this document, which describes information derived from the case, is TLP:CLEAR". The statement "the case is TLP:CLEAR" is not correct.

In the same way, public status applies to the vulnerability, not to the case. The correct statement is "the vulnerability described in the case is known to be public". This agrees with the Public Awareness (P) dimension of the CS model.

When a received CSAF document has a label that is stricter than the Vultron entitlement rules, Vultron cannot enforce that label. For example, a TLP:RED document can arrive in a case with five participants. Only the policy of the receiving participant can obey the label. This is a known limit, and concern #5133 tracks it.

Summary by area

The table gives one row for each area where the two models meet. Similarity is Same (same concept and shape), Close (same concept, different shape), or Divergent (same area, conflicting meaning). Proposed change says what could change, or why nothing changes. The links go to the detailed rows.

Area	Similarity	Proposed change
Parties and roles	Close	No change proposed. Both models put finder and reporter into one role with different names. The Reporter role and the CSAF `discoverer` category are the same choice.
Events and timeline	Close	No change proposed. A CSAF action has the same shape as an ActivityStreams activity: an actor, recipients, a time, a type, and a referenced earlier event. Undecided: CSAF could let an entity carry an identifier that stays the same in different documents.
Report management	Close	No change proposed. Vultron state names tell what already occurred, and CSAF status values tell what occurs now. Undecided: CSAF `confirmation` puts receipt and acceptance into one value.
Embargo	Close	CSAF could let an `embargo` action carry its own end date, and CSAF could record the early end of an embargo. See the proposals.
Case state	Close	No change proposed. Both models keep exploit availability as a fact about the vulnerability, not as an event between parties.
Content objects	Close	Vultron could add vulnerability records to the case, with CSAF or Common Vulnerabilities and Exposures (CVE) content. Vultron could read process fields in a received CSAF document as claims. See #5132 and #5131.
Distribution and tracking	Divergent	No change proposed. A projection would derive its own TLP label. The way TLP could appear inside Vultron is an open concern (#5133).

The coverage differences page lists the concepts that only one of the two models has.