Workload identity federation for CI/CD pipelines is becoming necessary

At a glance

What this is: This analysis argues that CI/CD pipelines have become a prime NHI risk because static secrets, broad permissions, and fragmented federation still leave build systems overexposed.

Why it matters: IAM and NHI teams need to treat pipeline access as a governance problem, because secretless authentication helps only if trust, scope, and audit controls are consistent across environments.

By the numbers:

• GitGuardian’s 2026 report found 28.65 million new hardcoded secrets on public GitHub in 2025, a 34% year-over-year increase.
• The Shai-Hulud 2 supply chain attack found that 59% of compromised machines were CI/CD runners rather than developer workstations.

👉 Read Aembit’s analysis of workload identity federation for CI/CD pipelines

Context

CI/CD pipelines are not just build automation. They are NHI-heavy trust zones where service credentials, API tokens, deployment roles, and runner permissions converge, which means one compromise can cascade into production access. That makes the problem less about build speed and more about whether identity controls can keep pace with how software is actually shipped.

The article’s core claim is that workload identity federation reduces secret exposure by replacing persistent credentials with short-lived, cryptographically asserted access. That is directionally right, but federation only works as governance when teams can manage trust policies, scope, and auditability across multiple cloud and SaaS targets. For broader NHI framing, see the Ultimate Guide to NHIs.

Key questions

Q: How should security teams replace CI/CD secrets without breaking deployments?

A: Start by identifying which workflows truly need cloud or SaaS access, then issue short-lived credentials through OIDC federation instead of storing reusable keys. Keep the trust policy narrow, tie it to specific repositories and branches, and test the rollout in non-production paths first. The goal is not just fewer secrets, but smaller blast radius.

Q: When does workload identity federation create less risk than static CI/CD secrets?

A: It reduces risk when the target service trusts runtime claims, the token lifetime is short, and the role scope matches the job. If teams still reuse broad roles, duplicate trust rules across systems, or leave audit gaps, federation lowers secret exposure but leaves governance weak. The model is safer only when policy stays tighter than the old secret sprawl.

Q: What is the difference between secret rotation and workload identity federation?

A: Secret rotation keeps the same basic model and changes the credential on a schedule. Workload identity federation removes the stored credential from the pipeline and replaces it with a runtime exchange for a temporary token. Rotation reduces persistence, while federation removes the long-lived secret from the workflow entirely. Both help, but federation changes the architecture more deeply.

Q: Why do CI/CD pipelines complicate zero trust architecture?

A: 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.

Technical breakdown

Why static CI/CD secrets create credential debt

Static credentials in pipelines behave like accumulated debt because they persist after the job finishes, spread into logs and configs, and often outlive the systems that created them. In practice, a deployment token can be copied into environment variables, runner images, and helper scripts, then reused long after the original need has passed. That turns routine automation into standing access. The risk is not only theft, but also scope creep: credentials granted for convenience tend to become broadly permissive over time. Practical implication: teams should inventory where pipeline secrets exist, who can read them, and how long they remain valid.

Practical implication: teams should inventory where pipeline secrets exist, who can read them, and how long they remain valid.

How workload identity federation changes pipeline authentication

Workload identity federation shifts authentication from stored secrets to runtime proof. A pipeline presents an OIDC-backed identity claim, the target service verifies the trust relationship, and temporary credentials are issued for a narrow task window. The key architectural change is that the pipeline no longer needs a reusable secret to authenticate. That removes the easiest theft path and makes compromise more time-bound. But federation does not erase trust decisions. It simply moves them into policies that define which repository, branch, environment, or runner may receive access. Practical implication: secure the trust policy as carefully as any credential vault.

Practical implication: secure the trust policy as carefully as any credential vault.

Where native federation still leaves a governance gap

Native federation works well for a single cloud or one-to-one integration, but CI/CD environments rarely stop there. Real pipelines often authenticate to multiple clouds, internal services, and SaaS tools, each with its own trust configuration and audit trail. That creates fragmented identity governance and makes it harder to enforce consistent context rules such as runner posture or deployment window. From an NHI perspective, the problem is not only whether access is secretless. It is whether every workload identity is governed under the same policy model across all destinations. Practical implication: consolidate policy and logging before federation sprawl becomes the next control gap.

Practical implication: consolidate policy and logging before federation sprawl becomes the next control gap.

Threat narrative

Attacker objective: The attacker aims to turn build-system trust into durable access to production environments, secrets, and downstream cloud services.

1. Entry via malicious pull request changes that trigger automated workflows and hidden CI script execution.
2. Escalation through theft of runner-exposed secrets, personal access tokens, or pipeline session material.
3. Impact through reuse of stolen credentials to access production infrastructure and internal systems.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD pipelines are now NHI governance surfaces, not just developer tooling. Once build systems store deploy keys, cloud tokens, and API secrets, they become identity infrastructure with production impact. That changes the control objective from pipeline uptime to access discipline. Teams should treat every workflow that can touch production as a governed non-human identity.

