Topic starter
25/06/2026 1:30 am
TL;DR: Akeyless says CI/CD pipelines are often the most privileged systems in the estate, yet nearly 29 million new secrets were exposed on public GitHub in 2025, with hardcoded tokens, verbose logs, and over-broad runner permissions keeping production access exposed. Static credentials break the build-run-deploy trust model because pipeline authority outlives the task.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “The Hidden Risks of Secrets Mismanagement in CI/CD Pipelines”.
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.
Key questions
Q: What breaks when secrets are hardcoded into DevOps pipelines?
A: Hardcoded secrets break rotation, ownership, and offboarding at the same time.
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.
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.
Practitioner guidance
- 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.
Bottom line: CI/CD secrets become a governance failure when pipeline authority outlives the job that needed it.
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
👉 Read Akeyless's guide to CI/CD secrets management gaps and production exposure →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 hours ago by NHI Mgmt Group
25/06/2026 10:58 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: CI/CD secrets management gaps keep production access exposed
This post was modified 4 hours ago by NHI Mgmt Group