What is an SBOM?

Modern software is assembled, not written from scratch. A typical application is a small amount of your own code sitting on top of hundreds of open-source libraries — each of which pulls in libraries of its own. A Software Bill of Materials is the list of everything in that stack.

The manufacturing analogy

Physical manufacturing has used bills of materials for decades. If a component in a car turns out to be defective, the manufacturer can identify every vehicle that contains it, because the bill of materials for each vehicle records exactly what went into it.

Software had no equivalent. When a vulnerability was announced in a widely used library, most organizations could not answer a simple question — do we use this, and where? — without days of manual investigation. An SBOM is the software industry's answer to that gap.

What an SBOM actually contains

• Components — every library, framework, and runtime included in the software.
• Versions — the exact version of each, because vulnerabilities almost always affect specific version ranges.
• Relationships — which components depend on which, so you can tell a direct dependency from one pulled in indirectly.
• Identifiers — standard names such as purl (Package URL), which allow a component to be matched reliably against vulnerability data.
• Supplier and licence information — where each component came from and under what terms it is used.

Direct and transitive dependencies

The components a team deliberately chose are the direct dependencies. Everything those components pull in is transitive. In most real applications, transitive dependencies outnumber direct ones by a wide margin — often ten to one.

That ratio is the reason manual tracking fails. Developers know what they added. Almost nobody knows the full transitive closure by memory. An SBOM records it automatically.

The standard formats

Two open formats dominate, and both are widely produced by build tooling and security scanners:

• SPDX (Software Package Data Exchange) — an ISO-standardised format that began with licence and provenance information and is now used broadly for component inventory.
• CycloneDX — a format designed from the start for application security and supply-chain risk use cases.

SBOMAtlas supports both, so SBOMs your pipeline already produces can be used without conversion.

Where SBOMs come from

An SBOM can be generated at build time by the pipeline that compiles the software, produced by a scanner analysing a finished artifact, or supplied by a vendor for software you have purchased. In practice a mature programme uses all three: pipeline-generated SBOMs for what you build, and vendor-supplied SBOMs for what you buy.

Having an SBOM is not the same as using one

This is where most SBOM programmes stall. An SBOM sitting in a folder tells you nothing. It becomes useful only when it is connected to three other things:

1. A product and version, so the inventory maps to something you actually ship or run.
2. Vulnerability data, continuously — because the SBOM does not change when a new CVE is published, but your risk does.
3. Deployment records, so a finding in a component can be traced to the customers actually affected by it.

That is the difference between having SBOMs and having software supply-chain visibility. SBOMAtlas exists to make that second thing possible: it collects SBOMs, links them to products and versions, analyzes every component for known vulnerabilities as they emerge, and connects each finding to the deployments — and the people — it affects.

What to do next

If your organization is receiving SBOMs from vendors, or generating them in CI, the useful next question is not "how do we get more SBOMs" but "what happens to the ones we already have?" That question is what the SBOMAtlas platform is built to answer.