TL;DR: CI/CD pipelines are often the most privileged systems in the estate, yet GitGuardian’s 2026 State of Secrets Sprawl report found nearly 29 million new secrets exposed on public GitHub in 2025, with CI/CD files among the main exposure paths. Static credentials, over-broad runner permissions, and weak rotation practices leave production access exposed far beyond the intended build window.
NHIMG editorial — based on content published by Akeyless: CI/CD secrets management and pipeline exposure
By the numbers:
- 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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Akeyless's guide to CI/CD secrets management and pipeline exposure →
CI/CD secrets management gaps: are your controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: CI/CD secrets management gaps keep production access exposed