In December 2021, a vulnerability in Log4j - a Java logging library that had been quietly embedded in thousands of enterprise software products for years - turned into one of the worst security events in recent memory. The problem wasn't just that the vulnerability was severe (it was, a CVSS score of 10.0). The problem was that nobody knew which of their software products contained Log4j. Enterprise security teams spent weeks manually inventorying their software stack, calling vendors, waiting on responses. Some of them are probably still finding Log4j deployments today.
That crisis accelerated something that had been building for years: the push to require software vendors to disclose exactly what's inside their products. The SBOM - Software Bill of Materials - is the standardized format for that disclosure. Think of it as a nutrition label for software. Just as a food manufacturer lists every ingredient, a software vendor lists every library, framework, and dependency their product relies on, along with version numbers and licensing information.
The Regulatory Push: EO 14028 and Beyond
In May 2021 - months before Log4Shell - the Biden administration published Executive Order 14028 on Improving the Nation's Cybersecurity. Section 4 of that order directed NIST to publish guidelines for secure software development practices, and specifically called out SBOMs as a baseline requirement for software sold to the federal government. The order gave agencies 60 days to produce recommendations and set up a timeline for implementation.
Federal mandates have a way of diffusing into enterprise procurement requirements over time. Within 18 months of EO 14028, major healthcare organizations, financial institutions, and defense contractors were adding SBOM requirements to their vendor questionnaires. The logic is simple: if a vulnerability is discovered in a component, a customer with an SBOM can immediately determine whether they're affected. A customer without one has to wait on the vendor.
The European Union has followed a similar trajectory. The Cyber Resilience Act, which entered into force in late 2024, includes SBOM requirements for products with digital elements sold in the EU market. This isn't just a government procurement issue anymore. If you sell software to large enterprises or to regulated industries anywhere in the developed world, SBOM requirements are coming for you.
What an SBOM Actually Contains
There are two dominant SBOM formats: SPDX (Software Package Data Exchange), maintained by the Linux Foundation, and CycloneDX, maintained by OWASP. They cover similar ground - both include package names, versions, licenses, checksums, and dependency relationships. CycloneDX has become more popular for modern SaaS applications because it has better tooling and supports more nuanced representations of complex dependency graphs.
A minimal SBOM for a typical Node.js application would include every package in yournode_modules tree - not just your direct dependencies, but their dependencies too, all the way down. That's often several hundred packages for a moderately complex application. For a Java application with Maven or Gradle, it might be thousands. Each entry includes the package name, version, and a unique identifier (CPE or PURL) that security databases can use to match against known vulnerabilities.
The AIBOM: A New Frontier
The concept is now expanding beyond traditional software to cover AI systems - what some are calling an AIBOM, or AI Bill of Materials. An AIBOM would disclose not just the software components in an AI-powered product, but the models being used, the datasets those models were trained on, the fine-tuning that was applied, and any known biases or limitations. CycloneDX version 1.5 added support for machine learning model components for exactly this reason.
This matters because the supply chain risk for AI systems is genuinely different from traditional software. When you include an open-source model like Llama or Mistral in your product, you're not just inheriting software vulnerabilities - you're potentially inheriting training data provenance issues, model extraction risks, and behaviors that emerge from fine-tuning. Enterprise customers who are serious about AI governance are going to want visibility into this. The companies that have the documentation ready will win those deals.
How to Generate One Without Manual Work
The good news is that SBOM generation is largely automated for modern software. Tools like Syft, Trivy, and the native SBOM generation in GitHub Actions can scan your codebase or container image and produce a CycloneDX or SPDX document in minutes. Integrating this into your CI/CD pipeline means you always have an up-to-date SBOM that reflects your current dependencies rather than a stale snapshot from the last time someone updated the documentation.
The harder problem is SBOM management - what you do with the document once you have it. The real value of an SBOM isn't the file itself; it's the ability to continuously monitor that file against vulnerability databases like the NVD (National Vulnerability Database) and OSV (Open Source Vulnerabilities). When a new CVE is published, you want to know within hours whether any of your dependencies are affected, not weeks later when a researcher or customer figures it out and emails you.
That continuous monitoring capability is what transforms an SBOM from a compliance checkbox into a genuine security tool. Tools like Dependency-Track, Grype, and integrated features in platforms like Snyk can consume your SBOM and alert you to new vulnerabilities as they appear in the public databases.
If you haven't started on this yet, start now. Generate an SBOM for your main product, review what's in it, and wire up at least basic vulnerability monitoring. The next time an enterprise prospect's security team asks for your SBOM in a questionnaire - and they will - you'll have it ready. More importantly, you'll actually know what's in your software, which turns out to be a prerequisite for defending it.