A software bill of materials is a structured inventory of the components inside a software product. It can help a team locate an affected dependency when a vulnerability is disclosed. It does not prove that the product is secure, that every component is reachable at runtime, or that the list is complete.
The useful question is not “does this product have an SBOM?” but “which build does this SBOM describe, how deep does it go, and can we match its component identities to the systems we operate?” That inventory complements checks such as tracking software dependency risk and verifying a reproducible build.
What an SBOM is supposed to contain
CISA describes an SBOM as a nested inventory: a list of ingredients that make up software components. The NTIA minimum-elements report, published July 12, 2021, turns that idea into a baseline record.
For each component, the report identifies seven minimum data fields:
- supplier name;
- component name;
- component version;
- other unique identifiers;
- the dependency relationship;
- the author of the SBOM data;
- a timestamp.
Those fields solve an identification problem. “Logging library” is too vague to match against an advisory. A supplier, package name, version and identifier such as a Package URL can give an inventory system something precise to compare.
The dependency relationship matters too. A product may include a component directly or inherit it through another package. That distinction helps a team understand why the component is present and which part of the build may need to change.
Machine-readable formats make the list operational
A PDF table can be read by a person, but it is awkward to compare against thousands of vulnerability records. NTIA therefore includes automation support in its minimum elements and names SPDX, CycloneDX and SWID tags as examples of machine-readable formats.
A buyer does not need to mandate one format merely because it is familiar. It does need to make sure the producer and consumer can exchange the file without losing identifiers, relationships or version data. A file that parses but strips dependency links is less useful than it looks.
The format also does not create accurate data by itself. An automated scanner can miss dynamically downloaded modules, platform-specific packages or components introduced after the build. The generation method and the point in the delivery pipeline are part of the evidence.
An SBOM is not a vulnerability report
An SBOM tells you what is believed to be present. A vulnerability database tells you that a version or identifier has been associated with a published issue. Neither statement, on its own, proves whether the vulnerable code can be reached in this product.
CISA separates that question with the Vulnerability Exploitability eXchange, or VEX. A VEX document is an attestation about whether a product is affected by a known vulnerability. It can add context such as a component being present but the vulnerable function not being used.
That does not make VEX an automatic exemption. The attestation needs a product identity, the vulnerability identifier, a status and reasoning a reviewer can evaluate. If the product or build changes, the conclusion may need to be revisited.
The practical sequence is:
- identify the exact product and build;
- ingest its SBOM;
- match component identifiers to current vulnerability information;
- investigate whether the affected code is reachable;
- record remediation or a supported VEX conclusion;
- repeat when the build or vulnerability data changes.
Completeness is a claim that needs a boundary
An SBOM can cover only direct dependencies, or it can traverse several layers of transitive dependencies. It may include operating-system packages, bundled libraries, containers and build tools—or omit some of them. A “complete” label is meaningless without the scope.
Ask where the SBOM came from. A source-code scan, a package-manager lockfile, a container image and a running system see different parts of the product. The best answer may combine methods and explain known gaps.
NTIA includes “known unknowns” among its practices and processes. That is useful discipline. If a producer cannot determine the version of a proprietary embedded component, recording that limitation is better than silently leaving it out.
Frequency also matters. An SBOM generated for version 4.2 should not be treated as the inventory for version 4.3. A continuously delivered service can change faster than a procurement review, so the buyer needs a way to obtain a current record.
Authenticity and delivery need their own controls
A precise SBOM can still be attached to the wrong binary. Link the document to the released artifact with a build identifier, digest, signed provenance record or another verifiable reference. Keep the supplier’s original file and record when it was received.
Access also needs thought. Publishing an SBOM can improve transparency, but some suppliers distribute detailed inventories only to customers or security teams. The access model should not prevent the people responsible for vulnerability response from obtaining it quickly.
Do not treat confidentiality as proof of quality. Whether public or restricted, the file should still identify its author, timestamp, scope and relationship to a release.
A procurement checklist that asks for evidence
When evaluating a product, request:
- the SBOM for the exact version or service release being assessed;
- the format and schema version;
- the generation method and pipeline stage;
- the depth of transitive dependency coverage;
- the treatment of containers, operating-system packages and dynamically loaded components;
- known omissions;
- the update cadence and delivery route;
- the way the SBOM is bound to the released artifact;
- the supplier’s process for vulnerability notices and VEX statements.
Then test the file. Parse it with the system that will consume it. Choose a few components visible in the product’s package metadata and see whether they appear with usable identifiers. Check that dependency relationships survive import.
This is similar to testing a data export before switching software: the existence of a file is not the same as a usable result.
What an SBOM cannot prove
An SBOM cannot prove that code has no vulnerabilities, that the build process was uncompromised, or that the listed components are configured safely. It does not replace source review, secure build controls, penetration testing, patch management or incident response.
It also does not automatically establish license compliance. Component identities can support a license review, but the applicable licenses, notices, modifications and distribution obligations still need to be checked.
Treat the SBOM as a map. A current, well-identified map makes investigation faster. It does not certify that every road is safe.
