Why do unpinned dependencies increase identity risk in CI/CD pipelines?

Why This Matters for Security Teams

Unpinned dependencies turn a build step into a moving trust boundary. A pipeline may expect the same package name, action, or container tag every run, but without a fixed version, the code behind that name can change silently. That matters because CI/CD runners often hold repository secrets, package publishing tokens, signing keys, and cloud credentials. Once malicious code executes in the build context, it can exfiltrate those secrets or modify later stages of the delivery chain.

This is not a theoretical hygiene issue. NHIMG research on supply chain attacks and secret exposure shows how quickly trusted automation can become the entry point for credential theft, including cases like the Reviewdog GitHub Action supply chain attack and the CI/CD pipeline exploitation case study. NIST CSF 2.0 also treats supply chain and identity assurance as core governance concerns, not just developer convenience. In practice, many security teams discover dependency drift only after a trusted workflow has already been used to harvest secrets or alter release artifacts.

How It Works in Practice

The identity risk comes from the fact that the dependency reference itself becomes an authorization shortcut. If a workflow imports an action by branch name, floating tag, or mutable package alias, the pipeline is not just consuming code, it is delegating execution to whatever content currently sits behind that label. That weakens provenance and makes the dependency behave like an ungoverned non-human identity with changing behaviour.

Current guidance suggests treating build-time dependencies as verified identities, not convenience pointers. That usually means pinning to an immutable version or digest, verifying signatures where available, and limiting the permissions granted to the job that consumes the dependency. It also means separating read-only build identities from higher-risk release identities, so a compromised test job cannot immediately publish artifacts or mint new secrets.

• Pin package versions, container digests, and workflow actions to immutable references.
• Use short-lived tokens for the runner, with scope limited to the single task.
• Store secrets in a manager, then inject them only when the job needs them.
• Review dependency provenance and update paths as part of change control.
• Apply alerting when a previously trusted reference changes unexpectedly.

NHIMG’s Ultimate Guide to NHIs shows how widely secrets leaks and overly broad privileges still affect enterprises, and that pattern carries directly into CI/CD when dependencies are left mutable. The practical identity lesson is that the build system is only as trustworthy as the weakest reference it executes. These controls tend to break down in fast-moving mono-repos and heavily cached runners because teams rely on convenience updates that bypass review.

Common Variations and Edge Cases

Tighter pinning often increases maintenance overhead, requiring organisations to balance supply chain integrity against update velocity. That tradeoff is especially visible in ecosystem-heavy pipelines where actions or packages release frequently and version churn is part of normal operations.

There is no universal standard for this yet, but best practice is evolving toward layered controls rather than a single rule. Some teams pin everything to exact digests, others allow only signed releases from trusted publishers, and some add policy-as-code checks that block floating references at merge time. The right choice depends on how much blast radius the workflow has and how much trust the organisation places in upstream maintainers.

Edge cases matter. Internal packages can still be risky if release permissions are broad. Forked actions can drift from upstream without clear provenance. Cached dependencies can preserve a safe version today while leaving the pipeline exposed on the next cache miss. For teams studying real-world failure patterns, the 52 NHI Breaches Analysis and the Guide to the Secret Sprawl Challenge both reinforce a common theme: once secrets and execution references are allowed to drift, attackers rarely need a new identity, only a mutable one.

Related resources from NHI Mgmt Group

• Why do CI/CD pipelines create non-human identity risk?
• Why do CI/CD pipelines increase lateral movement risk?
• How can teams reduce risk from transitive dependencies in CI/CD pipelines?
• What is the difference between prompt injection risk and identity abuse in agents?