What should teams do when a supplier SBOM looks clean but feels incomplete?

What a “clean” SBOM misses when the build story is incomplete

An SBOM can accurately list declared components and still miss material risk if the supplier did not expose how the software was actually assembled. The gap is usually in the build inputs, vendored code and source provenance, not the manifest itself. Teams should treat the SBOM as one artifact in a larger evidence set, then verify whether what was built matches what was reported.

That distinction matters because an SBOM is a dependency inventory, not proof of completeness. If the supplier vendors code, generates assets during build, or packages copied source outside normal dependency resolution, those elements may never appear as obvious package entries. Cross-checking the manifest against the source tree and build inputs helps you spot where hidden licence obligations, stale code or unresolved vulnerabilities may sit.

For a practical reference point, the SBOM Guide is useful when you need to compare SBOM quality, generation methods and downstream vulnerability correlation rather than assuming the manifest alone tells the full story. If the supplier cannot explain how vendored components were detected, the SBOM should be treated as an incomplete evidence package, not a final assurance document.

What evidence should teams ask for beyond the manifest?

The most useful next question is not “Does the SBOM exist?” but “What was counted, and how was it counted?” Ask for the source tree, build recipe, dependency lockfiles, vendoring rules and any scanning or generation step that would catch embedded code. This is especially important when the product is compiled, bundled or repackaged, because the material you care about may be incorporated before the SBOM is produced.

A supplier that can only provide a manifest but not the surrounding build evidence has not really proven component completeness. Teams should also look for signs that package names, file paths, generated assets and vendor directories were reviewed together, because that is where hidden code often shows up. The right standard is traceability from source to build output, not just a polished inventory.

The Open Source Security Guide helps teams connect SBOMs to dependency management, licence risk and vulnerable packages, while the AI Supply Chain Security and AI-BOM Guide usefully extends the same discipline to supply-chain evidence and provenance thinking. The common lesson is that inventory quality depends on the underlying build discipline, not the document format alone.

How should procurement and security use a clean SBOM in acceptance decisions?

A clean SBOM should move the conversation forward, not end it. If the supplier cannot explain vendoring, generated code or non-standard build steps, acceptance should remain conditional until the missing evidence is provided. That is because the absence of a listed component is only meaningful when the generation process would have been capable of seeing it.

Teams should also distinguish between “no known vulnerable dependency in the manifest” and “no embedded code risk in the release.” Those are not the same assurance claim. Where vendored material exists, the real control question becomes whether the supplier can show detection, review and accountability for that embedded code before release.

The OpenSSF provides a useful external anchor for supply-chain security and project-health thinking, while the NIST Cybersecurity Framework 2.0 supports the broader governance pattern of identifying, protecting and verifying supplier-controlled technology inputs. For teams evaluating supplier releases, that means the SBOM should inform trust, not replace it.

Risk and Threat Considerations

A superficially complete SBOM can hide the part of the release most likely to carry licence, vulnerability or provenance risk. Embedded or vendored code may evade ordinary package-level review, which creates a false sense of confidence and leaves teams blind to code that was brought in outside standard dependency resolution.

Failure mechanism: The supplier generated the SBOM from declared dependencies or packaging metadata, but did not reconcile it against vendored source, build inputs or copied code, so material content was never counted.

Impact: Teams may accept a release that contains unreviewed code, miss licence obligations, and overlook exploitable components that are present in the shipped artifact but absent from the manifest.

Practitioner Guidance

What to verify: Confirm that the supplier can trace the release back to source, build inputs and vendoring rules, not just to an SBOM export. If they cannot explain how embedded code was detected, treat the manifest as incomplete evidence.

Decision rule: If the SBOM is clean but the build path is opaque, do not sign off on it as final. Require a reconciliation between declared components, source tree contents and any vendored or generated material before acceptance.

Practitioner takeaway: The right question is not whether the SBOM looks tidy, but whether it is complete enough to support trust in the shipped artifact.

Related resources from NHI Mgmt Group

• How should security teams handle third-party access that looks legitimate after a supplier breach?
• What should security teams do when a message looks and sounds authentic but feels unusual?
• What should teams do when AI reports clean pentest results but risk still feels unresolved?
• How should security teams prioritise vulnerabilities when CVE metadata is incomplete?