A software bill of materials (SBOM) is a machine-readable inventory of the components in a software product and how those components relate to one another. It helps your team identify potentially affected software when a vulnerability or licensing issue emerges—but it is an input to security work, not proof that software is safe.
What an SBOM is
The National Telecommunications and Information Administration (NTIA) defines an SBOM as “a formal record containing the details and supply chain relationships of various components used in building software.” Think of it as an ingredients list for software: it records what is included and, where known, how components depend on one another.
An SBOM is useful only if people and systems can produce, share, ingest, and act on it. A file that exists but cannot be matched to the software your organization runs is of limited practical value.
What information an SBOM contains
NTIA’s baseline minimum-element framework covers seven data-field types, plus expectations for automation and operational practices:
#1 Best Overall
- Supplier: who provides the component.
- Component name and version: which component is included and which version is identified.
- Other unique identifiers: identifiers that help distinguish the component.
- Dependency relationship: how components relate to or depend on one another.
- SBOM data author: who created the record.
- Timestamp: when the SBOM data was recorded.
- Automation and process: support for automatic generation and machine readability, along with practices for requesting, generating, distributing, and using SBOMs.
These are minimum-element categories, not a guarantee that every SBOM will provide complete visibility into every dependency. The record’s context and quality matter.
How SBOM generation affects what the record shows
CISA’s 2025 guidance describes three points at which an SBOM may be generated. Each gives the team a different evidence context:
Rank #2
| Generation stage | What it is based on | What to consider |
|---|---|---|
| Before a build | Repository or source information | It describes components indicated by source or repository data; it may not establish exactly what contributed to a finished artifact. |
| During a build | Components that contributed to a releasable artifact | It can reflect the build context, so preserve which artifact and build the SBOM describes. |
| After a build | Binary analysis of the resulting software | Analysis of the artifact may not recover the exact dependencies used at build time. |
When evaluating an SBOM, ask how it was produced, when it was produced, and which software artifact it represents. NIST cautions that a retroactively generated SBOM may not reproduce the exact dependencies used during the build.
Why your team needs an SBOM
Find software that may be affected by a vulnerability
When a vulnerability is disclosed, teams can compare the affected component and version with SBOM records to find software that may be involved. That narrows the investigation: it helps identify where to check, but does not by itself confirm that a product is vulnerable or determine the risk.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Improve software and supplier inventory
Component and relationship data can help teams understand what is present in the software they build, buy, or operate. That inventory can support other security tools and practices and give teams better information about software supply chains.
Support license management
Component records can also help organizations identify software dependencies relevant to license review. An SBOM is an inventory aid; it does not replace the organization’s process for assessing license obligations.
Rank #4
Connect component data to security workflows
NIST guidance discusses machine-readable SBOMs in applicable federal procurement contexts, supplier access, repositories, and integration with vulnerability-detection capabilities for automated alerting. These are federal guidance considerations, not a universal legal requirement for every private company or every software purchase.
How to make an SBOM useful in practice
- Define scope. Decide which internally built software, purchased products, and suppliers are in scope, and specify when an SBOM should be requested or generated.
- Require interoperable, machine-readable output. CISA’s 2025 guidance identifies SPDX and CycloneDX as widely used formats and recommends accepting widely used, interoperable, machine-processable formats. NTIA’s 2021 material also named SWID tags; that earlier list should not be mistaken for CISA’s 2025 discussion of widely used formats.
- Capture generation context. Record whether the SBOM is source-derived, generated during the build, or produced through post-build analysis, and connect it to the relevant software and release.
- Set distribution and maintenance rules. Establish who can request and access SBOMs, where they are stored, how often they are updated, and how errors or corrections are handled.
- Make the data actionable. Ensure your organization can ingest and manage the records, then connect them to vulnerability-management workflows so relevant alerts can be investigated.
- Keep broader supply-chain controls. Continue supplier-risk assessment and other security practices; an SBOM complements these capabilities rather than replacing them.
What to evaluate in an SBOM workflow or tool
Compare approaches against the work your organization needs to do, rather than treating a format or generated file as a security outcome.
Best Value
- Generation stage and artifact coverage: which products and releases are represented, and at what point the record is created.
- Component identification and dependency depth: how components are named and identified, and how relationships are represented.
- Format support: whether the workflow produces and accepts interoperable, machine-processable formats such as SPDX or CycloneDX.
- Ingestion and storage: whether your systems can parse the data, associate it with software inventory, and keep records accessible.
- Distribution and updates: how suppliers provide records, who receives them, and how changes and corrections are handled.
- Vulnerability-monitoring integration: whether component information can feed alerting and investigation workflows.
What an SBOM cannot tell you
An SBOM is not a security certification, a guarantee that software is vulnerability-free, or proof that every component has been captured. Its completeness depends on how it was generated and what was visible at that point. In particular, post-build analysis may not reconstruct the exact dependencies used during a build.
NTIA describes SBOMs as a foundational data layer for additional security tools and practices, not a solution to all software-security problems. Use the inventory alongside vulnerability management, supplier-risk assessment, and other risk-based supply-chain practices.
Quick Recap
Official guidance
- NTIA: The Minimum Elements for a Software Bill of Materials (SBOM)
- CISA: 2025 Minimum Elements for a Software Bill of Materials (SBOM)
- NIST SP 800-161 Rev. 1, Update 1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
- NTIA: Software Bill of Materials resource library
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
