Notifications
Clear all
Topic starter
02/08/2026 11:35 am
TL;DR: Artifact scanners can tell you what is inside a build output, but not how it was assembled, and that gap matters when mutable tags, shared pipeline templates, and time-dependent dependency resolution can change production binaries without a code commit, according to OXSecurity. Execution lineage, not snapshot scanning, is becoming the control that distinguishes routine rebuilds from supply chain risk.
NHIMG editorial — based on content published by OXSecurity: Pipeline bills of materials and the CI/CD blind spot
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.
Questions worth separating out
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.
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.
Q: What do security teams get wrong about supplier SBOMs?
A: They often assume receipt equals assurance.
Practitioner guidance
- 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.
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.
👉 Read OXSecurity's analysis of PBOMs, rebuild drift, and CI/CD security blind spots →
PBOMs and CI/CD drift: what IAM and security teams need to know?
Explore further
02/08/2026 12:49 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Pipeline bills of materials expose the blind spot in CI/CD security
