On December 9, 2021, a security researcher posted a proof-of-concept exploit for a vulnerability in a Java library called Log4j. Within 72 hours, hundreds of millions of systems were at risk. The chaos that followed wasn't primarily about the vulnerability's severity. It was about something more fundamental: most organizations had no way to quickly search their own software to find out whether Log4j was buried somewhere inside it.
That moment made the software bill of materials — SBOM — go from a niche compliance topic to a board-level conversation almost overnight.
What Is an SBOM?
A software bill of materials is a structured, machine-readable inventory of every component inside a piece of software. Think of it as the nutrition label on a food package, applied to code. It tells you which open-source libraries, third-party packages, and internal components make up a given application — along with their versions, licenses, and any known vulnerabilities.
Modern software is rarely written entirely from scratch. A typical commercial application might contain 500 to 1,500 third-party dependencies by the time all transitive relationships are counted. Without an SBOM, tracking all of those relationships manually is effectively impossible.
Two open standards dominate today:
SPDX (Software Package Data Exchange)
Origin: Linux Foundation
Primary focus: License compliance
Best for: Teams where legal is the main concern
CycloneDX
Origin: OWASP
Primary focus: Security and vulnerability tracking
Best for: DevSecOps and security-focused teams
Why Log4Shell Made This Non-Negotiable
The Log4Shell vulnerability — CVE-2021-44228 affected an estimated 3 billion devices. But the more instructive part of the story was the response time gap.
Companies that had SBOMs — even rough, incomplete ones — could run an automated search and know within hours whether they were affected. Companies without them spent weeks manually auditing every application, tracing every dependency tree, and waiting on vendor responses.
The 2024 XZ Utils backdoor reinforced the same point. An attacker spent nearly two years contributing to an open-source project before inserting a hidden backdoor into a widely used compression library. Most organizations still had no automated way to know whether that library was in their stack. Supply chain attacks exploit exactly the visibility gap that an SBOM closes.
Who Requires SBOM Now
Compliance pressure has moved faster than most timelines:
US Executive Order 14028 (May 2021)
→ Federal software vendors must provide SBOMs
→ Status: Active
FDA Medical Device Guidance (Oct 2023)
→ SBOM required with every premarket submission
→ Status: Active
EU Cyber Resilience Act (Dec 2027)
→ Covers all software and connected devices sold in the EU
→ SBOM documentation explicitly required
→ Status: Full enforcement December 2027
According to ENISA's 2026 figures, 78% of enterprises have begun SBOM adoption. A DigiCert survey found that 43% of companies expect to face explicit SBOM requirements within 24 months. The gap between "starting adoption" and "production-ready compliance" remains substantial for most of them.
How to Actually Get Started
CISA maintains a comprehensive SBOM resource library covering formats, tooling, and implementation guidance. For most teams, the practical starting point looks like this:
Step 1: Pick a standard
→ Security-first team: CycloneDX
→ License compliance priority: SPDX
Step 2: Integrate automated generation
→ Open source: Syft (Anchore) — generates from container images and filesystems
→ Open source: Grype — vulnerability scanning against generated SBOMs
→ Commercial: FOSSA, Snyk, Black Duck — CI/CD pipeline integration
Step 3: Connect to a vulnerability database
→ NIST NVD
→ OSV (Open Source Vulnerabilities)
→ Commercial feeds from vendors above
Step 4: Establish update cadence
→ Tie SBOM generation to every build, not a quarterly audit
Start with a single application. Attempting to retrofit SBOM generation across an entire portfolio at once is where most programs stall.
What I Actually Found
The framing that dominates most SBOM coverage — "generate an SBOM, know what's in your software, fix vulnerabilities faster" — is accurate but incomplete in a way that matters practically.
Most organizations that invest in SBOM tooling discover the same thing in the first few months: the SBOM reveals a dependency tree that's far messier than anyone expected, and the organizational process for responding to what it reveals doesn't exist yet.
An SBOM is a diagnostic tool. It tells you what's there. But knowing your application has 847 dependencies, 23 of which have known CVEs, doesn't automatically generate a prioritization framework, a patch ownership model, or a vendor communication process.
The companies that responded fastest to Log4Shell weren't the ones with the most sophisticated tooling. They were the ones that had already answered "who owns this dependency when something goes wrong?" before the crisis hit. The SBOM tells you what you have. The harder question it surfaces is whether your organization is structured to act on it.
Full piece with more detail and external sources: lucas8.com/what-is-sbom-software-bill-of-materials
Top comments (0)