Reference

CSAF 2.1 Concept Mapping

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 maps each Vultron concept to its counterpart in the Common Security Advisory Framework (CSAF) 2.1 draft. It is for readers who convert between the two models, or who need to know how much meaning a conversion keeps. A Vultron concept can map to any part of a CSAF document, not only to document.involvement. The overview explains how a CSAF document relates to a Vultron case, and the coverage differences page lists the concepts with no counterpart.

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.

How to read the tables

Each row has six columns. Vultron concept and CSAF concept name the two sides, and the CSAF side gives its location in the document. Granularity tells how many concepts on one side match how many on the other side. Vultron → CSAF and CSAF → Vultron give the type of mapping in each direction. The two directions can differ: a mapping can be fixed in one direction and need judgment in the other. Proposed change says what could change, or why nothing changes.

Granularity	Meaning
One to one	One Vultron concept matches one CSAF concept.
One to many	One Vultron concept matches two or more CSAF concepts.
Many to one	Two or more Vultron concepts match one CSAF concept.
No match	The concept has no counterpart. The coverage differences page gives it in full.

Mapping type	Meaning
Mechanical	A fixed rule gives the result. No judgment is necessary.
Derived	A rule calculates the result from two or more facts, or from the state at a ledger position.
Interpretive	The result needs judgment or context.
None	No mapping exists in this direction.