Workload identity federation reduces secret theft, but it does not eliminate trust debt. Short-lived tokens are safer than static keys, yet each trust policy becomes a decision point that can be mis-scoped, over-permitted, or inconsistently applied. The field needs to stop framing secretless access as a finish line. Practitioners should see it as a better starting point for NHI governance.

Centralized governance is becoming the named concept here: federation sprawl. As pipelines authenticate to more clouds and SaaS tools, pairwise trust relationships multiply faster than teams can audit them. That creates an operational gap between authentication and governance. Practitioners should consolidate identity policy, logging, and review into one control plane before the sprawl becomes unmanageable.

Agentic AI will intensify pipeline identity pressure. AI coding assistants and autonomous workflow agents add more machine identities that can request access, mutate pipelines, or trigger deployments. That increases the number of trust edges without changing the underlying control model. Practitioners should assume the pipeline is becoming an execution environment for more than software builds.

Secrets removal is necessary, but access scope still defines the blast radius. Even when credentials are short-lived, overly broad role permissions can still expose production data or infrastructure. The security question is no longer whether a token is ephemeral. It is whether the token can do too much while it is alive. Practitioners should pair federation with least privilege and tight scope review.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which helps explain why pipeline and workload identities often evade basic governance controls.
• For a broader control model, review Ultimate Guide to NHIs - What are Non-Human Identities alongside pipeline federation policy.

What this signals

With 96% of organisations storing secrets outside secrets managers in vulnerable locations such as code and CI/CD tools, the control problem is already structural rather than exceptional. That makes CI/CD federation a governance decision, not a convenience feature, and it should be measured against NIST Zero Trust Architecture expectations rather than developer preference.

Federation sprawl: the next control gap is not whether a workload can authenticate, but whether every trust relationship can be reviewed, revoked, and audited consistently. If pipeline identities can reach multiple clouds and SaaS services, the organisation needs one policy model and one review cadence before the access graph becomes too fragmented to govern.

For practitioners

• Map every pipeline credential to an owning workflow List each service account, API token, and deployment role used by CI/CD jobs, then tie it to a specific repository, branch, and environment. Eliminate shared credentials that are not bound to a clear operational owner.
• Replace stored secrets with OIDC-based federation Use short-lived token exchange for cloud and SaaS access wherever the target platform supports it, and remove static keys from workflow files, runner images, and environment variables. Validate that token lifetime matches the job duration.
• Harden trust policies before broad rollout Restrict federation by branch, repository, environment, and runner posture so that a successful workflow does not imply universal access. Review trust policy changes through the same approval path used for production IAM changes.
• Centralise audit trails across pipeline destinations Correlate access decisions from cloud providers, SaaS integrations, and internal services so investigators can trace which workload identity accessed which resource and when. Fragmented logs make runtime abuse harder to detect and slower to contain.
• Test blast-radius assumptions with red-team scenarios Simulate a compromised runner, leaked workflow token, and poisoned pull request to see which downstream systems become reachable. Use the results to narrow permissions and remove unnecessary federation paths.

Key takeaways

• CI/CD pipelines are now high-value NHI environments, because the credentials they hold often unlock production systems.
• Workload identity federation is a better authentication model than static secrets, but fragmented trust policies can still leave major governance gaps.
• Teams should focus on reducing persistent access, narrowing scope, and centralising audit before pipeline identity sprawl becomes unmanageable.

Key terms

• Workload Identity Federation: A method for proving a machine or pipeline identity at runtime without storing a reusable secret. The workload presents a signed identity token, and the target system exchanges it for short-lived access scoped to a specific action or time window.
• Credential Debt: The accumulation of persistent, over-scoped, or duplicated credentials across systems that are hard to inventory and revoke. In CI/CD environments, credential debt increases blast radius because old secrets remain usable long after the original job or workflow should have ended.
• Trust Policy: The rules that decide which workload may receive access under federation. In practice, trust policy binds claims such as repository, branch, environment, or runner posture to specific permissions, making it the control point that replaces the old stored secret.
• Blast Radius: The amount of damage an attacker can cause after compromising one identity or token. For pipelines, blast radius depends on how broadly the credential is scoped, how long it lasts, and how many downstream systems trust it.

Deepen your knowledge

Workload identity federation and CI/CD secret removal are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are replacing static pipeline credentials with short-lived access, it is a practical place to build the governance model behind that change.

This post draws on content published by Aembit: Securing CI/CD Pipelines with Workload Identity Federation. Read the original.