Zero Trust for CI/CD: Securing the Software Delivery Pipeline

The traditional model of CI/CD security relies on a perimeter defense: once a build agent is inside the corporate network or connected to the repository, it is trusted to execute commands, access secrets, and deploy artifacts. This assumption collapsed under the weight of supply chain attacks like SolarWinds and Log4j. In these scenarios, attackers did not need to breach the firewall; they compromised the pipeline itself. The mechanism of failure is simple: static credentials and long-lived secrets allow an attacker who gains access to one node to move laterally across the entire delivery pipeline without detection. To secure the software delivery pipeline, we must replace the concept of a "trusted network" with a Zero Trust architecture where every request, every build step, and every artifact is verified.

The Failure of Perimeter Security in Pipelines

In a standard pipeline, the build agent (often a runner or worker) is assigned a long-lived secret, such as an API key or a static SSH token. When the agent connects to the repository to fetch code, it presents this token. The repository verifies the token once and grants access. If an attacker compromises the build agent—perhaps by injecting malicious code into a dependency like the Log4j vulnerability—they now possess a valid, active credential. The pipeline sees this request and thinks, "This agent is authorized," and proceeds to build and deploy the compromised code.

This is a failure of trust boundaries. The pipeline assumes that if the network connection is established, the actor is legitimate. However, in modern distributed systems, the "network" is often the internet itself, and the "perimeter" is porous. The mechanism of attack here is credential reuse and lateral movement. Once the attacker holds the static token, they can impersonate the build agent indefinitely, accessing secrets stored in vaults, pushing malicious artifacts to registries, and deploying to production. The lack of context means the system cannot distinguish between a legitimate build and a malicious one because both use the same static identity.

Machine Identities and Ephemeral Credentials

Zero Trust resolves this by shifting authentication from static secrets to dynamic, ephemeral machine identities. Instead of a long-lived API key, the pipeline uses OpenID Connect (OIDC) to generate a short-lived, cryptographically signed token for each specific build run.

Consider a scenario with a GitHub Actions workflow. Previously, you might have stored a GCP service account key as a secret. Now, you configure the workflow to use OIDC. When the job starts, GitHub acts as an Identity Provider (IdP). It generates a JSON Web Token (JWT) that includes specific claims: the repository name, the branch, the job ID, and the runner environment. This token is valid for only a few minutes. The cloud provider (e.g., Google Cloud Platform) validates this token against its trust policy.

The mechanism works like this:

1. Request: The build agent requests access to deploy a container.
2. Token Generation: The CI/CD provider (GitHub/GitLab) issues a temporary JWT signed with a private key, binding the request to the specific pipeline run.
3. Validation: The target system (Cloud Provider) checks the signature and verifies the claims. It ensures the token was issued by a trusted IdP for the correct repository and that the token has not expired.
4. Revocation: Once the job completes, the token expires. There is no secret to steal. Even if an attacker exfiltrates the token from the build logs, it is useless after a few minutes or if the pipeline run ID changes.

This approach eliminates the "standing permission" problem. An attacker cannot replay a token because the claims include the unique job_id and run_id. If they try to use the token in a different context or after the expiration window, the validation fails. This is the core of Zero Trust: verify explicitly, least privilege, and assume breach.

SLSA Levels and Artifact Attestation

While ephemeral credentials secure the identity of the build process, they do not inherently guarantee the integrity of the output. A compromised build agent with valid ephemeral credentials could still produce malicious binaries. This is where the Supply-chain Levels for Software Artifacts (SLSA) framework comes in. SLSA defines levels of assurance for the software supply chain, moving from Level 1 (basic) to Level 4 (highest).

The mechanism for achieving SLSA compliance involves provenance and attestation. Provenance is a record of the history of the artifact: what source code was used, what build script ran, what inputs were consumed, and who executed the build. Attestation is the cryptographic signature attached to the artifact that binds this provenance to the build.

Tools like in-toto provide a framework for link-based verification that can produce SLSA-compliant provenance, while Sigstore provides the signing infrastructure required to secure these attestations. The pipeline generates an attestation file (a JSON object) that describes the build process. This file is signed by the ephemeral identity discussed in the previous section. When the artifact is pushed to a registry, the attestation is stored alongside it.

For example, in a Level 3 SLSA implementation:

1. The build environment is ephemeral and isolated (no persistent state).
2. The source code is fetched from a verified repository.
3. The build script is executed in a container. While network isolation is a common implementation choice to enhance security, Level 3 primarily focuses on reproducible builds and integrity controls rather than mandating a complete lack of external network access.
4. Upon completion, the system generates a signed attestation linking the artifact hash to the source commit and the build script.

