The core principle

Zero Trust is a security model built on a single assumption: no entity — user, system, service or network — should be trusted by default, regardless of its location. Every access request must be verified, every session must be authenticated, every permission must be justified.

In the context of CI/CD pipelines, this principle has immediate practical implications. A pipeline that has a static token granting broad access to production infrastructure violates Zero Trust fundamentally. It is trusted by default, has more access than needed, and its identity is verified once (at token creation) rather than at every operation.

What Zero Trust means for CI/CD

No persistent credentials. Instead of static API keys stored as repository secrets, pipelines use OIDC federation to obtain short-lived tokens for each specific job. The token expires minutes after the job completes. Nothing to steal, nothing to rotate.

Least privilege, enforced. Each pipeline job gets only the permissions it needs for its specific task. A build job doesn’t need deployment permissions. A test job doesn’t need access to production secrets. Granular permission scoping means that even a compromised job has limited blast radius.

Verification at every step. Artifact signing (Cosign) ensures that what reaches production is exactly what the pipeline built. SBOM attestation provides a verified inventory. Branch protection rules ensure that code changes go through review. Each step verifies, rather than trusts, the previous one.

Audit trail by design. Every action in the pipeline generates a verifiable log entry. Not as an afterthought — as a core property of the system. When the auditor asks “who deployed what, when, from which source code?” — the answer is in the data, not in someone’s memory.

Zero Trust is not a productZero Trust is an architecture principle, not a tool you can buy. Implementing it in CI/CD requires changes to how pipelines authenticate (OIDC), how artifacts are verified (Cosign), how access is scoped (per-job permissions) and how changes are governed (branch protection, required reviews). No single product delivers all of this.

The practical starting point

For most organizations, the path to Zero Trust in CI/CD starts with three actions: replace static credentials with OIDC federation, restrict GITHUB_TOKEN permissions to the minimum per job, and enable branch protection rules requiring reviews before merge. These three changes address the most common violations and can be implemented incrementally without disrupting existing workflows.

Read also:

Zero TrustDevSecOpsFundamentalsArchitecture