A software bill of materials, or SBOM, is a structured inventory of the components inside a software product. It can name libraries, packages and other dependencies, record their versions and identifiers, and describe how those components relate to one another.
The practical value is simple: when a vulnerability or licensing question appears, the team has a list it can search. Without an inventory, responders may first have to reconstruct what was shipped, which version reached which customer and whether a vulnerable transitive dependency sits several layers down.
An SBOM is evidence about composition. It is not a certificate that software is secure, current or legally compliant.
What the inventory records
The US Cybersecurity and Infrastructure Security Agency’s 2025 minimum-elements guidance lists data fields for each component and for the SBOM itself. These include:
- the component name and version;
- an identifier that can distinguish the component;
- a cryptographic hash where applicable;
- license information;
- the dependency relationship between components;
- the SBOM author and the software producer;
- the tool used to create the SBOM;
- a timestamp and generation context.
The relationship field matters because a flat list can hide the path by which software arrived. An application may depend on a framework, which depends on a parser, which depends on a compression library. A graph lets a responder see whether a reported package is actually reachable through the delivered product.
Identifiers and hashes help match names that are ambiguous. They also reduce the risk that two packages with similar labels are treated as the same component. A hash identifies exact bytes, while a package identifier can point to a version in an ecosystem.
Direct and transitive dependencies
Developers usually choose direct dependencies. Package managers then install transitive dependencies required by those packages. The deeper components are easy to overlook in a manual spreadsheet, yet they can carry the same operational risk.
An SBOM generator can inspect source manifests, resolved lockfiles, build outputs or running systems. Each view answers a different question. A manifest shows declared intent; a lockfile shows resolved versions; a built artifact shows what was packaged. CISA’s guidance calls for recording the generation context so recipients understand which view they received.
That distinction is similar to the gap covered in our semantic versioning explainer: a version range describes what may be acceptable, while a lockfile records what a build selected. An SBOM intended for incident response is most useful when it represents the actual delivered artifact.
Common SBOM formats
The US National Telecommunications and Information Administration identifies three established formats: SPDX, CycloneDX and Software Identification Tags, or SWID. They use different schemas and histories, but all aim to exchange software identity and composition data in a machine-readable form.
Tool compatibility matters more than a familiar file extension. A useful workflow should be able to generate the chosen format, validate it, distribute it to the intended recipients and ingest updates. The producer and consumer should also agree on which fields and relationship types they require.
License fields can support a separate compliance review, but the label in an SBOM is only a starting point. Our comparison of MIT, Apache 2.0 and GPLv3 explains why obligations depend on the license and on how software is distributed.
How vulnerability matching works
When a new advisory names a package and affected versions, a security team can query SBOMs for matching identifiers. That can narrow thousands of products to the builds that may contain the component.
The first match is not the last step. Responders still need to determine:
- whether the component is present in the relevant artifact;
- whether the vulnerable code is reachable in that product;
- whether a mitigation or vendor patch changes the exposure;
- which customers or environments received the affected build.
False negatives are possible when the SBOM omits a component, uses an unrecognized identifier or is older than the shipped release. False positives are possible when a package is present but the vulnerable feature cannot be reached. Asset and release records therefore remain part of the response process.
Frequency, coverage and known unknowns
CISA’s 2025 guidance treats generation frequency, component coverage, known unknowns, distribution and update mechanisms as minimum operational elements. Those points make the inventory usable over time.
Generate an SBOM for each released build, or at another documented point that captures changes. State the depth of dependency coverage. Record when a tool could not identify a component instead of silently dropping it. Give recipients a dependable way to obtain corrected or newer versions.
Access control also matters. An SBOM may reveal internal package names or architecture details. Producers should decide who receives it and how integrity is protected while still making it available to customers and responders who need it.
What an SBOM cannot prove
An SBOM does not show that a dependency was reviewed, configured safely or free of malicious code. It does not guarantee that every component was detected. A complete inventory can still describe insecure software.
The SBOM should therefore sit beside vulnerability management, secure build practices, code signing, testing and incident response. Its role is to shorten discovery and improve traceability. It tells a team where to look and what was included; it does not make the risk decision for them.
