Skip to content
OrionHub Developer tooling and cloud development
Section
open-source
Kind
Editorial
Reading time
5 min
Updated
8 September 2026

Software Bills of Materials: What an SBOM Is Good For, and What It Is Not

What Is a Software Bill of Materials (SBOM) Good For, and What Is It Not?

An SBOM, or Software Bill of Materials, is a formal, machine-readable record of the components that make up a piece of software and the relationships between them. The question for a busy software engineer: why does that matter?

The simple answer is that an SBOM makes it far easier to identify vulnerabilities and track ingredient versions and dependencies. When a new security bug is announced, an SBOM lets you quickly identify if the bug affects your project and where to look for fixes. It shines a light on the full contents of a release and makes inspecting an application's ingredients a standard part of continuing engineering.

But an SBOM is not a guarantee of project security, a complete history of code provenance, or proof of whether a bug can actually be exploited in practice. It identifies vulnerabilities, but does not impugn them. Engineers who treat it as complete coverage are asking for trouble.

What Is an SBOM For?

The two leading formats for SBOMs are CycloneDX and SPDX, and both are widely adopted. [3][12][13], with a base document at least identifying the bill or manifest containing it, the product name, the product version, and the supplier name. [13] That core document can be stored in any acceptable format, though SPDX and CycloneDX are two of the most widely supported.

[REVIEW COMMENT: The term "user" is undefined, the history of "ratified standard" is wrong, and publication dates are missing]

An SBOM must be generated during the build process, and it is most useful if included at release.[6][11] The build-to-release process should include a scan and an alert workflow that checks artifact components against known-vulnerability databases. The SBOM does not need to be complete early in the process, but artifacts should carry up-to-date SBOMs by the time they are released to production.[7][8]

The practical, operational payoff of an SBOM is that it makes it far easier to answer whether a release has been affected by a new vulnerability. Once that answer is clear, an SBOM provides a starting point for case work to understand the risk.[9][14]

But what an SBOM cannot answer is whether the affected component actually creates a new vulnerability in the real-world deployment of a particular application, nor can it make specific suggestions on mitigation techniques. For network-level effects, those would need to come from separate testing in a slightly artificial release environment.

Inventory vs. Provenance

An SBOM will contain not just a list of components, but details tracing their source from a known supplier and their relationship to other software. That document becomes a bill-of-materials when it includes information about components, including their source and relationships. [4][10]

With software, tracking is typically handled through repos or other upstreams, meaning that SBOM vendors combine the artifact, the build, and some provenance data. [5]

Provenance work at the SBOM level is more burdensome, but git hashes or cryptographic digests attaching to each artifact do make this information transparent, if costly. An alternative is to use SBOM data stores that document who added a component to the artifact. In this system, commit metadata helps document the history for later audit. [10] [5] [14]

Where a binary is released without proper signing, provenance may be difficult to recover. This means that old acquire-time binaries or new binaries from an old deliverable can share the same inventory, but can be confused for analysis if provenance is not included.

SBOMs and Supplier Relationships

An SBOM can cover many kinds of dependencies, merchant packaging, source code, or static data. Attributing vendors is straightforward, and covering the source repository that evidence was pulled from is traceable, and used internally by most sbom vendors.[10]

During a defect in a vendor's supply chain, however, it is often important to be able to attribute defective components to a supplier's repository, and the repository to the vendor's systems. Many products that make public or private SBOMs find this to be an important need.[10]

When a supplier's repository is properly tagged, it is sometimes possible to look up and pull an artifact that would be coordinated with a public artefact at a point. This does require the upstream to expose their dependencies, so deployment security teams may make this disclosure conditional on trust.

How SBOMs Are Used

Some of the specific use cases that are commonly cited for using an SBOM:

  • Scanning releases for licensing data
  • Scanning releases for security bugs
  • Choosing between two versions of an artifact, when one is less vulnerable
  • Comparing two different versions of the same artifact
  • Patch management
  • Security point cases
  • Automated checks to keep build dependencies coordinated

These uses do not mean that you can't make use of an SBOM for other reasons, but they are the ones that are most commonly spelled out. Some security-specific tools interpret sboms based on the cvss score, and others allow you to include in the query builder a generic filter against suggested tags. [8] [9] [10] [14]

[TO ADD: response and response handling decision points would be newer additions to replace the ops security operator style tools, pervasive as they are]

What an SBOM should not be used to pretend or claim in an auditorium is that the software is defect free, or will protect you from any kind of breach. Attempting to redesign your application in terms of sboms would exclude longstanding secure engineering practices. Providing an sbom for free to customers would also expose you to improper roles for the information.[6][8][12]

With clear guidance on how to use the information, setting the SBOM as a protected artifact can allow license compliance agents, IP auditors, and security analysts to do their work without sharing the underlying artifact.

Conclusion

An SBOM identifies what a project includes and where. That makes it an invaluable tool for understanding if a vulnerability affects a particular release, but nothing more. An SBOM promotes accountability, but it does not guarantee security. When a vulnerability crops up, the SBOM's inventory is a starting point, but it is never a complete endpoint. To know if a bug matters in a particular app, exploitation context is still needed, and may come from different data sources.