Software Bill of Materials , Beyond the Mandate

A Software Bill of Materials is a structured inventory of the components that comprise a software product , the open-source libraries, commercial dependencies, and internal modules that together constitute the software's functional implementation. The US Executive Order 14028, the EU Cyber Resilience Act, and sector-specific regulatory requirements have driven significant SBOM adoption in recent years, with many enterprises now requesting SBOMs from their software vendors as a standard assessment activity. What these mandates have produced is widespread SBOM generation without equivalent emphasis on SBOM quality, currency, or actionability , the document exists, but it frequently does not serve the risk management purpose it is supposed to enable.

The currency problem is the most immediate SBOM quality issue. Software products evolve continuously , dependencies are added, updated, and removed with each release. An SBOM generated six months ago describes the component set of a six-month-old release. If the enterprise is running the current version of the software, the six-month-old SBOM may not accurately represent the components actually deployed. For vulnerability management purposes, an SBOM that does not reflect the current deployed version is an inventory of the wrong components. The SBOM should be version-specific and should be updated with each release.

The vulnerability status gap is the second quality dimension. An SBOM that lists components and versions without vulnerability status information is a component inventory, not a risk management document. The enterprise that receives an SBOM with 847 components must independently query a vulnerability database , NVD, OSV, or equivalent , to determine which components have known vulnerabilities. An SBOM with vulnerability status information , VEX (Vulnerability Exploitability eXchange) annotations , tells the consumer which known vulnerabilities affect the listed components, which are in components the vendor has confirmed are not exploitable in their deployment, and which have been remediated. The combination of SBOM and VEX provides an actionable vulnerability picture that an SBOM alone does not.

Why this matters

SBOM quality matters for TPRM because an SBOM that is stale, incomplete, or lacks vulnerability status information provides the appearance of supply chain transparency without the substance. The enterprise that collects SBOMs from vendors and stores them without reviewing their currency, completeness, and vulnerability implications has a filing cabinet full of compliance artifacts and no additional supply chain risk intelligence.

• SBOM collected without currency verification , six-month-old SBOM for current software
• No vulnerability status , SBOM without VEX requires independent vulnerability query
• No SBOM review process , documents collected but not analysed
• Known vulnerabilities in SBOM not actioned , listed but not tracked for remediation
• License information absent , compliance and IP risk not addressed

What good looks like

Mature SBOM programmes request version-specific SBOMs with each major release, review SBOMs for known critical vulnerabilities using automated tooling, request VEX information for components with known vulnerabilities, and track SBOM currency as a programme health metric.

• Version-specific SBOM tied to the deployed software version
• Automated vulnerability scanning of received SBOMs against NVD/OSV
• VEX request for components with known vulnerabilities , exploitability context
• License review for open-source license compliance
• SBOM currency tracking , age of SBOM relative to deployed version

Tooling

SBOM Analysis , Dependency-Track, Grype, Trivy for SBOM vulnerability scanning

SBOM analysis tools can ingest CycloneDX or SPDX format SBOMs and automatically scan their components against vulnerability databases , identifying known vulnerabilities in listed components without requiring manual database queries. Dependency-Track provides persistent SBOM management with automated vulnerability monitoring. For TPRM programmes receiving SBOMs from vendors, these tools convert the document into an actionable vulnerability picture.

VEX Tools , OpenVEX, CycloneDX VEX for vulnerability exploitability exchange

VEX documents provide vulnerability exploitability context alongside SBOM component lists , specifying which known vulnerabilities in listed components are not exploitable in the vendor's deployment configuration. Requesting VEX alongside SBOM for components with known critical vulnerabilities converts a vulnerability list into an actionable remediation priority.

Governance challenges

The governance challenge with SBOM programmes is the volume and tooling requirement. Large software products may have hundreds or thousands of components. Manual review of an 847-component SBOM against vulnerability databases is not a viable approach. Automated SBOM analysis tooling is the governance mechanism that converts SBOM collection from a compliance activity into a risk intelligence activity.

• Implement automated SBOM analysis tooling for all received SBOMs
• Request version-specific SBOMs tied to deployed version
• Request VEX for components with known critical vulnerabilities
• Track known vulnerabilities identified in SBOMs for vendor remediation
• Set SBOM currency standard , SBOMs older than 90 days flagged as potentially stale

If you are a small team

Take the most recently received SBOM from your highest-risk software vendor. Run it through Grype or Trivy , both are free, open-source tools that can scan SBOMs against vulnerability databases in minutes. Review the output for critical and high-severity vulnerabilities. Then check when the SBOM was generated and whether it is version-specific to your deployed version. That fifteen-minute analysis will produce more actionable supply chain intelligence than confirming the SBOM was provided.

• Run received SBOMs through Grype or Trivy for vulnerability scan
• Check SBOM currency , generation date vs deployed software version
• Request VEX for critical vulnerabilities identified
• Track vendor remediation of SBOM-identified critical vulnerabilities

What to require

Ask directly:

"Can you provide a version-specific SBOM in CycloneDX or SPDX format tied to the release we are running , and for any components with known critical vulnerabilities, can you provide VEX documentation confirming exploitability status in your deployment configuration?"

Expect as evidence

• Version-specific SBOM in standard format (CycloneDX or SPDX)
• VEX documentation for components with known critical vulnerabilities
• SBOM generation process and update cadence
• License information for open-source components

A vendor who provides an SBOM should be asked whether it is version-specific and whether VEX is available for known vulnerabilities. An SBOM without currency and VEX is a compliance artifact. An SBOM with both is a risk management tool.

How to evidence it

• Automated SBOM vulnerability scan records
• SBOM currency verification
• VEX request and review records
• Vendor vulnerability remediation tracking from SBOM findings

Key Takeaway

SBOM provided. 847 components. 14 with known critical vulnerabilities at generation time. SBOM age: 6 months. Vulnerability status: not included. The SBOM existed and met the regulatory request for one. The regulator's first review found three problems. The mandate produced the document. The mandate did not produce the currency, the vulnerability status, or the action that makes the document useful. Version-specific SBOMs, VEX for known vulnerabilities, and automated scanning of received SBOMs convert compliance artifact into supply chain risk intelligence.

More on Third-party oversight

• Build Pipeline Integrity
• Vendor Patch Cadence Reality
• Artifact Registry Security