Zero-trust — the security model based on ‘never trust, always verify’ — is now a cornerstone of modern cybersecurity, as formalized in National Institute of Standards and Technology (NIST) SP 800-207. Yet, despite this progress, CI/CD pipelines — the engines driving software delivery — often sidestep these principles by treating automation as inherently trustworthy.
This article highlights a critical blind spot in pipeline security: The gap between job identity and runtime trust. Here’s how organizations can finally close it.
Static Secrets and Implicit Access: Still Too Common
Despite advances in DevSecOps tooling, many CI/CD pipelines continue to rely on long-lived credentials or inherited cloud permissions. For example, a typical GitHub Actions workflow might look like this:
In cloud-hosted runners, such as those running on Elastic Compute Cloud (EC2), jobs can even inherit identity and access management (IAM) roles automatically:
These patterns introduce several risks:
No Isolation Between Jobs: If one workflow is compromised, it can access shared credentials.
Over-Permissioned Roles: Credentials often persist longer than necessary and may grant broader access than needed.
No Audit Trail: It is difficult to trace actions back to a specific workflow or user.
OIDC Tokens: A Step Forward — But Not a Complete Solution
To address the risks of static secrets, platforms like GitHub and GitLab now support OpenID Connect (OIDC). This allows continuous integration (CI) jobs to request short-lived, signed identity tokens with metadata about the repository, branch and actor.
Here’s an example of a secure GitHub Actions workflow using OIDC:
OIDC is a major improvement: It eliminates the need for stored secrets and provides traceability. But it only verifies who requested the job — not how securely it runs.
Identity is Not the Same as Trust
OIDC tokens authenticate the origin and configuration of a job, but they don’t verify the runtime environment.
Why does this matter?
- CI runners may be shared across teams or tenants, increasing the risk of lateral movement
- Base images may be outdated or lack integrity checks, introducing vulnerabilities
- No Built-In Attestation: There is no way to prove the runner’s security posture at runtime
A valid OIDC token can still be used in an insecure or compromised environment. In other words, zero-trust demands more than just job identity — it requires verifying where and how the job runs.
Workload Attestation: Bridging the Trust Gap
Modern security models are starting to use workload attestation to validate the environment before granting access. This means verifying the state of the operating system, container image or secure boot configuration.
Common attestation signals include:
Trusted Platform Module (TPM) or Virtual Trusted Platform Module (vTPM)-backed secure boot measurements
- Validation of signed container images or software bill of materials (SBOMs)
- Kernel version and node identity checks
- Secure production identity framework for everyone (SPIFFE)/ SPIFFE runtime environment (SPIRE) to issue identity only to verified workloads
Here’s an example of SPIRE policy for trusted Kubernetes runners:
If the runner passes all policy checks, it receives a workload identity, and only then is it allowed to access sensitive resources.
Policy-Based Identity Brokers: Enforcing Zero-Trust
To bring all these checks together, many teams are adopting policy-based identity brokers. These brokers:
- Accept the OIDC token and attestation data from the CI/CD job
- Evaluate them against policy (for example, using Open Policy Agent [OPA])
- Issue short-lived credentials only if all conditions are met
Example policy logic using Open Policy Agent (OPA):
This approach ensures both intent (OIDC) and execution trust (attestation) are verified before access is granted.
Why Does This Model Matter?
By combining OIDC with runtime attestation, organizations achieve:
Elimination of long-lived secrets
Least privilege access based on real-time environment checks
Auditable automation activity with full traceability
Alignment with NIST zero-trust, SBOM compliance and Internet Engineering Task Force (IETF) workload identity in a multi-system environment (WIMSE) proposals
This reflects a shift from authenticating ‘who’ to verifying ‘who, where and how’.
Key Takeaways
- Retire static secrets in favor of OIDC tokens
- Validate runtime environments using attestation
- Enforce policies dynamically with identity brokers
- Treat CI/CD pipelines as untrusted until proven otherwise
Final Note
CI/CD jobs are powerful — they build, test and deploy code directly to production. However, many organizations still treat them as trusted by default.
Zero-trust isn’t just for human users. By verifying both job identity and runner integrity, you ensure that only compliant, secure pipelines can access critical systems.
Start today: Audit your pipelines for static secrets and explore tools like SPIRE or OPA to close the trust gap.
