CI/CD secrets management gaps keep production access exposed

At a glance

What this is: This is an analysis of CI/CD secrets management and the finding that pipelines remain one of the most credential-dense, least hardened parts of the infrastructure estate.

Why it matters: It matters because CI/CD secrets directly affect NHI governance, workload identity, and privileged access controls across the software delivery chain.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Akeyless's guide to CI/CD secrets management and pipeline exposure

Context

CI/CD secrets management is the discipline of controlling the credentials that pipelines use to build, test, and deploy software. The problem is not simply that secrets exist, but that pipeline environments tend to be highly privileged, highly distributed, and poorly bounded, which makes a single leaked token disproportionately dangerous.

In practice, the same secret often moves across multiple stages, tools, and identities, from source control to build to deployment. That creates a governance problem for NHI programmes, because the credential lifecycle is longer and more exposed than the actual job that needs the access, and the control model often lags behind the delivery model.

Key questions

Q: How should security teams eliminate static secrets from CI/CD pipelines?

A: Security teams should move from stored credentials to runtime-issued access wherever possible. Use federation for cloud auth, inject short-lived secrets only into the job step that needs them, and keep the secret out of source control, logs, and artifacts. The aim is to remove standing exposure, not just hide it better.

Q: Why do CI/CD secrets create such a large blast radius?

A: CI/CD secrets often inherit permissions broad enough to deploy code, query cloud APIs, and modify infrastructure. If one runner credential is stolen, the attacker may gain the same reach as the pipeline itself. The blast radius is large because the pipeline is trusted to do privileged work by design.

Q: What do teams get wrong about secret rotation in pipelines?

A: Teams often assume deleting a secret from the latest configuration removes the risk. In reality, the credential may still exist in git history, build logs, caches, or container layers. Rotation only works when the exposed secret is revoked everywhere it could still be used.

Q: Which controls matter most when protecting CI/CD credentials?

A: The most effective controls are least privilege by pipeline stage, pre-commit and CI scanning, immutable pinning of third-party actions, and short-lived credentials issued at runtime. Together they reduce exposure, limit lateral use, and make stolen pipeline secrets far less useful.

Technical breakdown

Why pipeline secrets become a production access problem

CI/CD systems usually carry the permissions needed to push code, publish images, query cloud APIs, and modify infrastructure. That makes pipeline credentials a higher-value target than many workstation accounts. The technical failure is not only exposure, but scope: once a secret is injected into a runner, it may persist in logs, artifacts, or downstream jobs long after the original step ends. If the secret is static, the attacker does not need to win a race, only to find it before rotation. That is why pipeline hygiene is really identity governance for machine execution paths, not just secure DevOps housekeeping.

Practical implication: map every pipeline credential to its exact downstream privilege and remove any access that is not required for a single job step.

How hardcoded secrets survive in git history and build artifacts

A hardcoded secret removed from the latest branch commit is still present in git history, cloned copies, build caches, and sometimes container layers. That is why detection must happen before the commit is created or immediately after exposure, not after release. Tools such as pre-commit scanners and full-history CI scans are useful because they catch different points in the propagation chain. The core architectural issue is persistence: version control and artifact systems are designed to preserve state, while secrets management requires revocation and expiry. Those goals are in tension unless the pipeline is built to prevent static credentials from entering the system at all.

Practical implication: treat secret discovery as an exposure event and rotate the credential immediately, even if the current branch no longer shows it.

Why OIDC and JIT secrets change the credential model

OIDC federation replaces long-lived cloud keys with short-lived tokens issued for a specific workflow run, while JIT secrets replace stored credentials with values generated only when a job needs them. Both patterns reduce standing exposure, but they solve different problems. OIDC is strongest for cloud-provider auth from GitHub Actions or similar systems. JIT secrets are better for application and database access where the pipeline still needs a secret, but only for a narrowly scoped task. The important technical shift is from credential possession to credential issuance on demand, which narrows blast radius and simplifies revocation logic.

Practical implication: prefer federated identity for cloud access and JIT secrets for everything else that still requires a credential.

Threat narrative

Attacker objective: The attacker wants production-level control through the pipeline’s trusted automation path.

1. Entry occurs when a hardcoded token, leaked environment variable, or exposed build artifact gives the attacker a usable pipeline credential.
2. Escalation follows when the credential grants access to deployment jobs, cloud APIs, or image publishing paths that were broader than the task required.
3. Impact occurs when the attacker uses pipeline privilege to push malicious code, modify infrastructure, or reach production 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 secrets sprawl is really a machine identity governance failure. The article shows that pipeline credentials are not isolated implementation details, they are production-grade identities with broad operational reach. When those identities are static, shared, or over-scoped, the pipeline becomes a privileged access channel rather than a controlled delivery mechanism. Practitioners should treat every pipeline credential as an NHI subject to lifecycle control, not as a convenience variable.

