Pipeline bills of materials expose the blind spot in CI/CD security

At a glance

What this is: This is an analysis of why artifact-only CI/CD security misses rebuild-driven drift, and why PBOM-style execution lineage is needed to explain how production software changed.

Why it matters: It matters to IAM and NHI practitioners because build identities, runner context, and pipeline permissions are part of the trust chain, not just the artifact they produce.

By the numbers:

• Supply chain attacks more than doubled in 2025, with 22% hitting CI/CD pipelines directly.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.

👉 Read OXSecurity's analysis of PBOMs, rebuild drift, and CI/CD security blind spots

Context

Pipeline security breaks down when teams treat the repository as the only source of truth. In practice, base images, dependency registries, shared templates, runner identities, and build-time variables can all change the final binary without a code diff, which makes artifact-only scanning a weak control for CI/CD security.

This is also an identity problem. Build systems rely on non-human identities, ephemeral runners, tokens, and automation permissions to fetch, compile, and publish software. If those identities and their lineage are not recorded, security teams can see the output but cannot explain who or what caused the drift.

Key questions

Q: What breaks when CI/CD security relies only on artifact scanning?

A: Artifact-only scanning breaks when the build process, not the source repository, becomes the source of change. Teams may see a passing SBOM and a clean vulnerability scan while the pipeline has pulled a different base image, resolved a newer dependency, or executed altered template logic. Without lineage, there is no reliable way to explain why the binary changed.

Q: Why do build identities matter in CI/CD security?

A: Build identities matter because runners, tokens, and pipeline permissions decide what code, packages, and scripts can enter the build environment. If those non-human identities are overprivileged or untracked, they can introduce unreviewed change, fetch untrusted inputs, or widen the blast radius of a compromised pipeline.

Q: What do security teams get wrong about supplier SBOMs?

A: They often assume receipt equals assurance. In reality, many organisations receive SBOMs rarely or not at all, and even when they do, the data may lack depth, freshness, or consistent machine-readable structure. Supplier transparency has to be enforced, verified, and operationalised, not simply requested.

Q: How should teams respond when a rebuild changes production without a code commit?

A: Treat it as a provenance event, not a routine scan result. Freeze promotion, compare the build lineage, verify runner identity and base image digests, and determine which upstream input caused the drift before allowing the new artifact to spread further.

Technical breakdown

Why artifact snapshots miss build drift

An SBOM is a list of components present after a build, but it does not preserve the conditions that produced those components. That means two builds with the same source can still diverge if a base image tag points to a new digest, a dependency registry returns a newer package, or a shared template changes the pipeline logic. The scanner sees a clean artifact and a clean policy result, yet it cannot tell whether the build path was deterministic or whether an unreviewed automation change altered the output. Practical implication: teams need lineage data, not just post-build inventory.

Practical implication: Track build inputs, runner identity, and dependency resolution so you can prove whether a rebuild was authorised.

What a pipeline bill of materials adds to CI/CD governance

A PBOM records the execution lineage of the build: which pipeline ran, which identity triggered it, which runner executed it, which base image digest was used, and which environment variables shaped the result. That context turns an opaque rebuild into a traceable event. It is especially relevant where shared pipeline templates propagate changes across many repositories, because one alteration can affect a large fleet at once. In identity terms, the PBOM makes non-human build actors visible enough to govern. Practical implication: use lineage to decide whether a rebuild is routine maintenance or unreviewed change.

Practical implication: Treat pipeline provenance as a first-class control so shared templates and automated rebuilds remain auditable.

Why deterministic builds now matter more than static scanning

Deterministic builds are the difference between a controlled release and an environmental lottery. When dependency resolution depends on registry state, cache timing, or mutable tags, the same commit can produce different binaries on different days. That drift can alter runtime behaviour without changing vulnerability counts, which is why scanner pass rates are no longer a reliable measure of trust. In mature CI/CD programmes, the security question shifts from “does the artifact match policy?” to “does the artifact still match the source and build path that approved it?” Practical implication: enforce pinned inputs and reproducible builds wherever rebuild frequency is high.

Practical implication: Use pinned digests, locked dependencies, and reproducibility checks to reduce non-deterministic rebuild risk.

Threat narrative

Attacker objective: The attacker or compromised automation aims to alter production software through the build process while avoiding code-review and artifact-scanning controls.

1. Entry occurs when a shared pipeline template, mutable tag, or scheduled rebuild introduces a new build input without a corresponding code change.
2. Credential access or build influence occurs when runner identities, tokens, or environment variables allow the pipeline to fetch altered dependencies or execute unreviewed build steps.
3. Impact occurs when the rebuilt artifact ships to production with changed runtime behaviour that scanners cannot attribute back to its source of drift.

NHI Mgmt Group analysis

