CI/CD secrets management gaps keep production access exposed

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Akeyless's blog post: CI/CD secrets management fails when pipeline credentials are hardcoded, over-scoped, or left exposed in logs and history.

Why it matters: It matters because CI/CD systems often hold production-deploying access, so identity teams must govern pipeline secrets with the same rigor as privileged human or machine access.

By the numbers:

• Nearly 29 million new secrets were exposed on public GitHub in 2025, a 34% year-over-year increase.
• 70% of secrets leaked in 2022 were still active in 2025.

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

Context

CI/CD secrets management is the discipline of controlling credentials that pipelines use to build, test, deploy, and configure systems. In practice, the problem is that those pipelines are usually the most privileged systems in the environment, but they are also among the least hardened.

The article argues that the failure is structural: static credentials, broad runner permissions, and weak rotation practices let pipeline authority persist beyond the build window. Once secrets are present in logs, git history, or shared stage variables, the exposure problem becomes an identity governance problem as much as a tooling problem.

For IAM and NHI teams, this is a reminder that pipeline identities are not just implementation details. They are production-capable actors whose lifecycle, scope, and revocation need explicit governance.

Key questions

Q: What breaks when secrets are hardcoded into DevOps pipelines?

A: Hardcoded secrets break rotation, ownership, and offboarding at the same time. They become embedded in repositories, build systems, and configuration files, which means the credential can survive long after the workflow changes. That creates hidden persistence and makes remediation dependent on finding every copy first.

Q: Why do CI/CD secrets create more risk than many teams expect?

A: CI/CD secrets often have broad blast radius because they can authenticate to source control, cloud platforms, package registries, and deployment systems. If those secrets are long-lived or reused across repositories, one exposure can open several downstream paths. The risk is highest when secrets are stored in workflow contexts where third-party code can read them.

Q: What are the signs that pipeline secrets are not under control?

A: Common warning signs include credentials in source code, config files, or CI/CD variables, broad permissions that exceed the job's needs, and tokens that remain valid after a pipeline has been retired or replaced. Those patterns show that access is being managed as a secret stash rather than as a governed identity lifecycle.

Q: Should teams use OIDC federation or stored cloud keys for CI/CD access?

A: Use OIDC federation when the pipeline only needs cloud access for a specific run, because it removes the long-lived key problem entirely. Stored keys should be reserved for edge cases that cannot support federated issuance, and even then they need strict scoping and aggressive rotation.

Technical breakdown

Why CI/CD runners become high-value identity targets

CI/CD runners are ephemeral compute identities that are created to execute jobs, then discarded. That lifecycle makes them convenient for automation, but it also means the trust boundary is runtime, not machine ownership. When a runner receives secrets as environment variables, those credentials exist in memory, logs, child processes, or copied files for the duration of the job. The real risk is not the runner itself but the production authority attached to it. If the job can deploy code, push images, or query cloud APIs, the credential set is already privileged enough to matter as an access path.

Practical implication: Treat every CI/CD runner as a privileged non-human identity and scope its permissions to one job, one environment, and one purpose.

How static secrets turn pipeline access into durable exposure

A hardcoded secret in workflow YAML, source code, or a Dockerfile is not just a configuration mistake. It creates durable exposure because git history, build logs, forks, and replicated artifacts preserve the credential long after the current branch is cleaned up. The article’s key point is that deletion from HEAD does not revoke what already escaped into the repository lifecycle. That is why static secrets are such a bad fit for pipelines: the secret’s lifetime is far longer than the task that needed it, and the attack surface includes every system that stores or renders the artifact.

Practical implication: Use short-lived runtime secrets and immediate revocation workflows instead of treating repository cleanup as remediation.

Why shift-left scanning is necessary but not sufficient

Pre-commit hooks, CI-step scanners, and continuous artifact scanning each catch secrets at different points in the pipeline lifecycle. Pre-commit scanning stops many leaks before they leave a developer workstation. CI scanners catch what slips through or predates enforcement. Continuous scanning adds coverage for old commits, job logs, collaboration tools, and packaged artifacts. None of those controls eliminate risk by themselves because they detect exposure after a credential has already been created or propagated. The architecture therefore has to combine prevention, detection, and replacement with dynamic credentials and tight scope.

Practical implication: Layer detection across commit, pipeline, and artifact stages, then replace static credentials so the same secret cannot reappear downstream.

Threat narrative

Attacker objective: The attacker wants to turn a single exposed pipeline credential into production access and broader infrastructure control.

