TL;DR
- A high-impact leak is an exposed secret: it could do serious damage in the wrong hands because it still works or can't be proven inactive, and it reaches production, source code, sensitive data, or privileged identities.
- Validity isn't enough: Validation-only prioritization misses 46% of critical secrets because they can't be verified automatically.
- The five critical factors: Reach, environment, liveness, location, and time with ownership determine how much a leak can hurt you and how fast you need to contain it.
- What to do first: Contain high-impact leaks the same day, and escalate an untestable secret with admin reach without waiting on a validity check.
Two alerts land in the same queue on the same morning, both marked valid. One is a read-only key for a staging analytics dashboard. The other is a GitHub App private key, a credential type that never expires. A queue sorted by validity puts those two alerts side by side.
Ranking compromised credentials by what they can do takes five questions. They'll settle most alerts, though some will still sit in a grey zone.
What is a high-impact leak?
A high-impact leak is an exposed secret that could do serious damage in the wrong hands. It still works, or no one can prove it doesn't, and it reaches production systems, source code, sensitive data, or privileged identities.
GitGuardian holds public leaks to a stricter bar before warning anyone about them. The secret has to be exposed in public and tied to a specific organization, because a leaked credential only becomes someone's emergency once you know whose it is. In your own incident queue, that question is usually settled already. For a key sitting in a stranger's public repository, it takes real investigation. That investigation is the work behind GitGuardian's Enterprise Good Samaritan program, which warns organizations about leaks they haven't found yet.
Vulnerabilities have a shared severity language in CVSS. Leaked secrets have no widely used equivalent, so each team ends up with its own working definition, written down or not. The five factors below are one version of it, drawn from the questions our researchers ask before escalating a public leak.
Leaked means compromised
We assume breach, so we treat leaked and compromised as the same thing. A credential exposed anywhere outside a vault is one someone else could use. Waiting for proof of misuse before calling it compromised doesn't work for machine credentials, because when proof shows up, it is already too late.
The useful question is how much damage it can do. Impact qualifies the credential and its context, so you can assess it right away. A high-impact leak reaches production, sensitive data, or admin access and needs containing the same day.
Why credential compromise often goes unseen
Misuse of a machine credential rarely trips an alarm. The attacker is authenticated as a legitimate service, with no MFA prompt in the way. The evidence sits in provider audit logs, which often go unread. Exposure windows are long, too. Of the secrets we confirmed valid in 2022, 64% were still valid in January 2026, according to The State of Secrets Sprawl 2026.
Credentials matter well past the first step of an attack. Verizon's 2026 Data Breach Investigations Report counted credential abuse at every stage, including after the initial break-in, and found it in 39% of breaches, more than any other access method in its comparison.
Why some leaked secrets are not high impact
Volume is what makes ranking necessary. We counted 28.65 million new hardcoded secrets on public GitHub in 2025, a 34% jump over the year before. When every finding is marked critical, nobody can tell the emergencies from routine cleanup, and security alert fatigue sets in fast.
Plenty of findings deserve a lower rank or a different queue:
- Test and sandbox keys: real credentials that authenticate to nothing that matters.
- Revoked or expired secrets: still worth checking for use while they were live, but no longer a way in.
- Narrowly scoped keys: read-only access to a single low-sensitivity resource.
- Secrets that aren't yours: a key that mentions your domain but belongs to a vendor or to someone's personal project.
- Duplicates: one secret found in many places, which is one incident to fix.
A low-impact leak still gets rotated on its owner's schedule instead of today's. It is also a different call from a false positive, which isn't a working secret at all.
The five factors that make a leak high impact
Reach, environment, liveness, and location set how much damage a leak could do, and time and ownership set how urgently it needs containing. They won't always agree. A credential might carry broad permissions with no way to confirm it still works.
1. Reach: what the credential can access
Start with privilege. Admin roles, write access, organization-wide installations, wildcard permissions, and the ability to assume other roles all widen what a leak can do. An overprivileged AWS key attached to AdministratorAccess and a key scoped to one read-only bucket are different incidents, even when the same detector flags both.
Our research on leaked GitHub App keys shows how far reach can extend. Among the Apps whose keys still worked, 44 held organization administration privileges, enough for a takeover of the organizations that installed them. The damage can also spread to systems connected to whatever the credential unlocks.
2. Environment: production, staging, or sandbox
The same key type carries different weight depending on where it authenticates. A payment provider's live key can move money, while its test key moves nothing real. Signals that point to production include hostnames, variable names with a PROD_ prefix, the default branch, and deployment files. Watch for reuse across environments. If a staging secret also works in production, rank it as a production secret.
3. Liveness: valid, unknown, or revoked
A confirmed-valid secret works right now. A revoked one no longer authenticates, though anything it did while live still needs checking. The difficult case is a secret nobody can test automatically, which is common for database passwords and internal credentials with no public endpoint to check against. When a secret can't be tested, context has to carry the decision. If it sits in production or the identity behind it holds admin rights, escalate without waiting for a validity check.
Untestable secrets are where validity-based triage breaks down. Our State of Secrets Sprawl 2026 found that validation-only prioritization misses 46% of critical secrets because they can't be verified automatically.
4. Location: where the secret surfaced
Where a secret lands decides who can find it, and how quickly. Public repositories and container registries are harvested automatically. Collaboration tools spread a secret to everyone in the thread during urgent work, and the 2026 report found that secrets leaked outside code are 13 percentage points more likely to be critical than those found only in code.
Developer machines are another concentration point. Across laptops in our Developer Endpoint Protection early access program, we found about 150 credentials per machine on average, with some holding thousands. And a secret that appears in public as well as internally is a bigger problem than the same secret found only inside your perimeter.
5. Time and ownership: how long it stays live and who can revoke it
Time covers how long the secret has been exposed, and whether it survives in git history after someone deletes it from the current branch. Ownership covers who can safely rotate it. A secret with no clear owner stays live longer, because nobody wants to break the service it runs. Long-lived, static credentials stretch both windows. In the GitHub App research, one App's key leaked in November 2020 and its installations still worked years later, long after the project behind it was abandoned.
The five factors at a glance:
High-impact leak examples from GitGuardian research
A government repository left public for six months
In May 2026, we found a public GitHub repository named Private-CISA holding 844 MB of CISA data, including plain-text passwords and AWS tokens, exposed since November 2025. Some of the credentials were still valid. Reach, liveness, location, and time all score high here. CISA took the repository offline within 26 hours of our disclosure.
A Jira token inside a public container image
A public Docker image from a consumer electronics company contained valid Jira credentials tied to an employee's account. The leak never touched a code repository, so a scanner watching only source code would have missed it. The company's security team replied quickly to our report and started remediation.
Kubernetes credentials traced through a container registry
Valid credentials for a Kubernetes cluster turned up in a public GitHub commit. The clue to their owner was the cluster's container registry, hosted on a large telecom operator's domain. Depending on their permissions, those credentials could allow someone to modify running workloads or access sensitive data. We reported the leak through the company's bug bounty program, where triage rated it 9.8, a critical severity score, within three days.
How GitGuardian ranks leak impact
Several GitGuardian capabilities answer the questions above. Each one maps to at least one factor:
- Validity checks (liveness): checks against the provider, where possible, confirm whether a secret still works.
- Risk score (several factors): a machine-learning score from 0 to 100 on Internal Monitoring incidents, drawn from secret type, validity, detection context, and exposure patterns. The Critical view shows scores above 80.
- Secrets Analyzer and NHI Governance (reach): map the roles and permissions a secret carries and flag admin or overprivileged machine identities, so findings tied to them rank higher.
- Public Secrets Monitoring (reach, location): GitGuardian assesses each public incident for company relevance and risk, and shows the reasoning behind the verdict. Your team still makes the final call.
In GitGuardian's evaluation, the machine-learning ranking surfaced 72% of critical leaks, with 75% precision on critical flags.
GitGuardian gives security teams a ranked list of exposed secrets and the context to act on the high-impact ones first, while the provider's own logs still confirm whether a credential was used.
See your own incidents ranked by impact.
FAQ
What is a high-impact leak?
An exposed secret that could do serious damage if someone used it. It reaches production systems or privileged access, and nobody can show it has stopped working. Most leaks don't meet that bar, which is why teams rank them by impact before they start revoking. GitGuardian adds two conditions before warning an outside organization: the leak has to be public, and it has to be clearly tied to that organization.
What is credential compromise?
Credential compromise is when a password, API key, token, or other secret ends up somewhere someone else could use it without authorization. For human accounts it often starts with phishing or infostealer malware. For machine credentials it more often starts with a leak, such as a key in a repository or a developer laptop. Once the attacker authenticates, most downstream controls treat them as the legitimate identity.
Are leaked credentials the same as compromised credentials?
For machine credentials, we treat them as the same. A credential exposed anywhere outside a vault is one someone else could use, so it counts as compromised from the moment it's found. What changes from one leak to the next is the impact.
What happens if your API key gets leaked?
Anyone who finds it can call the API as your application, with every permission the key carries, until someone revokes it. A read-only analytics key limits the damage, while a cloud or payment key can mean data theft or fraudulent charges. Revoke it, or swap in a replacement first if revoking would break production. Then check the provider's logs for use you didn't make and remove the key from wherever it leaked.
Is every valid secret a high-impact leak?
No. Validity confirms that a secret still works and says nothing about what it can reach. A valid key that reads one sandbox bucket is a hygiene issue. Attach the same validity to an admin role in production and it needs action today. Rank valid secrets by privilege and environment before deciding what to revoke first.
Can a secret that can't be validated still be high impact?
Yes. Database passwords and internal credentials often have no endpoint to test against, and an untestable secret can still work. An unknown validity status calls for a closer look at context before anyone closes the incident.
How do attackers exploit compromised cloud credentials?
They authenticate as the identity the credential belongs to and put its access to work: pulling data from storage, running compute for crypto mining, creating new keys or users to keep a foothold, or assuming roles in other accounts. Because the calls come from a valid identity, they often look like normal activity until someone reviews the logs or the bill.
How do canary tokens detect compromised credentials?
A canary token, also called a honeytoken, is a decoy credential that grants no real access and has no legitimate reason to be used. Teams plant it where real secrets accumulate, such as repositories or CI variables. When someone uses or accesses it, it fires an alert with context about the source, which signals that the location was harvested and nearby real secrets need attention.
What should we do if GitGuardian contacts us about a leaked secret?
Treat it as real and route it to whoever can revoke the credential. The notice explains what leaked, where it appeared, whether it still works and what it can reach. GitGuardian confirms and assesses exposed credentials without taking destructive action, and its disclosure principles are published.