Why are SBOMs not enough to secure the software supply chain?

Why This Matters for Security Teams

An SBOM is useful for inventory and vulnerability triage, but it is only one layer of software supply chain assurance. It tells teams what components were observed at a point in time, not whether the artifact was produced by a trusted builder, whether the dependency graph was altered after review, or whether the package reached production through an approved pipeline. That gap matters because attackers increasingly target build systems, package registries, signing keys, and automation identities rather than the source code alone.

Current guidance from the OWASP Non-Human Identity Top 10 is especially relevant here because modern delivery pipelines rely on service accounts, workload identities, tokens, and other NHI that can be abused to publish, sign, or promote software without human intervention. If those identities are weakly governed, a perfect SBOM can still accompany a compromised release. In practice, many security teams discover that SBOMs were treated as a compliance artefact only after a malicious or tampered build has already entered the release process, rather than as part of a controlled trust chain.

How It Works in Practice

Secure supply chain programs usually treat SBOMs as an input to decision-making, not as the decision itself. Teams need provenance to answer who built the artifact, from what source, using which build steps, and under what controls. They also need signing and verification so downstream systems can reject untrusted packages, even when the package contents appear acceptable. This is where standards like Supply-chain Levels for Software Artifacts and the UK NCSC software supply chain guidance become operationally useful.

A practical control stack usually includes:

• Generating SBOMs at build time, then attaching them to the release artifact.
• Producing provenance metadata that links source, builder, dependencies, and pipeline steps.
• Signing artifacts and validating signatures before promotion or deployment.
• Restricting build and publish rights to tightly governed non-human identities.
• Applying policy checks in CI/CD, registry, and deployment stages so untrusted artifacts are blocked automatically.

This approach also helps incident response. If a dependency is later found to be malicious, provenance and signing data show which builds are affected, which environments received them, and whether the artifact was modified after attestation. Frameworks such as the NIST software supply chain and DevOps security guidance reinforce that resilience depends on integrity controls across the pipeline, not on visibility alone. These controls tend to break down when organisations depend on ad hoc build scripts, long-lived tokens, or manually promoted releases because identity sprawl makes it impossible to prove which system actually created the software.

Common Variations and Edge Cases

Tighter supply chain controls often increase delivery overhead, requiring organisations to balance release speed against stronger trust guarantees. That tradeoff becomes sharper in multi-team environments, where different product lines use different build systems, package managers, and approval flows. There is no universal standard for exactly how much provenance detail every pipeline must retain, so current guidance suggests prioritising the highest-risk paths first: internet-facing services, regulated workloads, and anything that can update production automatically.

SBOMs remain valuable for open-source dependency management, but they are less decisive when the risk comes from build tampering, compromised maintainers, or malicious publishing credentials. In those cases, a complete component list does not prove integrity. The same is true for container images and machine learning packages, where the question is not only what was included but whether the artifact was assembled from trusted sources and signed by an identity with legitimate authority. Where agentic automation is involved, provenance and policy become even more important because an AI-enabled pipeline may be able to trigger releases, fetch dependencies, or rotate secrets without a human in the loop.

For teams handling regulated data or critical services, it is usually better to define minimum trust requirements for release acceptance than to assume an SBOM satisfies the control objective on its own. That distinction is the difference between inventory and assurance.

Related resources from NHI Mgmt Group

• How should organisations use SBOMs to improve software supply chain governance?
• Why is provenance generation alone not enough to reduce software supply chain risk
• What is the difference between software supply chain risk and NHI risk?
• What is the difference between SaaS supply chain security and software supply chain security?