What breaks when software composition analysis stops at the SBOM?

When the inventory becomes the whole control

SBOMs are valuable because they tell you what is in the package, but software composition analysis has to answer a different question: what is safe to run, trust, or continue shipping. When teams stop at the bill of materials, they confuse visibility with assurance. That leaves a gap between component inventory and actual exposure, which is where most real supply-chain risk lives.

At that point, the control only records presence, not exploitability. A dependency can be listed, widely used, and still be unsafe because of a known vulnerability, malicious provenance, transitive reach into runtime paths, or a build-time manipulation that the inventory never shows.

That is why a plain SBOM is a starting point for assurance, not the finish line. It supports triage, but it does not by itself establish whether a package should be allowed, blocked, replaced, or monitored more closely.

What SBOMs miss about exploitable dependencies

An SBOM answers component provenance at a static level, but exploitation depends on context: version, reachability, configuration, call path, privilege, and whether the vulnerable code is actually invoked. Two applications can contain the same library and face very different outcomes if one exposes the affected function and the other never loads it in production.

That is why software composition analysis needs runtime and build-context signals. Teams should distinguish between merely present, actively used, externally reachable, and tampered. Without that separation, they tend to overestimate safe software and underestimate hidden exposure.

Supply chain trust also depends on integrity, not just inventory. A component can appear in an SBOM and still be malicious if the package was compromised upstream, swapped in transit, or injected through a compromised dependency chain. For that reason, SLSA is a useful companion control because it focuses on build provenance and artifact integrity rather than component listing alone.

What practitioners need beyond an SBOM

Effective software composition analysis combines inventory, vulnerability intelligence, provenance checks, and policy enforcement. The goal is not simply to know that a package exists, but to decide whether it should be trusted in the specific environment where it runs.

That means correlating SBOM data with dependency reachability, patch status, package origin, signing or verification signals, and any evidence of unexpected behavior in the build or runtime pipeline. Open source ecosystems often provide the raw materials for that workflow, but the workflow only works if teams operationalize more than component lists. The OpenSSF ecosystem is a practical reference point for supply-chain security guidance and tooling around that broader model.

For teams building a stronger supply-chain program, NHIMG’s AI Supply Chain Security and AI-BOM Guide is useful because it extends the same principle: inventory matters, but provenance, tampering, and credential containment decide whether the component can be trusted.

Risk and Threat Considerations

Stopping at the SBOM creates a false sense of control. Attackers do not need every dependency to be vulnerable, they only need one exploitable or substituted package that is actually reachable in the target environment.

Failure mechanism: The inventory layer records component presence, but the team never validates reachability, provenance, or runtime integrity. That leaves malicious packages, trojaned updates, and exploitable transitive dependencies outside the decision process.

Impact: Organisations can ship software that looks compliant on paper while remaining exposed to package tampering, known CVEs, and compromised build inputs. The result is preventable exposure, weaker incident response, and slower containment when a dependency turns hostile.

Practitioner Guidance

What to verify: Treat the SBOM as one input to a trust decision, not the decision itself. Verify whether each flagged dependency is reachable in the deployed path, whether the source is signed or otherwise provenance-checked, and whether runtime telemetry shows the package behaving as expected.

What good looks like: A mature program can answer three questions for each material component: is it present, is it exploitable here, and is it trustworthy enough to keep. If any one of those answers is unknown, the software composition analysis is incomplete.

Practitioner takeaway: The control goal is not a perfect inventory, but a defensible trust decision. SBOMs improve visibility, yet only provenance, exploitability, and runtime context tell you whether a dependency is safe to ship.

Related resources from NHI Mgmt Group

• What breaks when software composition analysis does not identify all dependencies accurately?
• What breaks when Software Composition Analysis is not integrated into developer workflows?
• What is the difference between point-in-time SBOM attestation and continuous software composition analysis?
• What is the difference between software composition analysis and an SBOM in open source security?