Why do CI/CD pipelines complicate zero trust architecture?

Because pipelines act as autonomous software identities that need to authenticate, request resources, and trigger actions without human presence. Zero trust assumes continuous verification, but build systems often combine high privilege with machine speed and limited context. That makes identity proof, policy enforcement, and logging more important than perimeter controls.

Why This Matters for Security Teams

zero trust architecture assumes every request must be verified, but CI/CD changes the shape of the problem by turning software delivery into a high-speed identity system. Pipelines authenticate to source control, package registries, cloud APIs, secrets managers, and deployment targets, often with broad privileges and little human oversight. That makes them a critical NHI surface, not just an engineering convenience. NIST’s NIST SP 800-207 Zero Trust Architecture emphasizes continuous evaluation of identity and context, but pipelines frequently outrun the governance model that supports it. NHIMG’s Guide to the Secret Sprawl Challenge shows why secret leakage and credential reuse remain persistent pipeline risks. In 2025, GitGuardian detected 59% of compromised machines in a major supply chain attack were CI/CD runners rather than personal workstations, underscoring that the build system itself can become the breach point. In practice, many security teams encounter pipeline privilege problems only after a leaked token has already been used to pivot, not through intentional design review.

Zero trust does not fail because the principle is wrong. It fails because many pipelines still behave like trusted automation islands, where service accounts, cached tokens, and long-lived secrets substitute for runtime proof. The result is a mismatch: the policy expects short-lived, contextual access, while the platform grants durable access to fast-moving workloads. That is why NHIs in delivery systems must be treated as first-class identities, with explicit issuance, scoped actions, and auditable revocation.

How It Works in Practice

The practical answer is to redesign the pipeline so it proves what it is, what it is doing, and for how long it may do it. Workload identity should be the baseline, not a backup plan. For many teams that means SPIFFE or OIDC-based identity for runners, then policy evaluation at request time rather than at pipeline creation time. NIST’s NIST Cybersecurity Framework 2.0 reinforces that governance, protection, and detection should operate as continuous functions, which fits CI/CD better than static approval gates alone. NHIMG’s CI/CD pipeline exploitation case study and the Reviewdog GitHub Action supply chain attack both illustrate how quickly a compromised workflow can expand its blast radius once a token or action is trusted broadly.

• Issue JIT credentials per job, not shared credentials per environment.
• Bind secrets to task scope and TTL, then revoke them automatically when the task ends.
• Use policy-as-code for deployment, signing, and registry access so decisions are made at runtime with context.
• Segment runners so build, test, and release identities are not interchangeable.
• Log every privileged action with identity, workload, and artifact provenance.

This is where Zero Standing Privilege matters operationally: a pipeline should only hold the access needed for the current step, not a standing token that survives retries, forks, or compromised dependencies. For agent-like pipelines or AI-assisted workflows, current guidance suggests moving from static RBAC toward intent-based authorisation because the workload’s next action cannot always be predicted in advance. These controls tend to break down when self-hosted runners share network trust and cached credentials across jobs because the boundary between one workflow and the next disappears.

For deeper implementation patterns, the Guide to SPIFFE and SPIRE is useful for workload identity design, especially where teams need cryptographic proof of runner identity rather than reusable secrets.

Common Variations and Edge Cases

Tighter pipeline control often increases delivery overhead, requiring organisations to balance deployment speed against revocation discipline and policy complexity. That tradeoff becomes visible in environments with ephemeral runners, multi-cloud releases, and third-party actions, where every integration adds another identity to verify. There is no universal standard for this yet, but current guidance suggests separating build-time and deploy-time privileges, then using different trust rules for each. In container-heavy workflows, the risk shifts again: secrets can leak from environment variables, image layers, or orchestration metadata, so a pipeline that is “zero trust compliant” in theory may still expose credentials through adjacent systems. GitGuardian’s 2025 research found 4.6% of public GitHub repositories contained at least one hardcoded secret, which is a reminder that leakage often starts in developer tooling long before deployment.

The biggest edge case is when pipelines become partially autonomous, such as agent-assisted release flows or tools that modify code, open pull requests, and trigger deployments. In those cases, the access model should focus on intent, not just role. The question is no longer “is this account allowed?” but “is this action appropriate for this workload at this moment?” NHIMG’s Guide to the Secret Sprawl Challenge is a good reference point for the operational consequences of that shift. For governance and audit alignment, the Ultimate Guide to NHIs — Regulatory and Audit Perspectives helps connect pipeline controls to evidence, ownership, and revocation. In practice, the hardest failures happen when a pipeline’s identity is correct but its authority is broader than the task it is actually performing.

Related resources from NHI Mgmt Group

• Why do non-human identities complicate zero trust architecture?
• Why do NHIs complicate zero trust and least privilege efforts?
• Why do Active Directory service accounts complicate zero trust programs?
• Why do non-human identities increase zero trust risk?