Static pipeline secrets create identity blast radius that far exceeds the job that requested them. A build runner often inherits access to deploy, query, and configure systems it never truly needs. That violates least privilege in a way that conventional access review processes struggle to see because the credential is embedded in delivery logic, not in a normal entitlement catalogue. The practical conclusion is that blast radius, not storage location, is the real governance metric.

Hardcoded credential persistence is the named failure mode this topic exposes. A secret committed to source code, logs, or artifacts outlives the moment of legitimate use and remains exploitable in git history and derived objects. That is not just poor hygiene, it is a broken assumption that deletion equals removal. The implication is that governance must account for persistence across version control, build systems, and deployment artifacts.

OIDC federation and JIT secrets show that pipeline access should be issued, not stored. The article points toward a broader identity pattern in which the credential exists only for the duration of the workflow step and then disappears. That aligns with OWASP NHI and zero standing privilege thinking, but only if organisations stop treating platform secret stores as a full secrets strategy. Practitioners should redesign around issuance, expiry, and revocation rather than repository-based storage.

CI/CD risk now sits at the intersection of NHI governance, secrets management, and supply chain control. GitGuardian’s finding that runner compromise dominates supply chain exposure underscores that the attacker does not need a workstation foothold when the pipeline itself is the highest-value identity. That makes CI/CD a board-level identity boundary, not a tooling afterthought. Practitioners should align pipeline controls with privileged access governance, not just developer workflow convenience.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• For a broader baseline on exposed credentials and remediation patterns, see the Guide to the Secret Sprawl Challenge.

What this signals

Pipeline identity is now part of the privileged access perimeter. When delivery systems carry production permissions, the security programme has to manage them like high-risk identities rather than low-friction automation. That means access scoping, credential expiry, and auditability belong in the same conversation as deployment reliability, not in a separate DevOps lane.

Secret persistence is the governance problem that keeps reappearing. The real issue is not whether a credential was once hidden, but whether it can still be reused after propagation through git history, logs, images, and downstream jobs. That persistence problem is why static credential strategy breaks down even when detection is strong.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the pattern is clear: any system that brokers runtime access becomes a credential magnet unless governance is designed in from the start. For pipeline teams, that means every new automation surface should be reviewed as an identity boundary, then linked to audit and revocation controls before it reaches production.

For practitioners

• Eliminate static credentials from pipeline definitions Move cloud, database, and deployment access to runtime-issued credentials so nothing sensitive is stored in workflow YAML, Dockerfiles, or source control. Use short-lived tokens wherever the job can authenticate through federation or a central secrets manager.
• Separate access by pipeline stage Give build, test, and production promotion steps different service accounts and different secret scopes so a compromise in one stage cannot automatically reach the next. Keep environment-level access narrow enough that a test job cannot read production credentials.
• Scan before commit and after merge Use pre-commit hooks, CI-step scanners, and full-history repository scans together so secrets are blocked before they propagate into logs, artifacts, or image layers. If a secret is found, rotate it immediately and do not rely on deleting the current branch copy.
• Replace long-lived cloud keys with OIDC federation For GitHub Actions and similar systems, use OIDC-based federation for cloud authentication so the workflow obtains a short-lived token instead of storing a reusable access key. That removes the most common static secret path from the pipeline.
• Review third-party action trust before every release Pin actions to immutable commit SHAs, not mutable tags, and re-evaluate whether each action really needs the environment variables and secrets it can see. Third-party workflow code should be treated as part of the trust boundary.

Key takeaways

• CI/CD secrets management fails when pipeline credentials are treated as configuration convenience instead of privileged machine identities.
• The scale of exposed secrets and the persistence of leaked credentials show why detection without revocation leaves production access exposed.
• Federated identity, short-lived secrets, and stage-specific access are the controls that shrink pipeline blast radius in practice.

Key terms

• CI/CD Secrets Management: The practice of controlling credentials used by build and deployment pipelines so they are not exposed, reused, or left active beyond their intended job. It covers generation, storage, access, rotation, and revocation across the delivery chain.
• Runtime-issued Credential: A credential created at the moment a workflow needs access and limited to that specific execution context. In pipeline environments, this reduces standing exposure because the token exists only for the job step or workflow run that requested it.
• Identity Blast Radius: The amount of damage that becomes possible when a single identity is compromised. In CI/CD, blast radius is often high because one runner credential may reach production systems, cloud APIs, and deployment tools that the job was trusted to use.
• Federated Workload Identity: A non-human identity pattern where a workload proves who it is through an external identity provider instead of storing a reusable secret. In CI/CD, this is commonly used to replace static cloud keys with short-lived access tokens.

What's in the full article

Akeyless's full guide covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples for scanning secrets in pre-commit hooks, CI jobs, and full git history.
• Concrete configuration patterns for GitHub Actions, GitLab CI, Jenkins, and CircleCI secret handling.
• Implementation detail for OIDC federation, including where static cloud keys can be removed entirely.
• Runbook guidance for rotating exposed credentials after a pipeline leak is confirmed.

👉 The full Akeyless guide covers pipeline leak paths, rotation steps, and runtime secret patterns.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.