SBOM Explained: What Every Software Company Must Know

📅 September 29, 2026  |  🏷 General  |  Cyber Security, Information Security, Threat Management

A single unpatched vulnerability in a third-party logging library brought global enterprise operations to a halt in December 2021. The Log4Shell crisis exposed a fundamental truth that still haunts software supply chains: most organizations had no reliable inventory of where Log4j existed in their own software. Four years later, the regulatory and operational response has crystallized around one critical tool — the Software Bill of Materials, or SBOM. If your organization builds, distributes, or procures software and you cannot produce an accurate SBOM on demand, you are operating blind in one of the most adversarially contested environments in modern computing.

What Is an SBOM and Why Does It Matter Now

An SBOM is a formal, structured inventory of every component that constitutes a piece of software — open-source libraries, commercial modules, internal packages, their versions, licenses, and dependency relationships. Think of it as a nutritional label for software: just as food manufacturers must disclose every ingredient, software suppliers are increasingly required to disclose every component that ships inside their product.

The concept is not new. The idea of software transparency was discussed in academic security circles as early as the mid-2000s. What changed was executive-level urgency. President Biden’s Executive Order 14028 on Improving the Nation’s Cybersecurity, issued in May 2021, mandated that federal agencies require SBOMs from software vendors as a condition of procurement. By September 2026, the Cybersecurity and Infrastructure Security Agency (CISA) has expanded minimum SBOM requirements, and the European Union’s Cyber Resilience Act has made similar documentation mandatory for products sold into the EU market. The regulatory window has closed for organizations that treated SBOMs as optional.

The Anatomy of a Compliant SBOM

CISA and the National Telecommunications and Information Administration (NTIA) have defined minimum viable SBOM fields that any compliant document must contain. These include: supplier name, component name, component version, other unique identifiers (such as CPE or PURL), dependency relationships, author of the SBOM data, and timestamp. Two dominant machine-readable formats have emerged as standards: SPDX (Software Package Data Exchange), developed under Linux Foundation governance, and CycloneDX, maintained by OWASP. Both are widely supported by commercial tooling, though CycloneDX has gained significant enterprise adoption due to its richer support for vulnerability disclosure and service dependency mapping.

Transitive Dependencies — The Hidden Attack Surface

Direct dependencies are the components your developers intentionally import. Transitive dependencies are the components those components import — and the ones those import, recursively. Research published by Sonatype in their 2025 State of the Software Supply Chain report found that over 96% of vulnerable open-source downloads could have been avoided by selecting an alternative version, yet developers continued pulling vulnerable packages because they lacked visibility into transitive dependency chains. An SBOM that only captures first-level dependencies is operationally useless when a vulnerability surfaces three levels deep. Accurate SBOM generation must traverse the entire dependency graph.

The Business Case: Risk, Liability, and Competitive Advantage

Framing SBOM adoption purely as a compliance exercise understates its business value. Organizations with mature SBOM programs demonstrate measurably faster incident response. When the OpenSSL 3.x vulnerabilities (CVE-2022-3602 and CVE-2022-3786) were disclosed, companies with queryable SBOMs identified affected systems within hours. Companies without them spent days or weeks conducting manual audits — during which their exposure windows remained open.

From a liability perspective, software vendors who ship products without SBOM documentation face increasing exposure under emerging product liability frameworks. The EU’s Cyber Resilience Act specifically places liability on manufacturers for foreseeable vulnerabilities in connected products. Shipping software without a documented component inventory is increasingly analogous to shipping a physical product without safety certification — it creates both regulatory risk and tort exposure.

SBOMs as a Sales Differentiator

Enterprise procurement teams — particularly in healthcare, defense, financial services, and critical infrastructure — now routinely include SBOM requirements in Request for Proposal (RFP) documentation. A 2025 survey conducted by the Cloud Security Alliance found that 67% of enterprise security leaders reported that the ability to provide a current SBOM positively influenced their purchasing decisions. Software vendors who cannot produce an SBOM on request are being disqualified from competitive bids. Conversely, vendors who proactively publish SBOMs and maintain them with automated tooling are building trust signals that translate directly to pipeline acceleration.

How to Generate and Maintain SBOMs at Scale

Generating a one-time SBOM is a solved problem. Generating accurate, continuously updated SBOMs across a portfolio of microservices, containerized workloads, and CI/CD pipelines is an engineering discipline that requires deliberate architectural decisions.

SBOM Generation Tooling Landscape

The tooling ecosystem has matured considerably. Key categories and representative tools include:

The most operationally effective architectures integrate SBOM generation as a native step in the build pipeline — not as a post-deployment audit. This means that every artifact produced by your CI system carries an associated, versioned SBOM that is stored alongside the artifact in your registry. Tools like GitHub Actions and GitLab CI have native or plugin-supported SBOM generation steps that can make this implementation straightforward.

Continuous SBOM Maintenance and VEX Integration

A static SBOM generated at release time degrades in accuracy as new vulnerabilities are discovered. The emerging companion standard, Vulnerability Exploitability eXchange (VEX), addresses this gap. VEX documents allow software suppliers to communicate whether a known CVE actually affects a given product — and in what context. For example, a product may contain a vulnerable version of OpenSSL but not expose the affected code path. A VEX statement allows the supplier to assert “not affected” with documented justification, reducing false-positive alert fatigue downstream in the supply chain. CISA’s VEX guidance from 2023, updated in 2025, provides a formal schema for these assertions. Integrating VEX into your SBOM program transforms it from a static inventory into a dynamic risk communication channel.

