Software Bill of Materials Automation

An SBOM programme that collects documents without automating their ingestion, parsing, and analysis is an evidence collection programme, not a supply chain visibility programme. The value of an SBOM is realised at the moment a new CVE is published for a component in the inventory , when the SBOM enables the enterprise to immediately identify which vendor's software is affected, which version of that software the enterprise is running, and what action is required. This value is only realisable if the SBOM data is in a machine-readable format, has been parsed into a system that can be queried against current vulnerability data, and has been updated since the software version the enterprise is actually running was released.

The format proliferation problem is the first automation barrier. SBOMs are produced in multiple formats , SPDX (in multiple serialisations: JSON, RDF, YAML, tag-value), CycloneDX (in JSON and XML), and various proprietary formats. A programme that accepts SBOMs in any format the vendor provides will accumulate a collection of documents that require different parsing tools, producing an inventory management challenge that most manual processes cannot sustain. Standardising on a single SBOM format , CycloneDX JSON is the most widely adopted for machine processing , and requiring vendors to provide SBOMs in that format is the foundation of automation.

The continuous update requirement is the second automation dimension. Software vulnerabilities are published continuously , the National Vulnerability Database publishes hundreds of new CVEs weekly. An SBOM that is accurate at collection becomes progressively more outdated as a vulnerability reference, because it does not reflect new CVEs published for components in the inventory since collection. Automated SBOM management platforms that continuously monitor component inventories against CVE databases , re-querying the vulnerability status of all components whenever new CVEs are published , provide continuous supply chain visibility that periodic manual review cannot.

Why this matters

SBOM automation matters for TPRM because the intelligence value of an SBOM programme is proportional to the speed with which new CVEs in the inventory trigger enterprise awareness and action. A programme that reviews SBOMs annually at reassessment provides CVE awareness on a twelve-month lag. An automated programme that monitors inventory against CVE databases continuously provides awareness within hours of CVE publication.

• SBOMs collected as documents , not parsed into queryable inventory
• Format diversity preventing automated parsing
• No continuous CVE monitoring against collected SBOM inventories
• SBOM age and version currency not tracked
• SBOM collection as compliance activity not supply chain intelligence

What good looks like

Mature SBOM automation programmes standardise on CycloneDX JSON format, ingest SBOMs into a platform like Dependency-Track that continuously monitors component inventories against CVE databases, track SBOM version currency, and generate automated alerts when new CVEs affect components in any ingested SBOM.

• Standardised SBOM format requirement , CycloneDX JSON from all vendors
• Automated SBOM ingestion into Dependency-Track or equivalent platform
• Continuous CVE monitoring against all ingested component inventories
• SBOM version currency tracking , alert when SBOM age exceeds threshold
• Automated CVE alerts to vendor relationship owners when CVEs affect their inventory

Tooling

SBOM Management , Dependency-Track for automated SBOM ingestion and continuous CVE monitoring

Dependency-Track is an open-source SBOM management platform that ingests CycloneDX and SPDX SBOMs and continuously monitors their component inventories against vulnerability databases including NVD, OSV, and GitHub Advisories. When a new CVE is published, Dependency-Track automatically queries all ingested SBOMs and identifies which components are affected. For TPRM programmes, Dependency-Track provides the continuous monitoring layer that converts a static document collection into a dynamic supply chain intelligence system.

SBOM Generation , Syft, cdxgen for automated SBOM generation; cyclonedx-cli for format conversion

For vendors who provide SBOMs in non-standard formats, format conversion tools can translate between SBOM formats , enabling ingestion into standardised platforms regardless of the vendor's output format. cyclonedx-cli provides conversion between SPDX and CycloneDX formats.

Governance challenges

The governance challenge with SBOM automation is the vendor compliance requirement. Requiring vendors to provide SBOMs in CycloneDX JSON format rather than any convenient format shifts the standardisation burden to vendors rather than the enterprise. Some vendors will comply readily; others will resist. The governance resolution is tiered implementation , requiring machine-readable SBOMs from critical-tier vendors immediately, expanding to other tiers as vendor compliance increases.

• Require CycloneDX JSON format from critical-tier vendors
• Implement Dependency-Track or equivalent for automated SBOM management
• Configure continuous CVE monitoring against all ingested SBOMs
• Track SBOM version currency and request updates when SBOMs age beyond threshold
• Automate CVE alert routing to vendor relationship owners

If you are a small team

Deploy Dependency-Track , it is free, open-source, and can be running in your environment within a day. Then take your ten most recently received SBOMs from critical vendors and re-request them in CycloneDX JSON format if they are not already in that format. Ingest all ten into Dependency-Track and configure CVE monitoring. Within 24 hours you will have a continuously monitored supply chain inventory for those ten vendors that provides more supply chain visibility than years of document collection could produce.

• Deploy Dependency-Track for SBOM management
• Re-request critical vendor SBOMs in CycloneDX JSON format
• Ingest into Dependency-Track and configure continuous CVE monitoring
• Automate CVE alert routing to vendor relationship owners

What to require

Ask directly:

"Can you provide your SBOM in CycloneDX JSON format, version-specific to the release we are running , and do you have a process for proactively notifying us when a new CVE is published for a component in your software?"

Expect as evidence

• CycloneDX JSON format SBOM for current deployed version
• CVE notification process for component vulnerabilities
• SBOM update cadence , how frequently updated
• Automated vulnerability notification capability

A vendor who provides an SBOM should be asked for it in CycloneDX JSON format and asked about their CVE notification process. CycloneDX JSON enables automation. CVE notification provides the proactive intelligence that delayed annual review cannot.

How to evidence it

• Dependency-Track or equivalent deployment
• CycloneDX JSON format SBOM collection
• Continuous CVE monitoring records
• CVE alert and response process

Key Takeaway

847 SBOM documents. 7 formats. 93% never parsed. 41% over 12 months old. Supply chain visibility: none. The programme collected compliance evidence. It did not build supply chain intelligence. SBOM value is realised at CVE publication , when the inventory immediately identifies which vendor's software is affected. That value requires: machine-readable format, automated ingestion, continuous CVE monitoring, and current version currency. Dependency-Track is free and can be running the same day. CycloneDX JSON is the format standard. Continuous monitoring is the capability that converts document collection into intelligence.

More on Third-party oversight

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