TL;DR: Verizon’s 2025 DBIR found 441,000 secrets in public Git repositories, with JWTs making up 66% of exposed web-app infrastructure secrets and GitLab credentials half of exposed CI/CD and development tokens, showing how easily non-human identity exposure still drives compromise, according to Entro Security. Secrets governance fails when exposure, ownership, and rotation lag behind attacker access.
At a glance
What this is: Entro Security’s analysis of Verizon DBIR data shows that leaked secrets in public repositories remain a primary path into NHI compromise, especially through JWTs and GitLab tokens.
Why it matters: IAM and NHI teams need to treat secrets discovery, ownership, and revocation as operational controls, because exposed tokens can bypass MFA, expand API access, and speed lateral movement.
By the numbers:
- 39% were web-app infrastructure secrets, and 66% of those were JWTs.
- 32% were CI/CD and development tokens, with GitLab credentials alone making up half.
- The median time to remediate leaked secrets in public repositories was 94 days.
Context
Leaked secrets remain a governance failure, not just a hygiene issue. When tokens, JWTs, and service credentials are exposed in code or repositories, the problem is not only discovery but also who owns the secret, who can revoke it, and how quickly the exposure window closes.
In NHI terms, the control gap is straightforward: a secret is itself an identity-bearing credential. If it can be copied, reused, and left active for weeks or months, then the organisation has effectively granted standing access without a reliable offboarding process.
The article uses Verizon DBIR data to show that this pattern is still common across public repositories, CI/CD systems, and GenAI-adjacent workflows. That makes secret lifecycle governance a core identity programme concern, not a niche DevSecOps task.
Key questions
Q: What breaks when leaked NHI secrets are not revoked quickly?
A: The credential remains a live authentication path long after exposure, which means attackers can turn a repository leak into authenticated access, API abuse, or lateral movement. The failure is not only disclosure but also delayed invalidation, because standing validity turns a one-time mistake into an active compromise window.
Q: Why do leaked secrets remain such a persistent NHI risk?
A: Leaked secrets persist because they are often embedded in code, pipelines, or collaboration tools, then left valid long enough for reuse. The real problem is not only exposure but weak identity lifecycle management, especially when ownership, rotation, and revocation are not tightly governed.
Q: How do identity teams know whether secrets governance is actually working?
A: Identity teams know secrets governance is working when they can prove that every active secret has an owner, an approved scope, and a tested revocation path. If they cannot quickly identify where a secret is used or remove it without breaking the workload, governance is still incomplete.
Q: What should teams do when a secret is compromised outside a code repository?
A: Teams should rotate the compromised key immediately, then trace where it was shared and used so related systems can be contained. They should also review adjacent tools and accounts for secondary exposure, because one leaked secret often reveals a wider trust path. Fast containment matters because remediation is resource intensive and affects engineering as well as security.
Technical breakdown
Why exposed secrets are high-leverage credentials
A leaked secret is not just a password equivalent. In modern cloud and SaaS environments, JWTs, API tokens, and service credentials often carry direct authentication power, broad API scope, or access to downstream automation. If the token is reusable, unbound, and not tied to a narrow session, an attacker can often authenticate as the workload or integration itself. That makes code repositories, logs, and CI output high-value discovery points because they contain credentials that do not need further user interaction once found. The technical issue is not secrecy alone, but the privilege embedded inside the credential and the blast radius that follows from reuse.
Practical implication: inventory secrets by privilege scope, not just by location.
Why remediation windows become attacker dwell time
The remediation problem is a lifecycle problem. Once a secret is exposed, the defender must discover it, assign ownership, validate whether it is still active, and revoke or rotate it before it is abused. If those steps take weeks, the attacker has enough time to automate collection, test the credential, and move into the connected environment. This is why remediation latency matters as much as exposure detection. A secret that remains valid for 94 days is not a past mistake, it is active access waiting to be used. The governance failure is the absence of a closure mechanism that is faster than reuse.
Practical implication: tie secret detection to automatic revocation and rotation workflows.
How GenAI and NHI access paths widen the exposure surface
The article’s GenAI observations matter because access paths are no longer limited to traditional application flows. When employees use non-corporate accounts, shadow plugins, or unsanctioned AI tools, credentials can be copied, reused, or embedded into workflows that bypass normal identity controls. That does not mean every AI tool is autonomous, but it does mean secrets can flow into places security teams do not monitor. For NHIs, the risk is compounded when a token is used by both an approved workload and an unverified integration. The technical issue is uncontrolled credential propagation across systems and contexts.
Practical implication: monitor where secrets are consumed, not only where they are stored.
Threat narrative
Attacker objective: The attacker aims to turn an exposed secret into authenticated access that can be reused for cloud abuse, API calls, or lateral movement.
- Entry occurs when attackers find exposed JWTs, GitLab tokens, or service credentials in public repositories, code, logs, or adjacent collaboration surfaces.
- Credential access follows immediately because the leaked secret already serves as an authentication factor, removing the need for password theft or MFA bypass.
- Escalation happens when the credential grants broad API scope, cloud access, or reusable service permissions that let the attacker pivot beyond the original repository.
- Impact is achieved through data access, lateral movement, or abuse of integrated systems before the organisation revokes the secret.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Leaked secrets are still standing identities, not just leaked data: Once a token or JWT escapes into code or a repository, it behaves like an addressable credential with its own lifecycle. The article shows that the real failure is not disclosure alone but the fact that the secret can continue to authenticate after disclosure. Practitioners should treat every exposed secret as a live identity until proven otherwise.
Secret governance fails when ownership is detached from revocation: The article’s 94-day remediation window shows that many organisations still cannot close the loop between discovery, accountability, and invalidation. That is an NHI lifecycle failure, because the credential outlives the team’s ability to act on it. The implication is that ownership metadata and automated revocation are part of the control, not administrative extras.
Ephemeral credential trust debt: JWTs, GitLab tokens, and service credentials create a trust obligation the moment they are issued, and that obligation compounds when they are copied into public or semi-public paths. The article makes clear that exposure is only the first stage; persistence is what turns exposure into compromise. For identity teams, the question is how much trust debt the programme is carrying in dormant secrets.
Cloud and DevOps pipelines are now identity supply chains: The exposed categories in the article are not random leaks, they are the operating material of modern software delivery. That means NHI governance must extend into code, CI/CD, and SaaS integrations, where credentials are minted, copied, and consumed. The practical conclusion is that secrets handling is a production identity control surface, not a back-office cleanup task.
Hybrid policy drift is the real reason GenAI increases risk: The article’s GenAI findings show how quickly credentials escape approved authentication paths when users move between corporate and personal accounts. That drift matters because identity controls lose visibility once a secret is embedded in unsanctioned workflows. Security teams should read this as an access governance problem first and an AI problem second.
From our research library:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Guide to NHI Rotation Challenges
What this signals
Ephemeral credential trust debt: Every exposed token creates a debt between issuance and invalidation, and the longer that debt sits unpaid, the more likely the credential will be reused in production paths. Teams should measure that debt in hours, not reporting cycles, because the attacker only needs one successful reuse.
Public repository leaks are now one of the clearest signals that secret governance is lagging behind software delivery. For NHI programmes, the practical issue is not just finding secrets faster but shrinking the number of places where a secret can remain valid after exposure.
For practitioners
- Inventory secrets by effective privilege Classify exposed tokens, JWTs, and service credentials by what they can actually access, not by where they were found. Prioritise secrets that bypass MFA, reach production APIs, or authenticate to cloud services.
- Automate revocation on exposure Connect secret discovery to immediate rotation or invalidation so a disclosed credential cannot remain usable for weeks. Human review should confirm context, not block containment.
- Attach ownership to every secret Require a named owner, recovery path, and revocation path for each credential so the team that receives the alert can act without searching for accountability.
- Reduce repository and CI/CD secret persistence Scan source control, build logs, and pipeline variables for reusable tokens and remove any long-lived credentials that are not bound to a narrow workload purpose.
- Monitor secret use outside approved contexts Watch for tokens being used in untrusted plugins, personal accounts, or other environments that do not match the original issuance path.
Key takeaways
- Leaked secrets remain a direct compromise path because the credential itself can authenticate into production systems long after exposure.
- The article’s figures show that exposed secrets are still common in repositories and often stay unremediated for months, which gives attackers time to use them.
- The control that matters most is fast revocation with clear ownership, because discovery without invalidation leaves the identity active.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on exposed tokens, JWTs, and leaked credentials in repositories. |
| NHI-07 — Long-Lived Secrets | The 94-day remediation window shows how long-lived credentials stay exploitable after exposure. | |
| NHI-05 — Overprivileged NHI | The article notes that exposed tokens can bypass MFA and grant broad API access. | |
| Recommendation — Scan for exposed secrets and revoke any credential found in code, logs, or repositories. Reduce secret lifetime so leaked credentials cannot remain valid for months. Review exposed credentials for scope creep and narrow privilege before reuse. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle control is directly implicated in rotation and revocation of secrets. |
| Recommendation — Apply authenticator lifecycle controls to rotate and invalidate compromised secrets quickly. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article describes leaked credentials being used as a path to further access. |
| Recommendation — Map leaked-secret risk to credential access and lateral movement detection. | ||
Key terms
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- Secrets Lifecycle: Secrets lifecycle is the management of credentials from issuance through rotation, revocation, and offboarding. It matters because a secret that is technically valid can still be operationally unsafe if its owner, purpose, or downstream access paths are no longer current.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
- Credential exposure window: Credential exposure window is the time period during which a secret remains usable, copyable, or replayable before it is revoked or replaced. The shorter that window, the less chance there is for abuse. In database governance, reducing this window is often more important than merely storing the secret securely.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on May 12, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org