More than 28.6 million secrets were detected in public GitHub repositories in 2025 alone, according to GitGuardian’s State of Secrets Sprawl Report. Even more alarming, the company found that internal repositories were significantly more likely to contain exposed credentials than public ones.
Ask ten DevOps engineers what keeps them awake during a production deployment, and most won’t mention a failed build. They’ll talk about credentials.
I once joined a post-incident review where the root cause wasn’t sophisticated malware or a zero-day exploit. A developer had enabled verbose logging to troubleshoot a deployment issue late on a Friday evening. The build completed successfully, but the logs had captured a production database password.
Nobody noticed until weeks later when an internal audit flagged it. The password had never been pushed to GitHub, yet dozens of engineers had access to the CI logs.
The CI/CD Pipeline Has Become Your Most Privileged System
Modern software delivery pipelines don’t simply compile code.
They authenticate with cloud providers, publish Docker images, access package registries, provision infrastructure through Terraform, deploy Kubernetes workloads, connect to production databases, sign release artifacts, and notify monitoring platforms.
Every one of those actions depends on secrets.
The OWASP Secrets Management Cheat Sheet describes secrets as any sensitive authentication material used by applications or automation, including passwords, API keys, certificates, encryption keys, OAuth tokens, and SSH credentials. The challenge isn’t simply storing these secrets securely. It’s ensuring they appear only when genuinely needed and disappear immediately afterward.
According to the architecture diagram above, centralized secrets management fundamentally changes how credentials move through a deployment pipeline. Instead of embedding passwords inside YAML files or repository variables, the pipeline authenticates itself using workload identity, retrieves temporary credentials from a secrets manager, performs the deployment, and discards those credentials immediately afterward. The visual also highlights an important security principle: attackers cannot steal credentials that never permanently exist inside the pipeline.
Hardcoded Credentials Create Long-Term Problems
Every experienced developer has probably written something similar at least once:
DATABASE_PASSWORD=SuperSecret123It might live inside a configuration file for only a few hours before being removed.
The problem is Git never truly forgets.
Removing the line from the latest commit doesn’t erase it from repository history. Unless history is rewritten and the credential is revoked, the secret remains recoverable. This is precisely why GitGuardian recommends treating every committed secret as compromised, regardless of how quickly it is deleted.
Research published by North Carolina State University reached a similar conclusion after reviewing hundreds of industry sources on secret management. Their findings consistently recommended moving secrets outside source code, automating credential rotation, and continuously scanning repositories before deployments reach production.
Secrets Management Is About Identity, Not Storage
A common misconception is that deploying a vault automatically solves the problem.
It doesn’t.
A vault without identity-aware access control simply becomes another secure storage location.
Modern secrets management combines several security practices:
- Identity-based authentication instead of shared credentials
- Short-lived tokens instead of permanent access keys
- Automatic credential rotation
- Granular access policies
- Comprehensive audit logging
- Continuous secret detection across repositories and pipelines
This layered approach aligns with guidance from both HashiCorp’s Well-Architected Framework and NIST’s recommendations for securing CI/CD pipelines.
Looking at the infographic above, you could see that one pattern stands out. Traditional credential management assumes that secrets remain trustworthy until someone changes them manually.
Identity-based systems make a different assumption, that credentials should expire automatically before they can become liabilities. This seemingly small design choice dramatically reduces an attacker’s window of opportunity if credentials are exposed.
A Practical Example: Deploying to AWS Without Long-Term Keys
One of the simplest improvements a team can make is replacing stored AWS access keys with OpenID Connect (OIDC).
The implementation is surprisingly straightforward:
- Create an IAM role that trusts your GitHub Actions workload.
- Assign only the permissions required for deployment.
- Configure GitHub Actions to authenticate through OIDC instead of stored access keys.
- Allow AWS Security Token Service (STS) to issue temporary credentials during each workflow execution.
- Automatically invalidate those credentials when the workflow finishes.
No permanent AWS keys.
No manual rotation schedule.
No forgotten credentials buried inside repository settings.
This approach also provides detailed audit logs showing exactly which workflow assumed which role and when, making investigations considerably easier if suspicious activity occurs.
Secret Scanning Should Be Treated Like Automated Testing
Developers don’t intentionally introduce bugs.
That’s why automated tests exist.
The same reasoning applies to credential exposure.
Tools such as GitHub Secret Scanning, Gitleaks, TruffleHog, and GitGuardian automatically inspect commits, pull requests, and CI workflows for accidentally committed credentials before they spread across repositories and build artifacts.
Rather than depending entirely on code reviews, these tools provide another layer of automated verification where humans are most likely to overlook small but dangerous mistakes.
The chart above illustrates more than increasing numbers. It reflects the rapid growth of automation across software development. Every SaaS integration, AI service, package registry, infrastructure platform, and deployment target introduces another machine identity requiring authentication. As software ecosystems become increasingly interconnected, organizations inevitably manage hundreds—or even thousands—of credentials that developers rarely see directly.
The Strongest Security Control Is Reducing Exposure Time
Many security discussions focus on preventing breaches altogether.
Reality is rarely that accommodating.
A better objective is limiting the damage when mistakes occur.
Short-lived credentials, centralized secrets management, automatic rotation, and continuous monitoring all contribute to one outcome: reducing the amount of time attackers can exploit exposed secrets.
That philosophy has quietly become one of the defining characteristics of mature DevSecOps programs.
Final Thoughts
CI/CD pipelines now sit at the center of software delivery. They build applications, provision infrastructure, deploy production workloads, publish packages, and connect nearly every service modern organizations depend upon.
Protecting those pipelines means protecting the credentials they rely on.
Secrets management is no longer just a compliance exercise or an operational convenience. It is a security discipline built around identity, automation, observability, and least privilege. Organizations that embrace those principles don’t simply reduce credential leaks—they build delivery pipelines that remain resilient even when human error inevitably finds its way into the workflow.
Further reading: Review the OWASP Secrets Management Cheat Sheet, NIST’s guidance on securing software supply chains, HashiCorp’s CI/CD security recommendations, and GitGuardian’s annual State of Secrets Sprawl Report for implementation guidance and current industry data.
