Repository navigation
Proposal: show SRAC safety context beside SBOM vulnerability results #3111
Description
Proposal
Add an optional experimental input for Safety Relevance Assertion Capability (SRAC) records when OSV-Scanner analyzes an SPDX or CycloneDX SBOM, allowing externally authored safety context to appear beside vulnerability results.
An illustrative command could be:
osv-scanner scan --sbom sbom.json --srac assertions.srac.json --format jsonThe exact interface is open to discussion. A minimal workflow would:
- validate the SRAC schema, integrity metadata, and internal references;
- correlate assertions with the SBOM packages OSV-Scanner analyzes using package URL, SBOM reference, version, or artifact digest;
- add externally authored safety relevance, assertion lifecycle/review state, and optional change-impact status to machine-readable output;
- expose unmatched, ambiguous, invalid, and stale assertions explicitly; and
- leave OSV vulnerability severity, matching, remediation, and exit behavior unchanged by default.
SRAC tooling validates and transports decisions from an authorized safety process. OSV-Scanner must not infer a safety classification, approve a decision, or interpret missing context as “not safety-related”.
Acceptance criteria
- Context appears only for deterministically matched, validated assertions.
- Output records which identifier established the match.
- Unknown, invalid, stale, ambiguous, and unmatched states remain distinct.
- Existing vulnerability results and default exit behavior are unchanged.
- The assertion digest and provenance remain auditable.
- A synthetic example and positive/negative tests document the behavior.
Context
- Eclipse tracking issue: Proposal: Define a minimum SRAC profile for an S-CORE pilot eclipse-score/score#3282
- CycloneDX discussion: Proposal: CycloneDX Safety Perspective for SRAC and safety impact workflows CycloneDX/specification#1122
The prototype demonstrates SPDX/CycloneDX correlation, integrity checks, enrichment reports, change-impact records, and fail-closed behavior. Its SPDX mapping follows current 3.1-development FunctionalSafety concepts; these are development/proposal references, not claims of released normative support.
Would maintainers consider a companion sidecar input useful, or should such enrichment remain a downstream post-processing concern?
Activity
Ly-Joey commentedon Oct 2, 2026
Hi @devashridatta-dotcom, thank you for the proposal!
osv-scanner's scope mainly lies in extracting software inventories and matching them against the OSV.dev database to report known vulnerabilities.
The SRAC input you proposed does not affect inventory extraction or vulnerability matching, and is instead validating and linking external metadata onto the scan results.
We are thinking this might be better suited for downstream post-processing using our readily available machine-readable output (via e.g.
--format json).We also see that you are actively working with CycloneDX and SPDX (both of which are supported SBOM formats in osv-scanner to model your proposal in CycloneDX/specification#1120, spdx/spdx-3-model#1436, and the like.
Rather than maintaining a separate sidecar format in
osv-scanner, we would prefer to revisit this once it is part of a widely adopted upstream SBOM/VEX standard that we can extract from the SBOM files natively.We are closing this issue as not planned for now, but please let me know if I have misunderstood anything!
devashridatta-dotcom commentedon Oct 2, 2026
Hi Joey, thank you for the clear explanation. Your understanding is correct: SRAC should not change OSV-Scanner’s inventory extraction, vulnerability matching, severity, or affected-status decisions.
The current prototype can operate as downstream post-processing: it consumes machine-readable vulnerability results together with externally authored safety assertions, validates and correlates them, and produces an enriched report without modifying the original OSV results.
I understand and agree with the preference not to introduce a separate format into OSV-Scanner before the semantics are available through a sufficiently adopted upstream SPDX/CycloneDX representation. I’ll focus the current work on the standards and downstream integration path, and we can revisit native extraction once that representation is released and supported.
Thank you for reviewing the proposal and clarifying the appropriate boundary.
devashridatta-dotcom commentedon Oct 23, 2026
Hi @Ly-Joey, I'd like to revisit this proposal in light of recent upstream standards progress.
When this issue was closed, the feedback was that OSV-Scanner would prefer to revisit the idea once the metadata was represented through adopted SPDX/CycloneDX standards rather than a separate sidecar format.
Since then, the relevant SRAC/safety assertion concepts have been incorporated into SPDX and CycloneDX workstreams, reducing the need for a proprietary sidecar representation and enabling extraction directly from supported SBOM documents.
Given that the primary concern was waiting for upstream standardization, would the maintainers be open to reconsidering support for exposing safety relevance/assertion metadata already present in SPDX/CycloneDX SBOMs alongside vulnerability results?
To be clear, the intent remains unchanged:
no impact on vulnerability matching or severity determination;
no inference of safety relevance by OSV-Scanner;
presentation of standards-based metadata already present in the SBOM;
preservation of existing exit-code behavior.
If helpful, I can also draft a more concrete proposal showing how the standardized SPDX/CycloneDX fields could be mapped into OSV-Scanner JSON output.