An SADP container covering multiple downstream products has a single providerMetadata.dateUpdated timestamp and no per-assertion identifiers on individual affected[] entries. A container is uniquely addressable (by CVE ID + provider orgId), but the individual product-status assertions within it are not.
This makes it impossible to:
- reference or cite a specific product-status assertion independently.
- determine which assertion(s) changed when
dateUpdated rolls. <-- requires consumer work to maintain awarness
- supersede or retract a single assertion without republishing the entire container. <-- more of a consumer concern
- reliably deduplicate or cross-reference a specific assertion when CVE data arrives via multiple channels. <-- less concern, but e.g. Microsoft publishes VEX also, and if there's disagreement between sources, an individual timestamp and ID would help describe the issue
Example
CVE-2026-22610 (record) has a Siemens SADP container with two affected entries. If Siemens ships a fix for one product and updates the container, dateUpdated rolls on both. A consumer cannot tell which assertion changed, when it was evaluated, or whether the other assertion was re-confirmed or left untouched.
Git history could in principle reveal what changed, but this is an unintended side channel, not a designed data contract, and is unavailable to consumers receiving CVE data via API or snapshot.
Proposed resolution
Define a per-assertion identifier, version, and update timestamp on each affected[] entry (or a wrapping statement object), allowing assertions to be individually addressed, timestamped, and versioned. fwiw, OpenVEX addresses this with a per-statement @id, @version, and timestamp.
I suspect a stable ID which persists for the lifetime of the assertion would provide more value and less scope for confusion than a new identifier for each specific version.
An SADP container covering multiple downstream products has a single
providerMetadata.dateUpdatedtimestamp and no per-assertion identifiers on individualaffected[]entries. A container is uniquely addressable (by CVE ID + provider orgId), but the individual product-status assertions within it are not.This makes it impossible to:
dateUpdatedrolls. <-- requires consumer work to maintain awarnessExample
CVE-2026-22610 (record) has a Siemens SADP container with two affected entries. If Siemens ships a fix for one product and updates the container,
dateUpdatedrolls on both. A consumer cannot tell which assertion changed, when it was evaluated, or whether the other assertion was re-confirmed or left untouched.Git history could in principle reveal what changed, but this is an unintended side channel, not a designed data contract, and is unavailable to consumers receiving CVE data via API or snapshot.
Proposed resolution
Define a per-assertion identifier, version, and update timestamp on each
affected[]entry (or a wrapping statement object), allowing assertions to be individually addressed, timestamped, and versioned. fwiw, OpenVEX addresses this with a per-statement@id,@version, andtimestamp.I suspect a stable ID which persists for the lifetime of the assertion would provide more value and less scope for confusion than a new identifier for each specific version.