When a consumer (like a production cluster) pulls this artifact, it does not just check the hash. It verifies the attestation signature and checks that the provenance claims match the expected build environment. Verification logic focuses on checking the iss (issuer) claim within the attestation against a trusted identity provider policy to ensure the identity binding is valid, rather than relying solely on a standard X.509 CA chain. If the artifact was built by a compromised agent that tried to modify the source code, the attestation will not match the source hash, or the signature will be invalid because the ephemeral identity was revoked or the claims do not align.

The Pipeline as a Zero Trust Control Plane

Combining ephemeral credentials and SLSA attestation creates a closed loop of trust. The pipeline becomes a Zero Trust Control Plane where no artifact can be promoted without a valid, time-bound identity and a verified provenance chain.

Imagine a deployment pipeline moving code from Staging to Production.

1. Identity Check: The deployment job requests a token from the CI/CD provider. The token is scoped only to the "staging" environment and expires in 5 minutes.
2. Build Verification: The artifact produced in Staging carries an SLSA Level 3 attestation. The signature proves it was built in an isolated environment using the specific source code commit.
3. Promotion Gate: Before the artifact is moved to Production, the gatekeeper service verifies two things:
   • The deployment request is signed by a valid, non-expired ephemeral token issued for the correct repository.
   • The artifact's attestation is valid and matches the SLSA Level 3 requirements (e.g., no external network calls during build, source code matches the commit).
4. Execution: Only if both checks pass does the system allow the artifact to be pulled and deployed.

If an attacker tries to inject a malicious binary into the pipeline, they face two walls. First, they cannot forge the ephemeral token because they do not have access to the CI/CD provider's signing keys. Second, the combination of OIDC and SLSA creates a dual-layer defense where a breach in one layer is insufficient for an attack. Even if an attacker could bypass one layer, they would fail at the other.

This architecture fundamentally changes the threat model. The attacker is no longer looking for a way to steal a static secret; they are looking for a way to bypass cryptographic verification. While not impossible, the barrier is significantly higher. The pipeline no longer trusts the network; it trusts the math.

Implementing this requires a shift in tooling and process. You must configure OIDC providers, set up attestation generation, and enforce SLSA levels in your deployment gates. It is a complex migration, but it is the only viable path for securing the software supply chain in an era where the perimeter no longer exists. The goal is not to prevent all attacks, but to ensure that any compromise is detected before it reaches production, and that the impact is contained within the ephemeral window of the build.

The tradeoff is complexity. Managing ephemeral tokens and verifying attestations adds latency and requires robust error handling. However, the cost of a supply chain breach far outweighs the operational overhead of Zero Trust. As the software supply chain becomes more interconnected, the assumption of trust is the single point of failure. Zero Trust removes that assumption, replacing it with cryptographic proof.

Conclusion

Securing the software delivery pipeline requires abandoning the illusion of a safe internal network. By adopting Zero Trust principles, organizations can leverage ephemeral machine identities to eliminate standing permissions and use SLSA attestation to cryptographically verify artifact integrity. This combination creates a secure control plane where trust is never assumed, but constantly verified through cryptographic proofs. While the implementation demands significant architectural changes, it provides the necessary defense against sophisticated supply chain attacks that have become prevalent in the modern development landscape.

Common Pitfalls

1. Assuming Network Isolation is Enough: Relying solely on network segmentation without ephemeral credentials leaves the pipeline vulnerable to lateral movement if the perimeter is breached.
2. Misinterpreting SLSA Levels: Confusing SLSA Level 3 requirements with Level 4. Level 3 ensures integrity and provenance but does not mandate that the build environment be completely air-gapped from all external networks.
3. Ignoring Token Scope: Configuring OIDC tokens with overly broad permissions (e.g., admin access) negates the benefits of ephemeral credentials, as a stolen token still grants excessive privileges.

Practical Takeaways

1. Principle of Least Privilege: Always scope ephemeral tokens to the minimum permissions required for the specific job, never granting broad administrative rights.
2. Verify, Don't Trust: Treat every artifact as untrusted until its attestation is cryptographically verified against the source code and build environment claims.
3. Shorten the Window: Minimize the lifetime of credentials. If a token must exist, it should expire in minutes, not hours or days.

FAQ

Q: Is SLSA Level 3 mandatory for all organizations? A: No. SLSA levels are a maturity model. Level 3 is a strong baseline for most organizations, ensuring integrity and provenance. Level 4 offers the highest security with fully automated, reproducible builds but requires significant infrastructure investment.

Q: Can I use SLSA without changing my CI/CD provider? A: Yes. Most major providers (GitHub Actions, GitLab CI, Jenkins) support OIDC and SLSA attestation generation via plugins or built-in features, though configuration varies by platform.

Q: How do ephemeral credentials handle secrets like database passwords? A: Ephemeral credentials do not store secrets themselves. Instead, they grant temporary access to a secrets manager (like Vault or AWS Secrets Manager) which then issues short-lived database credentials to the application.