A governance gap where the identities, permissions, and execution paths used in software delivery change faster than security teams can track them. It often appears in CI/CD, where workflows, tokens, and runners are added informally and outlive their intended purpose.
Expanded Definition
pipeline identity Drift describes a condition where the identities, permissions, tokens, runners, and execution paths inside delivery pipelines change faster than the organisation can inventory and govern them. The term covers both approved change that is no longer tracked and informal additions that quietly become part of production delivery.
It is narrower than general access sprawl because the drift is tied to software delivery and automation paths, especially CI/CD systems. It is also broader than a single secret leak, because the issue is the accumulation of unowned or stale machine access across pipeline stages. In practice, the boundary is often missed when teams treat pipeline accounts as temporary by default, even though many persist long after the workflow that created them has changed.
Industry usage is still evolving, but the governance problem is well understood: the delivery pipeline becomes a moving identity surface, and that surface can outpace review, rotation, and offboarding. For a broader NHI governance frame, Ultimate Guide to NHIs is a useful reference point.
Examples and Use Cases
Pipeline identity drift shows up in ordinary delivery operations rather than only in mature breach scenarios. Common examples include:
- A build workflow gets a new cloud token for a one-off release, then the token remains valid after the workflow changes.
- A self-hosted runner is added for testing, but its access scope is never reduced when it is promoted into a broader deployment path.
- A deployment script begins calling additional APIs over time, creating new permissions that no one formally reviews.
- A temporary service account is copied into a parallel pipeline and then becomes an undeclared dependency for release automation.
- Secrets move between code, CI variables, and runner configuration as teams work around delivery friction, increasing the number of places that must be governed.
The implementation tradeoff is speed versus traceability. Delivery teams often add identities and permissions to keep releases moving, but every shortcut expands the number of access paths that need ownership, expiry, and review. That is why the boundary between “working automation” and “governed automation” matters more over time than it does on day one.
When a pipeline spans multiple tools or repositories, the drift can be spread across several administrative domains, which makes the problem harder to notice than a single misconfigured account.
Security Implications
Pipeline Identity Drift creates a security blind spot because the organisation may assume delivery access is temporary, scoped, or centrally known when it is not. The result is stale credentials, excess privilege, and execution paths that remain trusted after the people who added them have moved on.
This can lead to unauthorized code changes, release tampering, secret exposure, and persistence inside build or deployment systems. If a runner, token, or pipeline account is compromised, the attacker may inherit the same trust that release automation uses to reach source control, artifact stores, cloud environments, or production deployments. The failure mechanism is usually not a single broken control, but an accumulation of unmanaged exceptions that weaken review, rotation, and revocation.
NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which helps explain why pipeline-linked identities are often discovered late rather than governed continuously. A common practitioner signal is that teams can name the toolchain, but not the exact identities and permissions each stage depends on.
Once drift exists across several pipelines, the blast radius grows quietly because each informal exception becomes part of the delivery trust chain.
Domain and Governance Relevance
In NHI governance, Pipeline Identity Drift matters because software delivery systems are full of non-human identities that authenticate, authorize, and act on behalf of engineering teams. When those identities drift, ownership becomes unclear and lifecycle controls become inconsistent, which weakens the assurance around builds, tests, releases, and rollback paths.
The governance challenge is not just “do we have credentials,” but “do we still need these credentials, who owns them, and what system depends on them today?” That question changes the interpretation of access review, offboarding, and least privilege for CI/CD because the pipeline itself is an active identity environment, not a passive transport layer. In environments with many automation layers, this term is a reminder that machine identity governance must follow the release process, not trail it.
For practitioners managing NHI-heavy delivery estates, this also affects accountability. If the pipeline is allowed to grow informally, security reviews become retrospective and control evidence becomes incomplete, which undermines both operational trust and auditability.
Risk and Threat Considerations
Pipeline Identity Drift is materially risky because delivery systems concentrate privileged machine access in places that are often lightly reviewed and heavily reused. The threat is not only secret leakage, but also trust abuse inside the software supply chain, where compromised pipeline identities can be used to alter code, inject artifacts, or expand into production-adjacent systems.
Failure mechanism: Drift accumulates when tokens, service accounts, runners, and workflow permissions are created for speed, then outlive their intended purpose. Over time, stale or excessive access weakens revocation, obscures ownership, and gives attackers or insiders durable execution paths that blend into normal delivery activity.
Impact: The likely consequences are unauthorized deployments, secret theft, release tampering, persistence in CI/CD infrastructure, and a wider blast radius across source control, artifact stores, and cloud environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | Pipeline drift often leaves CI/CD tokens and keys untracked or overstayed. |
| NHI-03 — Permissions and Access Boundaries | Drift commonly expands pipeline permissions beyond the workflow's intended scope. | |
| NHI-04 — Lifecycle and Offboarding | The term centers on identities that outlive the delivery path that created them. | |
| Recommendation — Inventory pipeline credentials, rotate them on schedule, and revoke stale machine access immediately. Tighten pipeline scopes to least privilege and remove unused execution permissions. Offboard obsolete pipeline identities and delete abandoned runners, tokens, and service accounts. | ||
| CIS Controls v8 | 5 — Account Management | Pipeline identity drift is an account lifecycle and ownership problem in delivery tooling. |
| 6 — Access Control Management | Pipeline access drift maps to excessive or lingering access in CI/CD environments. | |
| Recommendation — Maintain an authoritative inventory of pipeline accounts and disable accounts that lack a current owner. Enforce least privilege for build and deployment access paths and review exceptions regularly. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Attackers may alter pipeline accounts or permissions to persist in delivery systems. |
| T1552 — Unsecured Credentials | CI/CD drift often leaves exposed secrets in workflows, configs, and runner settings. | |
| Recommendation — Monitor for unauthorized changes to CI/CD accounts, roles, and tokens as persistence indicators. Detect and remove exposed pipeline secrets before they are reused for access or lateral movement. | ||
