Why do build pipelines create supply chain risk even when SBOMs exist?

Why a pipeline can still create supply chain risk after the SBOM is published

An SBOM is a snapshot, not a guarantee. If the build pipeline can fetch dependencies, run scripts, reuse tokens, or sign outputs after the SBOM is generated, the released artifact can diverge from the inventory you reviewed. The risk is not the existence of the SBOM, but the amount of trust you place in everything that happens after it.

That distinction matters because build systems often have broad access to source, package registries, signing material, and deployment destinations. A pipeline compromise can therefore change what ships, not just what was approved, and the SBOM may no longer describe the exact binary or container that reaches production.

Where the release path drifts away from the bill of materials

The drift usually comes from mutable steps in the pipeline. A dependency update, a malicious postinstall script, a poisoned build cache, or a compromised runner can alter the artifact without changing the original source review outcome. If those steps are automated, the change can happen faster than a human approval process can catch it.

This is also why transient build agents and automation credentials matter. A short-lived runner is still dangerous if it can access registries, artifact stores, or signing services, because the agent becomes the place where trusted material is assembled, transformed, and sometimes exfiltrated. CI/CD pipeline exploitation case study shows how a single exposed credential path can let an attacker turn a pipeline into a delivery mechanism.

In practice, the SBOM often describes intended composition, while the pipeline determines actual composition. If the release process does not preserve provenance from source to artifact, the SBOM can remain technically accurate for an earlier step and still be misleading for the shipped result.

What SBOMs do help with, and where they stop

SBOMs are still valuable for inventory, exposure analysis, and downstream response. They help teams identify what was expected to be present, compare releases, and assess whether a vulnerable component may exist in the software estate. They do not, by themselves, prove that the build path was clean, that the artifact was not modified, or that the dependency graph stayed fixed between scan time and release time.

That limitation becomes visible when build inputs are updated dynamically or when a package manager resolves versions at build time. The release may then include a different library, plugin, or transitive dependency than the one recorded in the SBOM generation step. For the same reason, provenance and artifact integrity controls matter as much as composition records. SLSA is useful here because it focuses on build provenance, not just package inventory.

For practitioners, the important question is whether the SBOM was generated from the exact artifact that was signed and deployed, or merely from an earlier build representation. If those are different objects, the SBOM should be treated as supporting evidence, not as proof of release integrity.

Risk and Threat Considerations

Pipeline risk is especially serious because attackers do not need to change the SBOM directly. They can target the build environment, compromise a maintainer token, tamper with a dependency source, or hijack a runner and let the pipeline produce a malicious artifact that still looks legitimate at inventory time.

Failure mechanism: The build process can introduce new code, new dependency versions, stolen credentials, or altered artifacts after the SBOM was created, so the published inventory no longer matches what is shipped.

Impact: Teams may trust an inaccurate material record, miss hidden backdoors or injected code, and delay response because the SBOM points investigators toward the wrong artifact state.

Practitioner Guidance

What to verify: Confirm that the SBOM is tied to the exact signed artifact, not just to the source tree or an intermediate build output. If your release process cannot prove that linkage, treat the SBOM as incomplete for release assurance.

What to prioritise: Lock down pipeline identities, runner permissions, and dependency resolution points before investing in more inventory tooling. The highest leverage control is reducing what the pipeline can change, fetch, or sign without additional scrutiny.

Common mistake: Treating SBOM generation as the end of supply chain assurance. The real control boundary is the path from commit to deployed artifact, including every automated step that can mutate content or access secrets.

Practitioner takeaway: An SBOM is only trustworthy when the build path is trustworthy, so pair composition records with provenance, artifact integrity, and tightly bounded pipeline access.

Related resources from NHI Mgmt Group

• Why do build and release pipelines create identity risk in supply chain security?
• Why do package publishing workflows create supply chain risk even when code reviews exist?
• Why does standing trust in build pipelines create supply chain risk?
• Why do build pipelines and developer workstations create the same supply chain risk?