What breaks when software composition analysis stops at the SBOM?

An SBOM gives visibility into what components are present, but it does not tell you which dependencies are exploitable, trusted, or malicious. If teams stop at the inventory layer, they can miss runtime exposure and package tampering, which are often the conditions that turn open source into an attack path.

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.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

SLSA, CIS Controls v8 and OWASP SAMM set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
SLSA	Supply-chain Levels for Software Artifacts	Supply-chain integrity and provenance directly address risks that an SBOM alone cannot detect.
Recommendation — Adopt SLSA-aligned provenance checks before trusting build artifacts or dependencies.
CIS Controls v8	CIS-16 — Application Software Security	This topic concerns secure software supply chain and dependency assurance in application delivery.
Recommendation — Embed dependency and provenance checks into software release gates.
OWASP SAMM	Software Assurance Maturity Model	The question is about moving from inventory to broader software assurance practices.
Recommendation — Measure whether security activities cover build, dependency, and release assurance, not just inventory.

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.