A projection is a CSAF document that a participant produces from its copy of a case, as the overview explains. "Vultron → CSAF" is the direction of a projection. "CSAF → Vultron" is the direction of a CSAF document that arrives inside a case, and Vultron could read such content as claims (overview, #5131).

Parties and roles

A Vultron participant is an actor with one or more roles in one case (§2.2 Roles). A CSAF entity is a party in one document, with one category. CSAF states that "the category does not control the role": an entity can act in one action and receive in a different action.

Vultron concept	CSAF concept	Granularity	Vultron → CSAF	CSAF → Vultron	Proposed change
`CaseParticipant`	Entity, `document.involvement.entities[]`	One to one	Mechanical	Interpretive	No change proposed: CSAF entities also include parties that are never participants, such as an `adversary` or the `public`.
`CVDRole` list on a participant	Entity `category`, one value	Many to one	Interpretive	Interpretive	No change proposed: a participant with two or more roles becomes one entity, and the projection selects the category that best fits the actions it records.
`VENDOR`	`vendor`	One to one	Mechanical	Mechanical	No change proposed.
`COORDINATOR`	`coordinator`	One to one	Mechanical	Mechanical	No change proposed.
`REPORTER`	`discoverer` ("It is assume [sic] that the discoverer also reports vulnerabilities.")	One to one	Interpretive	Mechanical	No change proposed: both models put finder and reporter into one role, with opposite names. Vultron retired its `FINDER` role, and the report content or a case note names the finder (ADR-0078). Vultron has no structured field for the finder. A projection gives `discoverer` to a `REPORTER` only when the report content or a case note names that participant as the finder. A coordinator that sends the report of a different party is not the discoverer, so it gets the category of its other roles, or `other`.
`DEPLOYER`	`user`	One to one	Mechanical	Interpretive	No change proposed: a CSAF `user` operates a product, and a Vultron Deployer is a participant that deploys the fix. A `user` that takes no part in the case is not a participant.
`OBSERVER`	`other`	One to one	Mechanical	Interpretive	No change proposed: both are the role that the other values do not give.
`CVE_NUMBERING_AUTHORITY`	No match. `reporting_authority` is "an entity that receives or requires a report, e.g. a national CSIRT". A CSIRT is a Computer Security Incident Response Team.	No match	None	None	No change proposed: a Common Vulnerabilities and Exposures (CVE) Numbering Authority (CNA) assigns identifiers, and a reporting authority receives reports. The two names are similar, but the concepts are different.
`CASE_OWNER`, `CASE_MANAGER`	No match	No match	None	None	No change proposed: these roles control who can change the case, and a CSAF document has no such control. See coverage differences.
Recipient set of a message, calculated from roles and entitlement	Entity group, `document.involvement.entity_groups[]`	One to one	Derived	None	No change proposed: Vultron does not store named groups. A projection makes a group only when the group makes the document shorter, for example the participants with one role, the parties to one embargo version, or the recipients of one message.
Actor profile and inbox	Entity `contact` (`contact_t`: `details`, `email`, `public_openpgp_key_url`, `url`)	One to one	Derived	Interpretive	No change proposed: a CSAF contact tells how to reach a party, and a Vultron actor identifier is an address for protocol messages. A contact is not an actor identity.
Actor Uniform Resource Identifier (URI)	Entity ID, `EID-…`, local to the document	One to one	Derived	None	Undecided: CSAF could let an entity carry an optional identifier that stays the same in different documents, for example a URI. The TC wants an issuing party to copy an involvement list into a different document without a change in meaning, and a stable identifier would let a reader match an entity in two documents. If nothing changes, a projection mints new `EID-` tokens for each document, and a reader matches entities by name and contact only.

Events and timeline

A Vultron case records each completed act as one or more case ledger entries (ADR-0119). The payload of each entry is an ActivityStreams 2.0 (AS2) activity (ADR-0124). A CSAF action is one event in the document.involvement.actions[] timeline. The two have the same shape: an actor, recipients, a time, a type, and an optional link to earlier events.

Vultron concept	CSAF concept	Granularity	Vultron → CSAF	CSAF → Vultron	Proposed change
Case ledger, all entries	`document.involvement.actions[]`, selected events	Many to one	Derived	Interpretive	No change proposed: different purpose. The ledger records every change, and CSAF records the events that the issuing party selects. A projection filters the ledger.
Activity `actor`	`acting_entity_refs`	One to one	Mechanical	Interpretive	No change proposed: a received action is a claim about who acted.
Activity recipients (`to`)	`receiving_entity_refs`	One to one	Mechanical	Interpretive	No change proposed. CSAF forbids one entity as both actor and recipient of one action (test 6.1.64.4). In Vultron, an organization that finds a vulnerability in its own product can be its own Reporter. As the CSAF note to that test advises, a projection then uses two entities for the organization, or leaves the act out.
Activity that refers to an earlier activity, for example `Accept(Offer)` or `inReplyTo`	`referenced_action_ids`	One to one	Mechanical	Mechanical	No change proposed.
Activity identifier, a URI	`action_id`, local to the document	One to one	Derived	None	No change proposed: a projection mints one `action_id` for each activity that it includes.
Two times: the `published` time that the sender claims, and the commit time of the Case Manager (CLP-14-002, CLP-15-005)	`date`, one time	Many to one	Mechanical	Interpretive	No change proposed: one time is sufficient for a documentation model. A projection uses the claimed `published` time, because that is the time that the sender gives for the act (CLP-15-004).
Semantic type of the activity	Action `category`	Many to one	Derived	Interpretive	No change proposed: Vultron has more semantic types than CSAF has categories, so several types share a category. CSAF uses `coordination` for joint work and `notification` for an action with no specific category. The other sections of this page give the mapping of each type.
Act on the whole case	`dl_vuln_ids`, `product_ids`, `group_ids` on an action	One to many	Mechanical	Interpretive	No change proposed: a projection leaves out `dl_vuln_ids`, and the action then applies to all vulnerabilities in the document (test 6.2.56.4). An act on one vulnerability only is an argument to split the case (ADR-0125, proposed).
State at a ledger position, for example an invitation with no answer	Action `status` other than `completed`	One to many	Derived	Interpretive	No change proposed: different purpose. A ledger entry records a completed act, so the entry of each act becomes a `completed` action. The follow-on entries that an act causes (CLP-07-013) go into that action. A projection derives `outstanding`, `deferred`, and `discontinued` from the state at its ledger position. It does not make `attempted`, because a failed delivery is a fact about the outbox, not about the case. It does not make `planned`, because Vultron does not record intentions.

Report management

Vultron state names tell what already occurred. RECEIVED means that the report arrived. CSAF status values tell what occurs now. In CSAF terms, the same fact is an assessment that is in_progress. Most differences in this section are a change of tense, not a disagreement.

The Report Management (RM) states belong to one participant (§6 Report Management (RM) State Machine). In the CSAF rows below, that participant is the actor. The CSAF design proposal notes a difference in perspective for deferred: CSAF records that an actor chose not to act, and RM DEFERRED records that a participant put a valid report aside (#1486, Appendix A.2). In the reading of this crosswalk, the two agree when the participant is the actor of the deferred action.

Vultron concept	CSAF concept	Granularity	Vultron → CSAF	CSAF → Vultron	Proposed change
Report submission, `Offer(VulnerabilityReport)`	`notification`, `completed`, from the sender to the receiver	One to one	Mechanical	Interpretive	No change proposed.
RM `START`	No match	No match	None	None	No change proposed: the participant has not received the report, so there is no event to record.
RM `RECEIVED`	`assessment`, `in_progress`	One to one	Derived	Interpretive	No change proposed: a change of tense. The design discussion records receipt as a `confirmation` instead, which "received or accepted" the action that it refers to (#1486, 6 October 2026). The RM `ACCEPTED` row discusses that value.
RM `VALID`, RM `INVALID`	`assessment`, `completed`	Many to one	Mechanical	Interpretive	No change proposed: CSAF records that the assessment occurred, and the result goes in `metrics`, `threats`, or `summary`. A projection writes the result in `summary`. A participant that finds a report invalid can also record a `dispute` of the `notification`.
RM `ACCEPTED`	`confirmation`, `completed`, which refers to the `notification`	One to one	Mechanical	Interpretive	Undecided: a CSAF `confirmation` means that the actor "received or accepted" the action. Vultron keeps receipt and acceptance as two facts. CSAF could make the two meanings different. If nothing changes, a projection writes in `summary` which of the two a `confirmation` records.
RM `DEFERRED`	`assessment` or `coordination` by the participant, `deferred`	One to one	Derived	Interpretive	No change proposed.
RM `CLOSED`	`completed` or `discontinued`, according to the reason	One to many	Interpretive	Interpretive	No change proposed: a participant closes a report after its work is complete, or when it stops work. The projection selects the status from the case context.
Participant leaves the case before its work is complete	`discontinued` on its open actions	One to one	Derived	Interpretive	No change proposed.

Embargo

Vultron Embargo Management (EM) keeps each embargo in the case's embargo register, one entry for each version (§7.1.1 The Embargo Register). Each participant gives its own embargo consent to each version (ADR-0122). The active embargo has one end time. CSAF records an embargo as an embargo action: "the actor and the receiving entities agree to not disclose the information before the intended disclosure date." The date is not on the action: "The agreed date is the disclosure_date of each vulnerability that dl_vuln_ids names." Vultron also keeps the end of an embargo apart from publication (Embargo Termination is Not the Same as Publication), and CSAF uses one date for both.

Vultron concept	CSAF concept	Granularity	Vultron → CSAF	CSAF → Vultron	Proposed change
Embargo register entry, one embargo version	`embargo` action	One to one	Mechanical	Interpretive	No change proposed for the action itself.
Embargo end time of the case	`vulnerabilities[].disclosure_date`	One to many	Mechanical	Interpretive	CSAF could let an `embargo` action carry its own end date. If nothing changes, one document holds one date for each vulnerability, so a projection shows only the current embargo version, and earlier dates appear only in `summary` text. See proposal 1.
Revised embargo, EM `REVISE` and the next register entry	A new `embargo` action that refers to the earlier `embargo` action	One to one	Derived	Interpretive	CSAF could let an `embargo` action carry its own end date. If nothing changes, the new action changes the `disclosure_date` of the document, and the date of the earlier version is lost. See proposal 1.
Early termination of an embargo, EM `EXITED` before the end time	No match	No match	None	None	CSAF could record the early end of an embargo. If nothing changes, a projection records the end as a `coordination` action and explains it in `summary`. See proposal 2.
Embargo consent `INVITED`	`confirmation` by the invitee, `outstanding`	One to one	Derived	Interpretive	No change proposed.
Embargo consent `AGREED`	`confirmation`, `completed`, which refers to the `embargo` action	One to one	Mechanical	Mechanical	No change proposed.
Embargo consent `DECLINED`	`dispute`, `completed`, which refers to the `embargo` action	One to one	Mechanical	Mechanical	No change proposed.
Embargo consent `TIMED_OUT`, the pocket veto	No match	No match	Interpretive	None	No change proposed: a projection records no action from the invitee, and it explains the time-out in the `summary` of the `embargo` action.
Embargo consent `UNINVITED`	No match	No match	None	None	No change proposed: no event occurred.

Case state

The Case State (CS) model has six dimensions (§8 Case State (CS) Dimensions). Some dimensions are events between parties, and CSAF records them as actions. Others are facts about the vulnerability, and CSAF records them in vulnerabilities[], not in involvement. CSAF also carries Stakeholder-Specific Vulnerability Categorization (SSVC) values in vulnerabilities[].metrics. SSVC and Vultron come from the same team at the CERT Coordination Center (CERT/CC), so their mappings are especially close. The SSVC crosswalk gives the mapping between the CS model and SSVC.

Vultron concept	CSAF concept	Granularity	Vultron → CSAF	CSAF → Vultron	Proposed change
Vendor Awareness (V)	`notification`, `completed`, to the vendor	One to one	Derived	Interpretive	No change proposed.
Fix Readiness (F)	`fix_release`, `completed`	One to one	Mechanical	Mechanical	No change proposed for the mapping. Details of the fix go in `vulnerabilities[].remediations`, which Vultron does not model. CSAF records a fix for each product, and Vultron records F once for each participant. Concern #5140 asks whether Vultron could track F for each vendor and product.
Fix Deployed (D)	`fix_deployment`, `completed`	One to one	Mechanical	Mechanical	No change proposed for the mapping. Concern #5140 asks whether Vultron could track D for each vendor, product, and deployer.
Public Awareness (P)	`vulnerabilities[].disclosure_date` with a past date	One to one	Mechanical	Mechanical	No change proposed. The time of the P event becomes the `disclosure_date`. A `disclosure_date` in the past means that the vulnerability is known to be public.
Exploit Public (X) and Attacks Observed (A), together	SSVC Exploitation value in `vulnerabilities[].metrics`: None for xa, PoC (public proof of concept) for Xa, Active for A	Many to one	Mechanical	Derived	No change proposed. The value Active gives A but does not tell whether an exploit is public, so the reverse mapping leaves X unknown. When the issuing party is aware of active exploitation, the CSAF Vulnerability Report profile says that it SHOULD give it with this metric, as `Active` or `PoC`.
Exploit Public (X)	`vulnerabilities[].threats[]` with `category` `exploit_status`	One to one	Mechanical	Interpretive	No change proposed: both models keep exploit availability as a fact about the vulnerability, not as an event between parties. The `exploit_status` details are free text, so the reverse mapping needs judgment.
Attacks Observed (A)	`observation` action, and the `exploitation` action that it can refer to	One to many	Interpretive	Interpretive	No change proposed. CSAF divides A into two events: the `exploitation` by the attacker and the `observation` by the party that saw it. Vultron never names the attacker, because an attacker is not a participant. A projection records the `observation` and can add an `exploitation` by an `adversary` entity with no name.
Time of the first A event	`vulnerabilities[].first_known_exploitation_dates[]`	One to many	Mechanical	Interpretive	No change proposed. CSAF gives the date for each product, and Vultron gives it for the case.

Content objects

A Vultron case holds reports and notes (Case Model). The VulnerabilityReport object has a content field that can hold any report format, and CSAF is one of the formats. A CSAF document holds its vulnerabilities in vulnerabilities[], each with identifiers, notes, references, and product status.

Vultron concept	CSAF concept	Granularity	Vultron → CSAF	CSAF → Vultron	Proposed change
`VulnerabilityReport` `content`	A full CSAF document, usually with the Vulnerability Report profile, `csaf_vulnerability_report`	One to one	Mechanical	Interpretive	Vultron could identify CSAF content by its `mediaType`, and it could read the process fields of that content as claims by the sender. A claim changes the case only through a Vultron activity, which can be automatic. If nothing changes, an implementation can still read and use the CSAF content, but the protocol does not say how a claim in it, such as a proposed disclosure date, becomes a Vultron activity. Issue #5131 tracks this change.
`VulnerabilityRecord` on a case	`vulnerabilities[]` with `cve` and `ids`	Many to one	Interpretive	Mechanical	Vultron could add a list of vulnerability records to the case, which CM-05-003 already expects. Vultron could also let a `VulnerabilityRecord` carry a CSAF document or a CVE record as its content, with a `mediaType` that identifies the format. The record keeps the identifiers that Vultron uses, and Vultron reads the content as claims. A CSAF document for one vulnerability must also define the products that it refers to (mandatory test 6.1.1, Missing Definition of Product ID), so this change could include a CSAF profile for one vulnerability, without `involvement`, because the case holds the coordination history. If nothing changes, a projection finds the vulnerabilities only in the text of the reports, and it cannot set `dl_vuln_ids` reliably. Issue #5132 tracks this change.
`VulnerabilityRecord` `name` and `aliases`	`vulnerabilities[].cve` and `vulnerabilities[].ids[]`	One to one	Mechanical	Mechanical	No change proposed. Both models treat identifiers from different systems as aliases for one vulnerability (CM-05-009).
`CaseReference`, with tags from the CVE reference vocabulary	`vulnerabilities[].references[]` and `document.references[]`, with `category` `external` or `self`	Many to one	Mechanical	Mechanical	Vultron could add a list of references to the case, which CM-05-004 allows. `CaseReference` exists, but `VulnerabilityCase` has no field for it yet, which is the same gap as vulnerability records (#5132). A projection puts the tag of a reference in its `summary`, because CSAF has no field for it.
Note, with no category	`notes[]`, with a `category` such as `description`, `details`, `faq`, `general`, `summary`, or `other`	One to many	Interpretive	Mechanical	No change proposed: a projection selects the category of each note that it includes.
Advisory draft from the publication pipeline (ADR-0030)	A CSAF document with the Security Advisory or Vulnerability Exploitability eXchange (VEX) profile	One to one	Derived	None	No change proposed: this is a projection at publication.

Distribution and tracking

A CSAF document controls its own distribution with a Traffic Light Protocol (TLP) label and an optional sharing group, and it tracks its own versions in document.tracking. Vultron controls who sees the case through entitlement and the embargo, and the case ledger gives the version of the case.

Vultron concept	CSAF concept	Granularity	Vultron → CSAF	CSAF → Vultron	Proposed change
Entitlement to case content and the embargo	`document.distribution.tlp.label`	Many to one	Derived	Interpretive	No change proposed: a projection derives its TLP label from its content, its recipient, and the case state, as the overview explains. The way TLP could appear in Vultron data and logic is an open concern (#5133). If nothing changes, Vultron cannot enforce a received label that is stricter than its own entitlement rules.
Case	`document.distribution.sharing_group.id`	One to one	Derived	Interpretive	No change proposed. For a multi-party disclosure, CSAF advises "to use one ID per case". A projection mints one UUID version 4 for each case and uses it again, because CSAF requires a version 4 UUID for a closed sharing group.
Projecting participant	`document.publisher`	One to one	Mechanical	Interpretive	No change proposed.
Ledger position of a projection	`document.tracking.version` and `revision_history[]`	One to one	Derived	None	No change proposed: each new projection of the same case is a new revision of one CSAF document, and its revision history names the ledger position.
Case state at the ledger position	`document.tracking.status`: `draft`, `interim`, or `final`	Many to one	Interpretive	None	No change proposed: the status describes the document, not the case. A projection during coordination is usually `interim`, because CSAF expects updates.

Summary

Principle	Statement
Unit of the mapping	A Vultron concept can map to any part of a CSAF document, not only to `involvement`.
Direction	A mapping is often mechanical from Vultron to CSAF and interpretive from CSAF to Vultron, because a received document is a claim.
Tense	Vultron state names tell what already occurred, and CSAF status values tell what occurs now.
Selection	A projection filters the case ledger, and the CSAF timeline holds the events that the issuing party selects.
Facts about the vulnerability	Both models keep exploit availability and public status in the vulnerability data, not in the timeline of events.