Pipeline lineage is now a governance control, not an audit luxury. Artifact scanning answers what shipped, but it cannot explain why a rebuild changed when the source did not. That leaves security teams blind to pipeline drift, template inheritance, and dependency timing. In practice, execution provenance has become part of the trust chain for software delivery.

Build identities are non-human identities and should be governed that way. Runner credentials, pipeline tokens, and automation permissions are the actors that determine what gets fetched, compiled, and published. When those identities are not explicitly inventoried and constrained, a CI/CD system can silently become a privileged production pathway. The control gap is visible, assignable build identity, not more artifact alerting.

PBOM is the right named concept for this problem because it captures provenance, not just composition. SBOMs describe the artifact, but PBOMs describe the process that made it. That distinction matters when mutable tags, shared templates, and cached dependencies produce different binaries from the same commit. Practitioners should treat provenance as the evidence that makes rebuilds explainable.

Software supply chain risk is increasingly a timing problem, not just a vulnerability problem. The article’s core insight is that the risk lives in when and how inputs resolve, not only in whether a package contains a known CVE. That changes the governance model for CI/CD, because the decisive question becomes whether the delivery path is deterministic enough to be trusted. The practical conclusion is that teams must govern build-time change as tightly as source code change.

Identity and supply chain security are converging at the pipeline boundary. The article shows that build systems are now operational identity systems, because they decide which software identity reaches production. That intersection is where IAM, NHI governance, and DevSecOps need a shared control model. Teams that do not classify build runners, tokens, and templates as governed identities will miss the real source of drift.

What this signals

Execution provenance will become a standard control objective for high-change delivery environments. As rebuild frequency rises, teams will need to prove that production binaries match an approved path, not just a passing scan. That shift pushes provenance, runner identity, and build-time inputs into the same governance tier as source control and change approval.

Pipeline identities deserve the same lifecycle discipline as other privileged non-human identities. Service accounts, ephemeral runners, and CI/CD tokens increasingly control production outcomes, so entitlement review and offboarding cannot stop at application owners. For identity teams, the practical signal is that build systems are now part of the privileged access perimeter.

Artifact trust will increasingly depend on cross-linking build metadata, secrets hygiene, and supply chain evidence. Secret exposure inside pipelines is still one of the fastest ways to turn a rebuild into an incident, which is why lineage alone is not enough. Teams will need to pair provenance controls with strong secret handling and the control patterns discussed in Guide to the Secret Sprawl Challenge.

For practitioners

• Implement pipeline lineage capture Record pipeline ID, runner identity, trigger source, base image digest, and dependency resolution details for every production build so investigators can reconstruct how each artifact was produced.
• Pin build inputs and digests Replace mutable tags with pinned digests, lock dependency versions, and require reproducible builds for critical services so the same commit cannot produce unexplained output drift.
• Govern build identities as privileged non-human identities Inventory CI/CD service accounts, short-lived tokens, and runner permissions, then restrict them to the minimum access needed for fetch, build, and publish actions.
• Use drift detection on rebuilds Compare successive builds for identical source trees and alert when artifact size, dependency graph, or runtime inputs change without an approved source change.
• Differentiate clean artifacts from trusted releases Require evidence of lineage and provenance before promotion, because a passing scan does not prove the artifact was produced by an approved path.

Key takeaways

• CI/CD pipelines can change production software without any code commit, which makes artifact-only scanning an incomplete trust model.
• Pipeline lineage, runner identity, and build-time inputs are the missing evidence needed to explain rebuild-driven drift.
• Practitioners should treat build identities and reproducibility controls as core supply chain governance, not optional hardening.

Key terms

• Pipeline Bill Of Materials: A Pipeline Bill of Materials extends SBOM thinking into the delivery chain by recording what was used, transformed, and promoted during build and release. It matters because many supply chain risks are introduced after code is written, inside automation, packaging, and deployment steps.
• Model Lineage: Model lineage is the traceable record of what data, code, training runs, evaluations, and approvals produced a deployed AI model. It is the trust chain for machine learning operations, because it lets security and risk teams verify provenance, investigate changes, and support rollback or audit requirements.
• Non-Deterministic Build: A non-deterministic build is one whose outcome can change across environments even when the source code is the same. Different tool versions, lockfile interpretations, or package manager behaviour can alter dependencies and artefacts, which complicates debugging and assurance.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full article

OXSecurity's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of how PBOM records pipeline definition, runner identity, and environment variables across rebuilds.
• Concrete comparisons of SBOM versus PBOM outputs so practitioners can see what evidence is missing from snapshot-only scanning.
• Detailed explanations of non-deterministic build inputs such as mutable tags, cache timing, and shared template updates.
• Incident examples and reconstruction logic showing how rebuild-driven drift can be traced back to a specific pipeline change.

👉 The full OXSecurity article covers pipeline lineage, deterministic builds, and the rebuild scenarios scanners cannot explain.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need to govern privileged automation. It helps security teams connect identity controls to real operational risk across modern delivery pipelines.