An SBOM is a machine-readable list of every component inside a piece of software, so that when a vulnerability is announced you can tell in minutes whether it affects you.
The short answer
A software bill of materials records each component in a build: name, version, supplier, licence and where it sits in the dependency tree. It is generated automatically at build time, usually in the SPDX or CycloneDX format, and increasingly requested by enterprise buyers during procurement.
The reason it exists is speed. When a widely used library is found to be vulnerable, the question every customer asks is whether you use it. Without an SBOM that answer takes days of searching. With one it takes a query.
On this page
What an SBOM records
Formats and how it is produced
Two formats dominate. Both are machine-readable, and most tooling can convert between them, so the choice usually follows whatever your customer asks for.
| Format | Background |
|---|---|
| SPDX | An ISO-standardised format originating in licence compliance, common where legal review matters |
| CycloneDX | An OWASP project designed for security use cases, common in application security tooling |
Generate it in the build, not afterwards
An SBOM written by hand or produced weeks later describes something that no longer matches what you shipped. It should come out of the same pipeline that produces the artefact, so the two always correspond.
Why buyers ask for one
Incident response
When a major vulnerability lands, they need to know within hours which suppliers are affected.
Procurement policy
Regulated and government buyers increasingly require an SBOM as a condition of purchase.
Licence exposure
Legal teams check for copyleft terms that could affect how the product is distributed.
How Osto generates SBOMs
Osto’s code security module produces an SBOM as part of the same process that runs SAST and SCA, alongside open-source licence compliance. The inventory therefore stays aligned with the dependency findings rather than sitting in a separate tool, and when a customer asks whether a newly announced vulnerability affects you, the answer comes from the same place the evidence lives.
Free security assessment
Answer the next dependency scare in minutes
Osto generates your SBOM in the same pipeline that runs SAST and SCA, so the inventory always matches what you shipped.
Get a free security assessment Book a platform walkthroughSPDX and CycloneDX · Generated at build · One platform, everything
Frequently asked questions
What does SBOM stand for?
Software bill of materials. It is a machine-readable inventory of every component in a piece of software, including name, version, supplier, licence and dependency relationships.
Is an SBOM the same as SCA?
No. SCA is the analysis that identifies components and checks them against vulnerability and licence data. The SBOM is the inventory artefact itself, which can be shared with a customer. Most SCA tools generate one.
Which SBOM format should we use?
SPDX and CycloneDX are both widely accepted, and tooling converts between them. Generate whichever your customers request, and keep it produced automatically at build time.
Do we have to share our SBOM with customers?
Increasingly yes for regulated and government buyers, and often on request in enterprise procurement. Some organisations share a reduced version listing components without internal structure, which is generally accepted.