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 around the world were at risk. What made the next weeks genuinely chaotic wasn’t the vulnerability itself — it was that nobody knew where Log4j actually lived. It was embedded inside applications, inside servers, inside tools that ran inside other tools, and most of the companies scrambling to respond had no way to quickly search their own software for it.
That moment made the software bill of materials — SBOM — go from a niche compliance concept to a board-level conversation almost overnight. Understanding what a software bill of materials is, and why regulators are now making it mandatory, starts with understanding why that scramble was so preventable.
What Is a Software Bill of Materials?
A software bill of materials is exactly what the name suggests: a structured, machine-readable list of every component inside a piece of software. Think of it as the ingredient label on a food package, applied to code. Just as a nutrition label tells you what’s in the product, an SBOM tells you which open-source libraries, third-party packages, and internal components make up a given application — along with their versions, their licenses, and any known vulnerabilities associated with them.
Modern software is rarely written entirely from scratch. A typical commercial application might contain hundreds of open-source libraries, which themselves depend on other libraries, which depend on others still. The average enterprise application has somewhere between 500 and 1,500 third-party dependencies by the time all transitive relationships are counted. Without a software bill of materials, tracking all of those relationships manually is effectively impossible.
Two open standards dominate how SBOMs are formatted today. SPDX (Software Package Data Exchange), originally developed by the Linux Foundation, is older and more focused on license compliance. CycloneDX, backed by OWASP, is newer and more oriented toward security use cases. Both are machine-readable and supported by the major tooling ecosystems — which standard a given organization uses typically depends on whether their primary concern is legal or security-focused.
Why Log4Shell Changed the Software Supply Chain Conversation
The Log4Shell vulnerability — CVE-2021-44228 affected an estimated 3 billion devices and caused remediation costs measured in the billions across the industry. But the more revealing part of the Log4Shell story wasn’t the vulnerability’s severity. It was how long it took organizations to even determine whether they were affected.
Companies that had SBOMs — even rough, incomplete ones — could run an automated search and know within hours. Companies without them had to manually audit every application, trace every dependency tree, contact every vendor, and wait for answers that often took weeks. The difference between those two outcomes is the entire argument for making software bill of materials practices standard.
The 2024 XZ Utils backdoor incident underlined the same point. An attacker spent nearly two years contributing to an open-source project before inserting a carefully hidden backdoor into a widely used compression library. Security researchers ultimately caught it through code inspection, not through any systematic inventory process — which means most organizations still had no automated way to know whether that library was buried somewhere in their stack. Supply chain attacks of this kind exploit exactly the visibility gap that an SBOM is designed to close.
The deeper issue is that the open-source ecosystem, which powers a significant majority of modern software, operates largely on trust. Packages are consumed, dependencies are pulled, and versions are pinned — but the full chain of custody is rarely documented anywhere a security team can query. A software bill of materials creates that documentation as a first-class artifact of the development process, the same way confidential computing keeps sensitive data protected at runtime — by making security a structural property of the system rather than an afterthought.
Who Requires SBOM Now and When Deadlines Apply
The regulatory push for software bill of materials practices has moved faster than most compliance timelines. In the United States, Executive Order 14028, signed in May 2021, directed the National Institute of Standards and Technology to publish minimum elements for an SBOM and required federal software vendors to provide them. That mandate effectively set the baseline for any organization selling software to the US government.
The FDA followed in late 2023 with guidance requiring medical device manufacturers to include an SBOM with every premarket submission. Healthcare software — which runs on the same open-source stacks as everything else — suddenly had a hard regulatory requirement attached to something most development teams had never formally tracked.
The most significant upcoming deadline is the EU Cyber Resilience Act, which enters full enforcement in December 2027. The CRA covers any product with digital elements sold in the European Union, which includes most commercial software, connected devices, and cloud services. SBOM documentation is one of its explicit requirements, and the penalties for non-compliance scale with market access. The compliance window is narrower than it looks — organizations that haven’t begun building SBOM generation into their pipelines now are already behind the curve for a December 2027 enforcement date.
Industry adoption data reflects the pressure. According to ENISA’s 2026 figures, 78 percent of enterprises have begun SBOM adoption, and a DigiCert survey found that 43 percent 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 an SBOM Is Created and Where Most Teams Get Stuck
Generating a basic SBOM has become relatively straightforward with modern tooling. CISA maintains a comprehensive resource library covering both the standard formats and the available tooling ecosystem. Open-source tools like Syft and Grype from Anchore can generate and scan SBOMs from container images and filesystems in minutes. Commercial platforms from vendors like FOSSA, Snyk, and Black Duck integrate SBOM generation directly into CI/CD pipelines, making it possible to produce a fresh, accurate SBOM as part of every build.
The harder problem isn’t generation — it’s currency. An SBOM produced at build time reflects the dependency tree at that specific moment. Libraries get updated, new transitive dependencies get pulled in, and vulnerabilities get disclosed against components that weren’t vulnerable when the SBOM was last generated. An SBOM that’s six months old may be less useful than no SBOM at all if it creates a false sense of inventory completeness.
The organizations that get the most out of SBOM practices treat them as live documents tied to CI/CD, not compliance artifacts produced once and filed away. That distinction — between SBOM-as-process and SBOM-as-document — is where most implementation efforts stall.
Tools Worth Knowing Before You Start
For teams just beginning, the practical starting point is integrating an automated SBOM generator into the existing build pipeline, picking one standard format (CycloneDX for security-focused teams, SPDX for teams where license compliance is the primary concern), and establishing a process for scanning against a vulnerability database — NIST’s NVD, OSV, or a commercial equivalent — at every release. Starting with a single application and iterating is far more sustainable than attempting to retrofit SBOM generation across an entire portfolio at once.
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. The missing piece is that most organizations that have invested 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 that your application has 847 dependencies, 23 of which have known CVEs, doesn’t automatically generate the prioritization framework, the patch ownership model, or the vendor communication process needed to act on that information. Teams that treat SBOM adoption as a tooling problem consistently underestimate how much of the real work is organizational.
The companies that got the most out of Log4Shell remediation weren’t the ones with the most sophisticated SBOM tooling. They were the ones that had already answered “who is responsible for this dependency when something goes wrong?” before the crisis hit. The software bill of materials tells you what you have. The harder question it surfaces is whether your organization is actually structured to do anything about it.
What is a software bill of materials (SBOM)?
A software bill of materials is a structured, machine-readable inventory of every component inside a piece of software — including open-source libraries, third-party packages, their version numbers, their licenses, and any known vulnerabilities. It works like a nutrition label for code, giving organizations visibility into what their software is actually made of.
Why did Log4Shell make SBOM important?
The Log4Shell vulnerability in 2021 affected an estimated 3 billion devices, but the chaos was amplified because most organizations had no way to quickly determine whether the vulnerable Log4j library was embedded in their systems. Organizations with even basic SBOMs could run an automated search within hours; those without them spent weeks manually auditing their applications.
Who is required to have an SBOM?
US federal software vendors have been required to provide SBOMs since Executive Order 14028 in 2021. Medical device manufacturers must include them with FDA submissions since 2023. The EU Cyber Resilience Act, entering full enforcement in December 2027, will require SBOMs for most commercial software and connected devices sold in the European Union.
What tools are used to create an SBOM?
Open-source tools like Syft and Grype from Anchore can generate SBOMs from container images and filesystems. Commercial platforms like FOSSA, Snyk, and Black Duck integrate SBOM generation directly into CI/CD pipelines. CISA maintains a resource library covering both tooling options and the two main standards: SPDX and CycloneDX.
What is the difference between SPDX and CycloneDX?
SPDX, developed by the Linux Foundation, is older and primarily focused on license compliance. CycloneDX, backed by OWASP, is newer and more oriented toward security use cases like vulnerability tracking. Both are machine-readable and widely supported — the choice typically depends on whether a team’s primary concern is legal or security-focused.