Software Supply Chain Security: How SBOMs Create the Transparency That’s Been Missing

SolarWinds, Log4Shell, MOVEit – every major supply chain attack of recent years could have been contained faster with a Software Bill of Materials (SBOM). SBOMs list every component in a software application and enable organizations to determine – within minutes – whether they’re affected. Without them, that same assessment can take weeks.

TL;DR

US Executive Order 14028 mandates SBOMs for vendors supplying federal agencies
The EU Cyber Resilience Act (CRA) requires SBOMs starting in 2027 for all digital products placed on the EU market
Standard formats: SPDX (Linux Foundation) and CycloneDX (OWASP)
The US National Telecommunications and Information Administration (NTIA) defines minimum requirements: supplier, component, version, and dependency

What an SBOM Actually Is

An SBOM is a machine-readable inventory of all software components: libraries, frameworks, dependencies – with name, version, license, and origin. Think of it like a food ingredient label: you know exactly what’s inside.

In practice: When a new vulnerability like Log4Shell emerges, an organization with SBOMs can identify – in minutes – which of its products contain the vulnerable component. Without SBOMs, teams face a manual, weeks-long forensic search.

Regulatory Pressure Is Mounting

The US led the way: Executive Order 14028 requires software suppliers to federal agencies to provide SBOMs. The EU is following suit with the Cyber Resilience Act (CRA), which mandates SBOMs starting in 2027 for all digital products sold in the EU.

For German software vendors and manufacturers of digital products, this is a countdown: failure to deliver SBOMs by 2027 means losing market access – in both the US and the EU.

Integration into the Development Process

SBOMs shouldn’t be created retroactively. Instead, they must be generated automatically during the build process. Tools such as Syft, Trivy, CycloneDX CLI, or SPDX-Tools integrate seamlessly into CI/CD pipelines and produce SBOMs with every release.

The workflow: the build generates the SBOM; the SBOM is scanned against vulnerability databases (NVD, OSV); if critical findings emerge, the release is blocked. This is DevSecOps in action – transparency baked in as an automated quality standard.

SBOM Management: More Than Just Generation

Generating an SBOM is only the first step. Real value comes from continuous SBOM management: newly published CVEs are automatically matched against existing SBOMs; customers receive proactive notifications when impacted components are identified; and SBOMs are updated with every product release.

Platforms like Dependency-Track (OWASP, open source) or commercial solutions such as Anchore and Sonatype automate this entire lifecycle. The effort required is minimal – the payoff in a real incident is enormous.

Key Facts

Transparency: SBOMs reduce response time to new CVEs – from weeks down to minutes

Regulation: US Executive Order 14028 + EU CRA make SBOMs mandatory by 2027

Adoption: SBOM generation rose 300% after Log4Shell (Sonatype)

Frequently Asked Questions

Which format should I use?

Use CycloneDX (OWASP) for security-focused SBOMs; SPDX (Linux Foundation) for license compliance. Both are machine-readable and interoperable. CycloneDX offers stronger integration with VEX (Vulnerability Exploitability eXchange).

Do I need to generate SBOMs for open-source dependencies?

Yes – and that’s precisely where the greatest value lies. Most modern applications consist of 70-90% open-source components. Without SBOMs covering those dependencies, vulnerability management remains blind.

How should I share SBOMs with customers?

Three models exist: direct delivery with each release, access via an SBOM portal, or provision upon request. The CRA will likely require proactive, automatic sharing. Establish your process now – before the mandate takes effect.

About the author: Tobias Massow

Read article

Compliance