The plain-language definition
An SBOM is an inventory of every component inside a piece of software — every open-source library, every internal package, every dependency of a dependency — along with its version and where it came from. Think of it the way you'd think of an ingredients list on packaged food: not a description of what the product does, a list of exactly what's inside it, down to the parts you didn't add yourself.
Modern applications are assembled, not written from scratch — a typical production app can easily have hundreds of open-source dependencies pulled in transitively, most of which nobody on the team chose directly or would recognize by name. An SBOM is the artifact that makes that invisible supply chain visible and queryable.
Why this became urgent, not academic
SBOMs used to be a compliance checkbox mostly relevant to government contractors. Two things changed that. First, a run of serious supply-chain incidents — vulnerabilities buried three or four dependency layers deep, or outright malicious code slipped into a popular open-source package — made "we don't actually know what's in our own software" an unacceptable answer for security teams. Second, regulation caught up: government procurement in the US and the EU's Cyber Resilience Act have both moved toward requiring SBOMs for software sold into their markets, and larger enterprise customers increasingly ask vendors for one during procurement regardless of whether a regulator requires it.
When a critical vulnerability in a widely-used library makes headlines, the first question every security team asks is "are we affected, and where?" Without an SBOM, answering that means manually grepping dependency trees under time pressure. With one, it's a query that takes minutes.
What's actually inside one
- Component inventory — every library and package, direct and transitive, with exact version numbers.
- Provenance — where each component came from and, ideally, how it was built.
- License information — increasingly a procurement and legal concern in its own right, separate from security.
- Known vulnerabilities — when cross-referenced against a vulnerability database, which is what turns a static inventory into an actionable tool.
The two formats that matter in practice are SPDX (originated for license compliance, now broadly used) and CycloneDX (built security-first, from the OWASP ecosystem). Most tooling supports both; which one a specific customer or regulator wants is usually dictated to you rather than a real choice.
Do you actually need one? A quick checklist
- Do you sell software to government agencies, or to enterprise customers with a formal security review process? — Very likely yes, either now or soon.
- Does your product handle sensitive data, or sit somewhere a compromise would be high-impact (healthcare, finance, infrastructure)? — Worth having regardless of whether anyone's asked yet.
- Has a customer's procurement or security team ever asked "what's in your software supply chain?" — If this has already happened once, it will happen again.
- Is your team currently unable to quickly answer "are we affected?" when a major open-source vulnerability makes the news? — This alone is reason enough.
If none of these apply yet — a small internal tool with no external customers, say — an SBOM is lower priority, though generating one is cheap enough now that there's rarely a good reason to skip it entirely once you're shipping anything customer-facing.
Generating one isn't the hard part — maintaining it is
Tooling to generate an SBOM from a build is mature and mostly automated at this point; that's not where the real work is. The real work is keeping it current as dependencies update constantly, wiring it into CI so it's regenerated on every build rather than going stale, and — the part that actually delivers value — connecting it to a vulnerability feed so a new CVE in a library you use surfaces as an alert instead of something you find out about from a customer.
Need an SBOM process that doesn't go stale?
We build SBOM generation and dependency monitoring into the pipeline itself, not as a one-time compliance document.
Frequently asked questions
Is an SBOM the same as a security audit?
No. An SBOM is an inventory — it tells you what's in your software. A security audit assesses whether that software is actually secure. An SBOM is one input a good audit uses, not a replacement for one.
How often should an SBOM be regenerated?
On every build, ideally, wired into CI rather than produced manually on a schedule — dependencies change often enough that a quarterly SBOM is already out of date by the time anyone reads it.
Does open-source software need an SBOM too?
Open-source projects increasingly publish their own SBOMs precisely so the companies consuming them can build accurate SBOMs of their own — the whole point is that this information should propagate down the dependency chain, not stop at the first layer.
SPDX or CycloneDX — which one should we use?
If a specific customer or regulator has told you which they require, use that one. If you're choosing freely, CycloneDX has the stronger security tooling ecosystem right now; SPDX has broader adoption for license compliance. Good tooling can usually output both from the same source data.