What an SBOM Can—and Cannot—Tell You

A practical guide to software bills of materials, component identity, dependency graphs, vulnerability matching, VEX, freshness, provenance, and operational use.

Naked News Desk · September 26, 2026

A software bill of materials can answer a narrow but valuable question: which software components does a producer claim are associated with a particular product or build? It cannot, by itself, prove that the product is secure, that every component is present, that a reported vulnerability is exploitable, or that the file describes what is actually running.

The distinction matters because an SBOM is often treated as either a compliance document that solves supply-chain risk or a noisy list with no operational value. Both views miss the point. An SBOM is structured inventory evidence. Its usefulness depends on identity quality, coverage, provenance, freshness, and the decisions connected to it.

What an SBOM records

CISA’s 2025 minimum-elements document treats an SBOM as a formal record of software components and their supply-chain relationships. It groups the baseline into data fields, automation support, and practices and processes, including generation frequency, depth, known unknowns, distribution, access control, and accommodation of mistakes.

At a useful minimum, a consumer needs to determine:

• which product, release, artifact, or build the document describes;
• who created the SBOM and when;
• component names, versions, suppliers, and useful identifiers;
• dependency or containment relationships;
• how completely the analysis covered transitive and bundled components;
• which tool and generation context produced the result;
• whether an updated document supersedes it.

A component name without a precise identity is weak evidence. “OpenSSL” or “logging library” may not distinguish a package ecosystem, fork, supplier, version, build, or patched downstream distribution. Package URLs, cryptographic hashes, CPEs, persistent document identifiers, and supplier coordinates can help, but each identifier has a scope and failure mode.

Choose a format for interoperability, not branding

Two widely implemented standards are SPDX and CycloneDX. The current SPDX 3.0.1 specification defines a system-oriented data model with profiles for software, licensing, security, builds, AI, datasets, and other domains. The CycloneDX specification overview describes a BOM object model covering metadata, components, services, dependencies, vulnerabilities, compositions, and related evidence.

The formats overlap but are not identical. A team should choose based on the producers, consumers, fields, versions, validators, and exchange paths it actually supports. Converting syntax does not repair missing identity or provenance. A valid JSON document can still describe the wrong artifact perfectly.

Record the exact specification version. Validate documents against the matching schema and semantic rules. Preserve unknown fields during processing when possible, and test round trips before relying on format conversion in a compliance or incident workflow.

Generate at the point with the best evidence

Different generation stages see different things:

• a source manifest knows declared direct dependencies but may omit resolved versions;
• a lockfile captures resolution but not necessarily files copied outside the package manager;
• a build system can observe inputs and generated artifacts;
• a container scanner sees installed packages and files but may lose source relationships;
• runtime discovery sees deployed components but may miss dormant or dynamically loaded code;
• a supplier SBOM can include private build knowledge unavailable to a downstream scanner.

No single viewpoint is always complete. For important software, compare producer-generated, build-time, artifact, and operational evidence. Differences are findings to investigate, not automatically errors in one tool.

Generate an SBOM for an immutable artifact, not merely for a repository branch. Bind it to a digest, release identifier, or signed attestation. If the product is rebuilt, patched, or repackaged, issue a new version. An old SBOM with a familiar product name may be worse than no inventory because it creates false confidence.

Vulnerability matching is a join, not a verdict

An SBOM helps a team ask whether a newly disclosed vulnerable component may be present. The basic workflow joins component identities and versions against advisory data. Each stage can fail:

• the component may be missing or misidentified;
• ecosystem version rules may be interpreted incorrectly;
• a distribution may backport a fix without changing the upstream-looking version;
• multiple advisories may describe the same issue differently;
• the vulnerable code may be excluded, unreachable, disabled, or mitigated;
• the component may be exploitable even though no public identifier exists yet.

Therefore, “CVE matched” means investigate. It does not always mean exploitable. “No CVE matched” means no match was found in the consulted data; it does not prove safety.

CISA’s SBOM resources library distinguishes inventory from Vulnerability Exploitability eXchange information. VEX can communicate whether a product is affected, not affected with justification, fixed, or still under investigation. That assertion needs a trustworthy issuer, precise product identity, current analysis, and evidence appropriate to the consequence.

What an SBOM does not prove

An SBOM alone does not establish:

• that source code, build workers, dependencies, or distribution channels were uncompromised;
• that the listed source produced the shipped binary reproducibly;
• that every dependency and embedded file was discovered;
• that components were configured securely;
• that secrets, malicious code, unsafe behavior, or exploitable design flaws are absent;
• that licences were interpreted correctly or obligations were fulfilled;
• that deployed systems match the described release;
• that a vulnerability is reachable in the product’s real execution path;
• that the producer will issue timely updates.

It also does not replace secure development. NIST’s Secure Software Development Framework describes a broader set of practices for preparing an organization, protecting software, producing well-secured releases, and responding to vulnerabilities. Component inventory supports those practices; it is not the whole programme.

Test the document before accepting it

A procurement team should not stop at “SBOM provided.” Apply measurable acceptance tests:

1. Subject binding: Does the document identify the exact artifact or release received?
2. Schema validity: Does it validate under the declared standard version?
3. Identity quality: Do important components have ecosystem-aware identifiers and versions?
4. Relationship coverage: Are direct, transitive, bundled, generated, and service dependencies represented or explicitly scoped out?
5. Known unknowns: Does the producer state where collection was incomplete?
6. Freshness: When is a new SBOM issued, and how are consumers notified?
7. Integrity: Can the consumer verify the origin and detect modification?
8. Operational match: Does sampling the delivered or deployed artifact support the claims?
9. Vulnerability response: Is there a path for VEX, advisories, remediation, and corrected SBOMs?
10. Access and retention: Can authorized responders obtain the document during an incident, including after a product is retired?

Sample difficult cases: statically linked libraries, vendored source, language packages inside containers, base images, operating-system packages, plugins downloaded after installation, firmware, commercial components, and cloud services. A high component count is not evidence of quality; it can indicate better depth, duplicate records, or indiscriminate scanning.

Connect inventory to decisions

An SBOM creates value only when a process consumes it. Useful integrations include:

• blocking a release when prohibited components or licences appear;
• finding affected products after an advisory;
• prioritizing investigation by exposure, reachability, and business impact;
• comparing supplier claims with artifact and runtime discovery;
• tracking unsupported or abandoned dependencies;
• informing customer notices and incident scoping;
• measuring how quickly teams identify and remediate exposure.

Keep raw SBOMs as evidence, but normalize carefully into an asset model for search and correlation. Preserve the original document, issuer, timestamp, standard version, subject digest, and transformation history. Otherwise, a central inventory can lose exactly the provenance needed during a dispute.

A useful mental model

Treat an SBOM like a map. A good map identifies important objects and relationships, has a scale and date, declares gaps, and helps someone plan a route. It does not prove that every road is safe or that conditions have not changed.

The practical objective is not to collect the largest possible BOM. It is to maintain sufficiently complete, artifact-bound, machine-readable inventory that makes vulnerability response, supplier communication, and software decisions faster and more defensible.