Explanation

CSAF 2.1 Crosswalk: Conclusions

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 gives the conclusions of the comparison between the Common Security Advisory Framework (CSAF) 2.1 draft and the Vultron Protocol. It is for readers who want the result of the crosswalk without its detail, and for readers who want to follow the work that comes next. Each follow-up item links to the issue that tracks it. The overview, the concept mapping, the coverage differences, and the proposals give the detail.

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.

What the comparison shows

CSAF and Vultron work at different levels of abstraction. CSAF records what happened in a disclosure, and Vultron controls how a disclosure proceeds. A design proposal for the CSAF involvement model, by a member of the CSAF Technical Committee (TC), states the same difference in an informative appendix: the CSAF involvement model is "a documentation model". For this reason, most gaps are not defects on either side. They are the result of the different purposes.

The two models are close where they meet. A CSAF action has the same shape as a Vultron activity: an actor, recipients, a time, a type, and a link to earlier events. The CSAF entity categories and the Vultron roles cover most of the same parties, and both models put finder and reporter into one role. Both models also keep exploit availability and public status as facts about the vulnerability, not as events between parties.

The comparison gives three relations between a CSAF document and a Vultron case:

Relation	Conclusion
Replacement	A CSAF document is not the case of record. It holds selected events, has one issuing party, and has no rules for change.
Nested content	A CSAF document can travel inside a case as the content of a report, and Vultron could read its process fields as claims by the sender.
Projection	A participant could produce a CSAF document from its copy of the case, at publication and during coordination.

Where each side can improve

The largest gap on the CSAF side is the embargo. A CSAF document cannot show the date that each earlier version of an embargo set, and the draft does not say how to record an early end of an embargo. The proposals page gives two changes that would close this gap.

The largest gap on the Vultron side is depth in the object model. CSAF describes each vulnerability, each product, and the status of each product. Vultron does not yet hold vulnerability records on the case, and it tracks the fix path once for each participant. The Vultron object model has not reached that depth yet. These gaps are recognized, and they are not decisions to leave the detail out.

Traffic Light Protocol (TLP) labels are a gap of a different type. Vultron controls access through entitlement and the embargo, and CSAF controls it through a label on each document. A label becomes necessary when a projection leaves the case, and the way Vultron handles labels is an open concern.

Follow-up work

All follow-up items are part of the Vultron Epic #5130 CSAF 2.1 crosswalk and interoperability.

Changes Vultron could make

Issue	Change	Source
#5131	Vultron could identify CSAF content in a report by its `mediaType`, and read its process fields as claims by the sender.	Overview
#5132	Vultron could add vulnerability records to the case, with CSAF or Common Vulnerabilities and Exposures (CVE) content.	Concept mapping
#5134	Vultron could produce a CSAF document from the copy of a case that a participant keeps.	Overview
#5133	Vultron could define how TLP labels appear in its data and logic. This item is a concern.	Overview
#5140	Vultron could track the fix path at the granularity of products and deployers. This item is a concern.	Below
#5135	Vultron could record which participants want public credit. This item is undecided.	Coverage differences

Changes CSAF could make

The TC decides on changes to CSAF. Issue #5137 tracks the decision whether to send the proposals to the TC, for example as comments in the public review of the draft.

The fix path and products

The chain from a case to a deployment is longer in reality than in the Vultron model. A case holds vulnerabilities, a vulnerability affects the products of vendors, and deployers install the fix for each product. The Vultron vendor fix path tracks Vendor Awareness (V), Fix Readiness (F), and Fix Deployed (D) once for each participant (§8.1 VFD — Vendor Aware, Fix Ready, Fix Deployed).

Each of the three events has a different natural unit:

Event	Natural unit	Reason
Vendor Awareness (V)	One vendor	A vendor learns of the vulnerability once.
Fix Readiness (F)	One vendor and one product	A vendor with several affected products can have a fix ready for one product and not for another.
Fix Deployed (D)	One vendor, one product, and one deployer	Each deployer installs the fix for each product at its own time.

A case with several vulnerabilities multiplies each unit again. CSAF already records status at this granularity, in vulnerabilities[].product_status and vulnerabilities[].remediations.

Tracking at this granularity could increase the state space very much. It could also bring the Vultron model of the process closer to the real process. The page Limitations and Future Work already describes D as a process that spreads through many deployments, and it suggests a roll-up of many facts into one event. Concern #5140 tracks the question.

Summary

Principle	Statement
Purpose	CSAF records a disclosure, and Vultron controls it. Most gaps come from this difference.
Shape	A CSAF action and a Vultron activity have the same shape.
Relation	A CSAF document is nested content or a projection of a case, never its replacement.
CSAF gap	The embargo needs its own end date and a way to record an early end.
Vultron gap	The object model needs vulnerability records and possibly product-level fix tracking.
Labels	A TLP label belongs to a projection, and Vultron has yet to define how it handles labels.