SBOM Programs Need Vulnerability-Matching Accountability, Not Document Generation Alone
Software bills of materials improve supply-chain transparency, but generating a machine-readable file does not by itself prove vulnerability matching or response. This standards synthesis asks how SBOM programs should be evaluated when component inventory, vulnerability-source mapping, exploitability status, remediation evidence, and build provenance are separate claims. The evidence base combines AlexandrAI graph search, NTIA minimum elements, NIST SSDF, SPDX 3.0.1 conformance, CycloneDX VEX and VDR documentation, OASIS CSAF 2.0, OpenVEX, OSV schema, NVD CPE, CVE JSON record format, SLSA provenance, and OpenSSF Scorecard. The contribution is a Vulnerability-Matching Accountability Chain with ten evidence states from generated SBOM through review cadence. The synthesis finds that SBOM reporting should stop at the strongest verified stage: a document proves inventory; exact identity and version mapping prove matchability; VEX and CSAF-style status prove triage; remediation and provenance prove response applicability. The practical implication is that SBOM dashboards should show match confidence, source coverage, exploitability status, remediation closure, and artifact binding beside generation counts.
Introduction
Software bills of materials are now a familiar answer to software supply-chain opacity. They list the components that make up a software artifact and give producers, purchasers, and operators a shared record for inventory, license, and vulnerability work. The danger is that "we generated an SBOM" can be misread as "we know which vulnerabilities affect this release and what we will do about them." Those are different claims.
NTIA defines an SBOM as a formal record of component details and supply-chain relationships and explicitly frames it as a foundational data layer rather than a complete security solution [[cite:ntiaMinimum]]. NIST's SSDF then shows the response side: organizations should govern third-party components, collect provenance and integrity data, gather vulnerability information, investigate credible reports, and develop remediation plans [[cite:nistSsdf]]. The gap between those sources is the subject of this paper.
This paper asks how SBOM programs should be evaluated when document generation does not itself prove vulnerability matching, exploitability status, or remediation accountability. It contributes a Vulnerability-Matching Accountability Chain that separates generated SBOMs, component identity, version normalization, dependency scope, source coverage, match confidence, exploitability status, remediation, provenance binding, and review cadence.
Methods
This is a conceptual synthesis grounded in standards, official documentation, and related AlexandrAI graph items. I searched the graph with six terms and found one close neighbor: a comparison grid for CycloneDX, SPDX, and SWID. That item chooses formats; it does not model the operational evidence needed after a format is chosen [[cite:sbomGrid]]. An adjacent AI/ML provenance item was screened but excluded from cited support because this paper focuses on ordinary software component vulnerability matching.
The external evidence included twelve search angles: NTIA minimum elements, NIST SSDF, SPDX security profile, CycloneDX VEX/VDR, CSAF 2.0, OpenVEX, OSV schema, NVD CPE, CVE schema, SLSA provenance, in-toto attestation context, and OpenSSF Scorecard. The final cited corpus uses primary standards and official project documentation wherever possible.
I coded each source for the claim it can legitimately support and the overclaim it prevents. The result is not a benchmark. It is a claim discipline model for SBOM programs: public reporting should stop at the strongest stage with evidence, not jump from a generated document to a vulnerability response claim.
Related Work and Novelty Boundary
The prior SBOM format-selection grid is useful but answers a different decision. It recommends CycloneDX for security operations, SPDX for compliance/provenance interchange, and SWID for installed-asset inventory [[cite:sbomGrid]]. This paper begins after that choice: even the best format does not prove that identities, versions, vulnerability sources, exploitability status, and remediation plans are correct.
Build provenance is related because it can bind an SBOM to an artifact, but it is not identical to vulnerability matching. SLSA describes provenance as evidence of where, when, and how an artifact was produced [[cite:slsaProvenance]]. Vulnerability matching additionally asks whether listed components map to advisory sources and response decisions.
SPDX and CycloneDX both expose security-operation affordances. SPDX 3.0.1 has a Security Profile for exchanging information about vulnerabilities, severity, affected software elements, and fix availability [[cite:spdxConformance]]. CycloneDX has VDR for vulnerability disclosure and VEX for exploitability status in product context [[cite:cyclonedxVdr,cyclonedxVex]]. These capabilities support the chain, but none eliminates the need to assess data quality.
Component and Vulnerability Matching Boundary
A generated SBOM begins the process by listing components, but matching starts only when those components can be mapped to vulnerability-source identity systems. NTIA's minimum elements include supplier, component name, version, other identifiers, dependency relationship, SBOM author, and timestamp [[cite:ntiaMinimum]]. Those fields are necessary because vulnerability sources do not all use the same naming scheme.
CPE and OSV illustrate the split. NVD's official CPE dictionary provides agreed product names and is updated as new names are added [[cite:nvdCpe]]. OSV, by contrast, is built around ecosystem-native package identity and affected version ranges [[cite:osvSchema]]. CVE records can include affected products, affected versions, and public references [[cite:cveSchema]]. A program that treats these as interchangeable without confidence labels risks both false positives and missed vulnerabilities.
The first accountability claim should therefore be "we can identify components and versions at the precision required by the vulnerability sources we use." A display name is not enough. For some ecosystems, package identity and version ranges may be precise. For vendor products, CPE or supplier advisories may be more appropriate. For ambiguous components, manual review is not a failure; hiding that manual review is the failure.
Exploitability and Status Boundary
A matched vulnerability is not the end of analysis. CycloneDX VEX focuses on whether a vulnerability in a component can actually be exploited in a specific product context and helps prioritize response [[cite:cyclonedxVex]]. OpenVEX requires a status for a vulnerability with respect to products and components; not-affected statements need either a machine-readable justification or an impact statement, and affected statements should describe remediation or mitigation actions [[cite:openvexSpec]].
CSAF shows the advisory side of this same boundary. The standard includes validation checks that affected or under-investigation products have remediation information, and affected products have score information [[cite:csaf20]]. That does not make every CSAF or VEX assertion automatically true. It means the assertion has a structured place to carry product status, remediation, and supporting rationale.
This boundary prevents two opposite errors. One error is patch panic: every match becomes an urgent fix even when the affected code path is not reachable in the product context. The other error is unsupported suppression: a vulnerability is marked not affected without a reusable justification. VEX is valuable because it can convert both errors into explicit, reviewable claims.
Remediation and Provenance Boundary
NIST SSDF connects matching to action. It calls for gathering vulnerability information from acquirers, users, and public sources, investigating credible reports, and developing remediation plans for vulnerabilities [[cite:nistSsdf]]. That turns a matched vulnerability into an ownership question: who reviewed it, what is the status, what is the plan, and how will closure be verified?
Provenance adds a different but necessary claim. SLSA describes build provenance as verifiable information about where, when, and how software was produced [[cite:slsaProvenance]]. If an SBOM is not bound to the release artifact by digest or attestation, a clean match result can refer to the wrong build. Provenance does not determine exploitability, but it keeps the vulnerability result attached to the artifact it claims to describe.
Repository-level signals are complementary. OpenSSF Scorecard checks source, build, dependency, testing, and maintenance risks and produces risk-weighted scores [[cite:scorecard]]. Those signals help prioritize supplier or project risk, but they should not be substituted for component-level matching. A healthy repository can ship a vulnerable dependency; an unhealthy repository can have no currently known vulnerable dependency. The signals answer different questions.
Vulnerability-Matching Accountability Chain
Table 2 is the paper's main contribution. It names ten stages and the evidence each stage requires. A program may be mature at stage 1 and immature at stage 6. That is normal. What should be avoided is a report that claims stage 8 response evidence from stage 1 document generation.
The chain also lets organizations publish partial progress honestly. "All releases have SBOMs" is a valid stage-1 claim. "All releases are continuously matched against OSV, CVE/NVD, and supplier advisories with confidence labels" is a stronger stage-5 and stage-6 claim. "All affected matches have VEX status and remediation owners" is stronger still. Each claim earns a different level of trust.
Measurement Model
A useful SBOM dashboard should expose the denominators that generation counts hide. The numerator "SBOMs generated" should sit beside artifact binding, component identity confidence, vulnerability source coverage, match age, VEX justification completeness, and remediation closure. Those measures allow operators to see whether the SBOM is feeding response or merely satisfying a procurement checklist.
The metrics should be reported per release and per portfolio. Release-level reporting prevents a team from using one well-instrumented product to mask gaps elsewhere. Portfolio-level reporting helps risk owners identify systemic problems such as missing package identifiers, stale vulnerability sources, unsupported not-affected statements, or unresolved affected findings.
Discussion
The central lesson is that SBOM programs need vulnerability-matching accountability, not file generation alone. Generating a machine-readable document is necessary for automation, but matching requires identity precision, source coverage, version semantics, and confidence labels. Response requires exploitability status and remediation planning. Assurance requires provenance binding and re-scan cadence.
This framing also reduces unnecessary conflict between SBOM advocates and skeptics. Advocates are right that SBOMs create a foundational data layer for software transparency [[cite:ntiaMinimum]]. Skeptics are right that a data layer is not a completed vulnerability-management program. The accountability chain makes both points compatible by keeping claims scoped to evidence.
The chain is format-neutral. CycloneDX may be convenient for VDR and VEX workflows [[cite:cyclonedxVdr,cyclonedxVex]]. SPDX may be better where security data must sit beside licensing, build, AI, dataset, or other profiles [[cite:spdxConformance]]. The accountability question remains the same: what does the program know, how was it matched, what status was assigned, and what action follows?
Limitations
This paper is a standards synthesis, not an empirical audit of SBOM tools. It did not compare scanners, measure false-positive rates, or evaluate real supplier VEX quality. The chain should be tested against production SBOM programs and adjusted where tool limitations make a stage too coarse or too fine.
The cited sources also cover different layers. NTIA and NIST are policy and practice guidance, SPDX and CycloneDX are data-format ecosystems, CSAF/OpenVEX are status/advisory mechanisms, OSV/CPE/CVE are vulnerability-source identity systems, and SLSA is provenance evidence. The paper's contribution is the synthesis across layers, not a claim that any one source mandates the whole chain.
Finally, the model does not settle the difficult problem of vulnerability truth. A component may be misidentified, a version range may be incomplete, a supplier may assert not-affected incorrectly, or a remediation plan may be delayed. The model makes those uncertainties visible rather than pretending SBOM generation removes them.
Conclusion
SBOM programs should be evaluated by vulnerability-matching accountability, not document generation alone. A bill of materials says what the software contains. It does not automatically say which advisories apply, which matches are uncertain, which findings are exploitable, which are fixed, or which exceptions are still open.
The Vulnerability-Matching Accountability Chain supplies a practical reporting language. It lets teams state exactly what they have earned: generated SBOM, normalized component identity, dependency scope, source coverage, match confidence, exploitability status, remediation plan, provenance binding, and review cadence.
The result is a more honest SBOM program. It preserves the value of the SBOM as a foundational transparency layer while preventing the file itself from being mistaken for vulnerability management.