September 8, 2026
Posted by Akeyless
- Secret leakage is effectively unavoidable at some rate; GitGuardian recorded 28.65 million new secrets leaked to public GitHub in 2025 alone, a 34% year-over-year jump.
- Scanning tools catch leaks after they happen; Wiz found 65% of Forbes AI 50 companies leaking verified secrets in places most scanners don’t check: notebooks, logs, VS Code extensions, and support portals.
- Preventing secret leakage is two separate jobs: stopping leaks before they happen (pre-commit hooks, push protection, moving off static secrets) and containing the ones that get through (rotation, audit review, notification).
- CISA’s own May 2026 GitHub leak stayed exposed for roughly six months; Akeyless’s own analysis found a 15-minute dynamic-secret TTL would have expired the credential before it was ever discovered.
- Akeyless removes static, long-lived secrets through dynamic secrets with configurable TTLs and Distributed Fragments Cryptography, so a leaked credential is worth far less by the time anyone finds it.
Quick Answer: How Do You Prevent Secret Leakage?
Secret leakage happens at some rate no matter how careful a team is: hardcoded credentials, plaintext config, and CI/CD logs all create exposure. Scanning catches leaks after the fact and misses places most tools don’t check. Prevention means closing the obvious entry points, moving off long-lived static secrets, and having a rotation plan ready before a leak happens, not after.
- Add pre-commit hooks and push protection to stop secrets from reaching a public repo in the first place.
- Replace static, long-lived credentials with dynamic secrets that expire automatically.
- Have an incident-response playbook ready so a confirmed leak gets rotated and contained in minutes, not months.
Quick Facts
| Category | Data Point |
| Scale | 28.65 million new hardcoded secrets were added to public GitHub commits in 2025, a 34% year-over-year increase and the largest single-year jump on record (GitGuardian State of Secrets Sprawl 2026) |
| Remediation lag | 64% of secrets confirmed valid in 2022 were still active and exploitable when GitGuardian retested them in January 2026 (GitGuardian State of Secrets Sprawl 2026) |
| Blind spots | 65% of Forbes AI 50 companies leaked verified secrets in places most scanners never check: notebooks, logs, VS Code extensions, and support portals (Wiz research) |
| Beyond code | Roughly 28% of leak incidents originate in collaboration and productivity tools rather than source repositories (GitGuardian State of Secrets Sprawl 2026) |
| In practice | A CISA contractor’s public GitHub repository exposed AWS GovCloud credentials for roughly six months before discovery in May 2026 (Krebs on Security) |
Secret leakage happens to almost every team eventually, no matter how careful engineers try to be. An API key gets hardcoded during a late-night fix. A database password lands in a config file that gets committed by mistake. A token shows up in a CI/CD log nobody thought to scrub. GitGuardian’s newest research puts a number on just how often: 28.65 million new secrets leaked to public GitHub in 2025 alone.
What matters isn’t whether a leak will happen. It’s whether the credential is still worth anything by the time anyone notices. A static AWS key valid for years turns a single mistake into an open door. A credential that expires in fifteen minutes turns the same mistake into a footnote.
The rest of this guide covers why secret leakage keeps happening, what scanning can and can’t catch, and a practical checklist for closing what scanning misses. It also covers what changes once the leaked secret itself has nothing left to give an attacker.
What Is Secret Leakage, and Why Does It Keep Happening?
Secret leakage is any credential, API key, token, certificate, or password landing somewhere it shouldn’t. Common examples include credentials hardcoded in source code, pasted into a chat message, sitting in a spreadsheet, or exposed in a CI/CD log. OWASP’s Non-Human Identities Top 10 lists secret leakage as NHI2:2025, one of its highest-severity risk categories. Easy exploitability and hard detectability are the reasons it ranks so high. It happens because teams create secrets faster than any manual process can track them.
Hardcoded credentials are the most common starting point. A developer drops an API key directly into code to get something working and means to move it to an environment variable later. The commit ships before that happens.
Plaintext configuration files carry the same risk. A .env file or a config.yaml with live credentials gets committed because .gitignore wasn’t updated. Sometimes it happens because a teammate copies a working config into a new project without checking what’s inside it.
Git history makes the problem durable. Deleting a secret from the current version of a file doesn’t remove it from history. Anyone who clones the repository, or finds a public fork, can still recover it with a simple search.
CI/CD pipelines add their own exposure. Build logs routinely print environment variables for debugging, and a token meant to stay internal ends up in a log a wider group can read.
Collaboration tools create the same risk outside of code entirely. A credential pasted into Slack to unblock a teammate, dropped into a spreadsheet, or attached to a support ticket lives on in a system. Nobody thinks to audit that system for secrets.
How Much Does Secret Leakage Cost Organizations?
GitGuardian’s newest State of Secrets Sprawl report puts a hard number on the scale of the problem: 28.65 million secrets leaked to public GitHub in 2025. It’s a 34% jump from 2024, the largest single-year increase the company has recorded.
The bigger cost sits in what happens after a leak, not the leak itself. GitGuardian found 64% of secrets confirmed valid in 2022 were still active and exploitable when the company retested them in January 2026. A leaked credential that never gets rotated stays a live risk for years, not days.
Leaks also aren’t confined to code the way most teams assume. Roughly 28% of incidents GitGuardian tracked originated in collaboration and productivity tools rather than source repositories. Another 59% of the compromised machines it identified were CI/CD runners rather than personal laptops. Secret leakage spans far more of an organization’s surface area than a code scanner alone can cover.
Why Scanning Alone Can’t Prevent Secret Leakage
Scanning tools are built to catch a leak after it’s already happened, not before. A commit lands in a public repository, a scanner flags the exposed credential, and a team gets an alert. But the secret was already visible to anyone else scanning the same repository in that window.
Scanners also have blind spots. Wiz’s research into the Forbes AI 50 found 65% of those companies leaked verified secrets in places most scanning tools don’t typically check. The list includes notebooks, logs, VS Code extensions, and support portals. A tool built to scan an organization’s main repositories has nothing to say about a credential sitting in a notebook. The same is true for a support ticket nobody thought to check.
These limits don’t make scanning useless. It’s a necessary safety net, catching a meaningful share of leaks and shortening how long they stay exposed. It just isn’t a complete answer on its own, because a scanner can only flag a secret that already exists somewhere it shouldn’t. The more durable fix removes that exposure window entirely, by making the secret itself expire before a scanner or an attacker gets the chance to use it.
A Practical Checklist for Preventing Secret Leakage
Preventing secret leakage means closing the obvious entry points now and removing static, long-lived secrets from the picture for good. The two don’t happen on the same timeline, so it helps to separate them.
The fixes worth doing immediately are mostly configuration, not architecture:
- Add pre-commit hooks that scan for credential patterns before a commit ever reaches a shared branch.
- Turn on push protection at the repository or organization level so a commit containing a recognizable secret pattern gets blocked outright.
- Audit .gitignore files across active repositories to confirm config files, .env files, and credential directories are actually excluded, not just assumed to be.
- Extend scanning past source code to build artifacts and container images. Secrets baked into a compiled binary or a Docker layer survive long after the source has been cleaned up.
The fixes worth planning for the long term change what’s actually at risk:
- Replace hardcoded, long-lived credentials with dynamic secrets that get issued on demand and expire automatically.
- Centralize secrets in a dedicated secrets manager rather than scattering them across config files, environment variables, and individual developer machines.
- Scope every credential to the minimum access it actually needs, so a leaked secret can’t reach further than the one system it was issued for.
What Should You Do When Secret Leakage Occurs?
The moment a leaked secret is confirmed, the priority shifts from prevention to containment, and the clock is already running.
Rotate the exposed credential first, before anything else. A leaked secret that’s still valid is an open door regardless of how it was found; revoking and reissuing it closes that door immediately.
Check access and audit logs next, for the exposed credential specifically. Whether it was actually used while live determines whether the incident is a close call or an active compromise that needs a broader response.
Notify anyone downstream who depends on the exposed credential (an integration partner, a customer, a vendor) so they can rotate their side of the connection too. A leaked secret rarely affects only the team that leaked it.
CISA’s own May 2026 GitHub leak shows what happens when this playbook runs too slowly. The exposed credentials sat in a public repository for roughly six months before anyone caught them. Speed, not just process, determines whether an incident stays contained.
Comparing Approaches to Preventing Secret Leakage
The three approaches to preventing secret leakage remove different things, and confusing one for another leaves risk uncovered.
| Approach | What It Actually Does | What’s Left Exposed |
| Secret scanning | Detects a secret after it’s already been committed or shared, shortening how long it stays exposed | The window between exposure and detection, and anything a scanner isn’t configured to check |
| Traditional secrets manager | Centralizes static secrets in one vaulted location instead of scattering them across code and config | The secret itself is still long-lived; a copy pulled from the vault can still leak downstream |
| Dynamic and ephemeral secrets | Issues short-lived credentials on demand and lets them expire automatically | Only the narrow window the credential was valid for, regardless of where a copy ends up |
None of these approaches replaces the others outright. Scanning still catches what slips through, and a secrets manager is still where dynamic secrets get issued from. The difference is what’s left over after a leak actually happens, and that’s exactly what dynamic secrets are built to close.
How Akeyless Prevents Secret Leakage from Becoming a Breach
Akeyless’s answer to secret leakage isn’t a better scanner. It’s removing the static secret a scanner would otherwise need to find.
The Challenge
CISA’s own contractor-maintained GitHub repository exposed AWS GovCloud credentials and internal system access for roughly six months before discovery. It’s the kind of static, long-lived credential exposure that no scanning cadence would have caught in time.
The Approach
Akeyless’s own analysis of the incident walked through what a 15-minute dynamic secret would have changed:
| akeyless dynamic-secret create aws \ –name /gov/cisa/aws-govcloud-admin \ –target-name govcloud-target \ –aws-access-mode iam_user \ –aws-role-arns arn:aws-us-gov:iam::123456789012:role/PrivilegedOps \ –user-ttl 15m |
That 15-minute expiration meant a copy-pasted credential would have gone dead long before it could do any damage, whether the discovery came from GitHub’s indexer or anyone else. The real incident had no such expiration in place, which is the entire reason it stretched to six months instead of minutes.
Akeyless protects what it stores using Distributed Fragments Cryptography, a patented zero-knowledge architecture. Key fragments are generated independently across regions, and the complete key never exists in one place, including on Akeyless’s own infrastructure. It’s FIPS 140-3 Level 1 validated under NIST CMVP #5227.
For privileged human access specifically, Secure Remote Access brokers the session so the underlying credential is never exposed to the user at all. The session itself is recorded to the organization’s SIEM.
The Outcome
Dynamic secrets don’t make secret leakage impossible. A credential copied and used during its own live window is still technically usable, the same way any short-lived access is. What they remove is the category of risk that made CISA’s incident last six months: a static credential with no expiration, sitting in a public repository. That credential is worth exactly as much to an attacker the day it’s found as the day it leaked.
How Akeyless Earns Enterprise Trust on Credential Security
Cimpress’s own account of eliminating credential leakage is direct proof Akeyless’s approach holds up in production, not just in company messaging.
Cimpress’s experience speaks to secret leakage directly. Conor Mancone, Principal Application Security Engineer at Cimpress, described the shift: “We set Akeyless up 9 months ago, and we haven’t had to worry about credential rotation. We haven’t had to worry about credential leakage. All of our software that’s running, it just works, we haven’t really had to think about it since then. It’s been a really smooth, really easy process.”
Progress Software runs in 16 countries and adopted Akeyless to get ahead of secrets sprawl in a multi-cloud environment it inherited through acquisitions. Richard Barretto, Chief Information Security Officer and VP at Progress, credited fast adoption with no code changes and pipelines connecting instantly: “Akeyless is true SaaS that allows you to scale. It’s purpose-built to live in the cloud. We saved 70% of our maintenance and provisioning time with Akeyless.”
Progress’s case study centers on sprawl, and Cimpress’s centers on rotation. Both describe the same underlying shift this guide recommends: moving off static, manually managed credentials and onto a system that issues, tracks, and expires them automatically.
How Do You Choose the Right Approach for Preventing Secret Leakage?
The right approach depends on what a single exposed credential could actually cost, not a fixed checklist.
A small team with limited infrastructure and low-sensitivity data might reasonably start with scanning and push protection alone. Both fixes take an afternoon to set up and immediately shrink the most common failure mode.
A team handling production infrastructure, customer data, or regulated systems needs more than detection. The cost of a single leaked credential (a database of customer records, a cloud account with broad permissions) is high enough to justify the investment. Dynamic secrets and centralized management are worth setting up before a leak happens, not after.
Most organizations land somewhere in between, and the practical path is usually sequential. Close what’s immediately exploitable first, then work toward removing static secrets from the systems that would do the most damage if they leaked. Secret leakage doesn’t need to be solved everywhere at once to meaningfully lower the risk.
FAQs About Preventing Secret Leakage
Is Secret Leakage a Recognized Security Risk Category, or Just a General Term?
It’s recognized formally. OWASP’s Non-Human Identities Top 10 lists it as NHI2:2025, one of the highest-severity risks in the framework. The ranking reflects how easy leaked secrets are to exploit and how hard they are to detect before someone else finds them. The designation comes from an independent, community-run standards body, not a vendor.
What’s the Difference Between Secret Leakage and Secrets Sprawl?
Secrets sprawl describes secrets scattered across too many locations, config files, chat tools, individual developer machines, with no central visibility. Secret leakage describes the outcome: a secret ending up somewhere unauthorized. Sprawl makes leakage more likely, but a tightly controlled environment can still leak a single secret, and a sprawling one doesn’t guarantee anything has actually leaked yet.
Does Secret Leakage Always Turn into a Breach?
No. A leaked secret is an opportunity, not a guaranteed outcome. Whether it becomes a breach depends on how long it stays valid, how much access it grants, and how quickly it gets discovered and rotated. Shrinking the exposure window is the entire argument. The same mistake that stays open for six months and the one that expires in fifteen minutes carry very different consequences.
Is Secret Scanning Still Worth It if It Can’t Fully Prevent Leaks?
Yes. Scanning shortens how long a leak stays exposed and catches a meaningful share of mistakes before anyone finds them. It’s necessary, just not sufficient on its own, which is why it works best paired with removing static secrets rather than as a replacement for that step.
Does Deleting a Secret from Git History Actually Remove the Exposure?
No, not on its own. Removing a secret from the current version of a file leaves it recoverable in prior commits. Anyone who already cloned the repository or found a public fork keeps their own copy regardless of what happens to the original afterward. Rotating the credential, not editing history, is what actually closes the exposure.
How Long Should a Dynamic Secret’s TTL Be?
It depends on how the credential gets used. A CI/CD pipeline that finishes in minutes can use a TTL that short, the way Akeyless’s own analysis of the CISA leak used a 15-minute example. Interactive human access typically runs longer, tied to the length of a working session rather than a fixed number. The guiding question is how long the credential actually needs to be valid to do its job, not a default number applied everywhere.
Can Secret Leakage Still Happen with a Secrets Manager Already in Place?
Yes. A secrets manager centralizes where static secrets live. But a copy pulled from it, hardcoded elsewhere, cached locally, pasted into a script, can still leak the same way any other credential can. Centralizing secrets reduces sprawl; it doesn’t automatically make each individual secret short-lived.
