A Software Bill of Materials — SBOM — is a formal, machine-readable inventory of everything that goes into a piece of software: the open-source libraries, their versions, their own dependencies, and ideally where each came from. The analogy that stuck is the food label. You wouldn't buy packaged food with no ingredient list, especially with an allergy. Modern software is assembled from hundreds of third-party components, and until recently most of it shipped with no ingredient list at all.
Why This Became Urgent
Today's applications are mostly other people's code. A typical project directly imports a few dozen libraries, and each of those pulls in its own dependencies, so the real "dependency tree" runs to hundreds or thousands of components — most of which a developer never consciously chose. This is the software supply chain, and it's an attack surface as much as a convenience.
Two kinds of events made SBOMs unavoidable. The first is a widespread vulnerability like Log4Shell, where the urgent question is "which of our systems contain the affected version?" The second is a malicious-package incident, where a dependency is compromised at the source and ships hostile code to everyone who pulls it. In both cases, you cannot respond to a risk you can't see — and without an inventory, you can't see your own software's contents.
"Are we affected by vulnerability X?" Without an SBOM, answering means manually auditing every project, often under time pressure while attackers are already scanning. With one, it's a search across a list you generated in advance. The value isn't theoretical security — it's response speed when something is actually on fire.
What's Actually In One
Industry guidance — notably the minimum-elements work published by the U.S. National Telecommunications and Information Administration (NTIA) — converged on a baseline set of fields every SBOM entry should carry:
- Component name — the library or package
- Version — precise, because vulnerabilities are version-specific
- Supplier / author — who produces it
- Unique identifiers — standardized IDs (such as a package URL) so the same component is recognizable across tools
- Dependency relationships — what depends on what, so you can see the full tree, not just the top level
- Author of the SBOM data and a timestamp, so consumers know its provenance and freshness
That dependency-relationship field is the one people skip and later regret. The Log4j problem was rarely "we imported Log4j directly." It was "a framework we use imported something that imported Log4j." A flat list of top-level packages would have missed it; a real dependency graph catches it.
The Two Main Formats
An SBOM is only useful if tools can read it, which means standard formats. Two dominate:
| Format | Origin | Notes |
|---|---|---|
| SPDX | Linux Foundation; standardized as ISO/IEC 5962 | Long history in license compliance; broad tooling; an international standard |
| CycloneDX | OWASP | Security-first design; rich support for vulnerabilities and related advisories |
Both are mature and widely supported; the choice usually comes down to ecosystem and tooling rather than capability. What matters is picking a standard format at all, so the SBOM can be consumed by the scanners and dashboards that turn it into action.
How SBOMs Get Generated
You don't write an SBOM by hand. Tools generate it automatically by inspecting your project. Open-source scanners such as Syft and Trivy can analyze source trees, lockfiles, and even built container images to produce an SBOM in SPDX or CycloneDX format. The strongest practice is to generate the SBOM as part of the build pipeline, so it always reflects what actually shipped rather than what someone thinks shipped. An SBOM that's out of date with the real artifact is worse than none, because it offers false confidence.
An SBOM is a snapshot, not a guarantee. It tells you what's inside as of a moment in time. Its value depends entirely on being regenerated whenever the software changes and on being paired with current vulnerability data. — A realistic view of what an SBOM does and doesn't do
From Inventory to Action: VEX
An SBOM tells you what you have. It does not tell you whether a given vulnerability in a listed component actually affects you — sometimes the vulnerable function is never called, or the component is configured so the flaw can't be reached. That's where VEX (Vulnerability Exploitability eXchange) comes in: a companion document where a supplier states, for a specific vulnerability, whether their product is actually exploitable through it. Pairing SBOM ("we contain component X") with VEX ("but this CVE in X doesn't affect us, because…") is what keeps security teams from drowning in false positives. Understanding the underlying severity scores helps here too — see our explainer on CVSS and CVE scoring.
The Regulatory Push
SBOMs moved from best practice to requirement largely through government procurement. In May 2021, U.S. Executive Order 14028 directed federal agencies and their software suppliers toward providing SBOMs as a condition of doing business with the government. Because the federal government is an enormous software buyer, that requirement rippled outward — vendors who wanted federal contracts had to produce SBOMs, and many then standardized the practice across all their products. Regulators in other jurisdictions have been moving in the same direction, treating component transparency as a baseline expectation rather than a differentiator.
Why This Matters Even If You're Not a Developer
As a user of any security-sensitive software, SBOMs are part of why the next widespread vulnerability gets patched in days instead of months. They're also a reasonable thing to ask a vendor about: a company that can produce an SBOM and describe how it monitors those components for new vulnerabilities is demonstrably paying attention to its supply chain. One that can't may not know what's inside its own product.
At Haven, dependency transparency is part of how we keep the stack trustworthy — knowing exactly what our apps are built from is a prerequisite for the kind of verifiable, reproducible builds that let security claims be checked rather than merely asserted. An ingredient list isn't glamorous, but in a world where software is assembled from thousands of other people's parts, it's the difference between managing your supply chain and hoping nothing in it goes wrong.