SBOMs in the Context of Software Supply Chain Security

Supply chain attacks have become the preferred vector for sophisticated threat actors precisely because they exploit the trust relationships organizations place in their software suppliers. The 2020 SolarWinds compromise, which affected approximately 18,000 organizations including multiple U.S. federal agencies, was not a perimeter breach — it was an injection into the build process of a trusted software vendor. An SBOM would not have prevented that attack, but it would have dramatically accelerated the blast radius assessment for every affected organization.

SBOM programs are most powerful when integrated into a broader Software Supply Chain Security (SSCS) framework that includes:

• SLSA (Supply-chain Levels for Software Artifacts) — a Google-originated framework for provenance and build integrity verification
• Sigstore — a Linux Foundation project enabling cryptographic signing of software artifacts and SBOMs
• In-toto — a framework for verifying that each step of the supply chain was performed by an authorized actor
• OSV (Open Source Vulnerabilities) database — for automated cross-referencing of SBOM components against known CVEs

Regulatory Alignment: CISA, FDA, and EU CRA

Regulatory requirements for SBOMs have diverged across industries, and compliance officers need sector-specific awareness. The U.S. Food and Drug Administration’s 2023 guidance on cybersecurity for medical devices made SBOM submission a formal requirement for premarket approval — a mandate that has since been tightened in 2025 updates to include post-market SBOM maintenance obligations. The EU Cyber Resilience Act, fully enforceable from September 2026, requires CE-marked connected products to ship with machine-readable SBOMs and mandates timely disclosure of newly discovered vulnerabilities. Defense Industrial Base (DIB) contractors face SBOM requirements under CMMC 2.0’s supply chain risk management controls. Organizations operating across these jurisdictions must maintain SBOMs that satisfy the most stringent applicable standard — which in practice means building toward FDA and CRA alignment from the outset.

Common SBOM Implementation Failures and How to Avoid Them

Despite growing awareness, SBOM programs frequently fail to deliver their intended security value due to predictable implementation errors. Understanding these failure modes is as important as understanding the technology itself.

The Completeness Problem

The most pervasive SBOM failure is incompleteness. Organizations generate SBOMs for their primary application codebase but omit containerized runtime dependencies, firmware components, operating system packages within container base images, and dynamically loaded plugins. A 2024 study by Chainguard found that 78% of enterprise SBOMs examined failed to accurately capture all components present in the corresponding production container images. This gap is particularly dangerous because container base images are frequently the source of exploited vulnerabilities. Any SBOM generation strategy must explicitly include: application code dependencies, container base image packages, infrastructure-as-code tool versions, and third-party SDKs bundled in mobile or embedded deployments.

SBOM Without a Consumption Strategy

Generating SBOMs is only half the equation. Organizations that produce SBOMs but have no process for consuming, querying, and acting on SBOMs received from their own suppliers gain limited security value. An effective SBOM program requires:

1. A centralized SBOM repository (Dependency-Track is the most widely deployed open-source option)
2. Automated correlation of SBOM components against the National Vulnerability Database (NVD) and OSV
3. Defined SLAs for investigating and remediating high-severity findings surfaced by SBOM analysis
4. Contractual requirements on suppliers to deliver SBOMs with each software release
5. A process for ingesting and evaluating VEX statements from suppliers to suppress confirmed non-applicable CVEs

Key Takeaways

• SBOMs are now regulatory baseline, not best practice. Federal procurement requirements, FDA mandates, and the EU Cyber Resilience Act make SBOM generation and maintenance a legal obligation for a growing set of software producers and distributors.
• Transitive dependencies are where the real risk lives. Any SBOM program that only captures first-level dependencies is providing a false sense of security. Full dependency graph traversal is non-negotiable for meaningful vulnerability management.
• Integrate SBOM generation into your CI/CD pipeline at build time. Post-deployment SBOM generation is error-prone and operationally late. Treat the SBOM as a build artifact — versioned, signed, and stored alongside the deliverable.
• VEX integration transforms your SBOM from static inventory to dynamic risk communication. Pairing SBOMs with Vulnerability Exploitability eXchange statements reduces downstream alert fatigue and demonstrates supplier accountability.
• SBOM programs require both production and consumption capabilities. Generating accurate SBOMs without a corresponding strategy for ingesting supplier SBOMs and acting on findings leaves half the supply chain risk unaddressed.

Conclusion: Building Your SBOM Program Before the Deadline Forces You To

The organizations that will navigate the next major supply chain incident with the least damage are those that have already built the infrastructure to answer one question instantly: where does this component exist in our environment? An SBOM program, properly implemented and continuously maintained, makes that question answerable in minutes rather than days.

The regulatory environment as of late 2026 has removed ambiguity about whether SBOMs are required. The remaining question is whether your program is accurate, complete, and operationally integrated — or whether it is a checkbox artifact that will fail you precisely when you need it most.

Start with a concrete action this week: audit your three most critical software products using Syft or Trivy, generate CycloneDX-formatted SBOMs, ingest them into a Dependency-Track instance, and review the vulnerability findings against your current patching backlog. You will almost certainly discover components you did not know existed in your own software. That discovery, uncomfortable as it may be, is the foundation of a defensible software supply chain security posture. Schedule that audit, assign an owner, and set a 30-day deadline to expand coverage to your full software portfolio. Every week of delay is a week your adversaries may already know more about your software composition than you do.