1. Entry begins when a hardcoded token, leaked environment variable, or verbose job log exposes a credential in a CI/CD workflow or related artifact.
2. Credential access follows when an attacker harvests the secret from repository history, build output, or third-party pipeline tooling.
3. Escalation occurs when the stolen credential is reused to gain production deployment access, cloud API permissions, or database control beyond the original job.
4. Impact is achieved when the attacker can push code, modify services, or exfiltrate additional secrets from the pipeline’s privileged execution context.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD secrets exposure is a privileged identity problem, not just a scanning problem: Pipeline credentials often have the authority to deploy, configure, and query production systems. That makes them non-human identities with unusually high blast radius when leaked. The governance mistake is assuming that build infrastructure is temporary enough to be low-risk. In reality, the access it carries is durable and consequential, so practitioners should govern pipeline identities as production actors.

Static credentials create identity lifecycle debt inside delivery systems: A secret that lives in workflow YAML, git history, or shared job variables outlives the change that introduced it. That means revocation, offboarding, and rotation are no longer optional hygiene tasks but core lifecycle controls. The named concept here is pipeline credential persistence: the credential remains exploitable long after its intended use window has ended. Practitioners should treat lifecycle mismatch as the defect, not just the leak.

Shift-left detection only works when it is paired with runtime replacement: Secret scanners reduce exposure, but they do not change the fact that the pipeline was built around a reusable credential. This is where OIDC federation and dynamic secrets matter: they change the identity model from stored credentials to ephemeral issuance. The implication for IAM and PAM teams is that prevention has to move from review-after-commit to issuance-time control.

CI/CD governance should be measured by credential scope, not by tool count: A stack of scanners, vaults, and logs is not evidence of control if runner permissions remain broad and secrets remain shared across stages. The better question is whether a pipeline credential can do anything beyond its exact job, environment, and promotion step. That is the control boundary practitioners should be using when they assess delivery security maturity.

Compliance pressure is converging on pipeline identity governance: The article’s references to SOC 2, NIST SP 800-53, and PCI DSS reflect a broader market shift. Auditors increasingly expect documented access control, authenticator management, and evidence of review for build and deployment systems. The practical conclusion is that CI/CD secrets management has moved from engineering preference to governance obligation.

From our research library:

• 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, according to the State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Pipeline credential persistence: The central governance issue is not whether a secret can be found, but whether it can still be used after the job that created it has ended. Static secrets, shared stage variables, and log exposure all extend the useful life of a credential beyond the delivery window, so control has to move to issuance time and scope restriction.

CI/CD pipelines sit at the intersection of NHI governance and privileged automation. If an organisation still manages them as a convenience layer instead of as production identities, it is leaving the highest-value access path in the estate outside normal lifecycle discipline.

For practitioners

• Implement runtime-only credential delivery Replace stored pipeline secrets with short-lived values issued at job execution time and scoped to the specific step that needs them.
• Separate build and production identities Use distinct service accounts and permissions for build, test, staging, and production promotion so one compromised runner cannot inherit the full deployment path.
• Scan the commit and artifact chain Run pre-commit hooks, CI scanners, and scheduled history scans across source, logs, and container layers so exposed secrets are caught before they spread.
• Replace static cloud keys with federation Use OIDC federation for GitHub Actions or similar pipelines so cloud access is issued per run instead of stored as long-lived keys.
• Rotate every credential that has already leaked Treat removal from the current branch as insufficient and revoke any secret that may have reached history, logs, or shared artifacts.

Key takeaways

• CI/CD secrets become a governance failure when pipeline authority outlives the job that needed it.
• The exposure problem is material, with public GitHub and CI/CD runner data showing large-scale secret leakage and reuse.
• Runtime issuance, scope-limited permissions, and fast revocation are the controls that shrink the blast radius.

Key terms

• CI/CD secret: A CI/CD secret is a credential used by build or deployment automation to reach source control, cloud services, registries, or internal systems. In practice it is a non-human identity artifact, so its scope, lifetime, storage location, and revocation path must be governed like any other privileged access token.
• Ephemeral Runner: A disposable build executor that exists only for a single job or short-lived task. Ephemeral runners reduce the chance that credentials, state, or malicious changes persist across builds, which makes them a key control for pipeline isolation and supply chain resilience.
• Dynamic Secret: A secret generated on-demand for a specific task and automatically revoked after use or expiry. Dynamic secrets dramatically reduce the risk of credential exposure compared to static, long-lived secrets and are considered best practice.
• Pipeline Credential: A pipeline credential is a secret, token, key, or service account used by automation to authenticate and move code through delivery stages. These credentials function like non-human identities and should be governed with the same expectations for ownership, scope, rotation, and revocation.

What's in the full article

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

• Workflow examples for injecting secrets at runtime without storing them in YAML or source code
• Step-by-step detection patterns using pre-commit hooks, CI scanners, and repository history scans
• Operational guidance for OIDC federation in GitHub Actions and other cloud-integrated pipelines
• Rotation and revocation patterns for credentials that may already exist in logs, history, or artifacts

👉 The full Akeyless guide covers detection layers, OIDC federation, and dynamic secrets in pipeline environments.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.