TL;DR: Truffle Security shows that secrets leaked into source code remain live IAM credentials, not code defects, and fixing them requires rotation, revocation, and verification in the identity system rather than another code review. That reframes secret scanning as detection, not remediation, and shifts control ownership to IAM and lifecycle governance.
At a glance
What this is: Truffle Security argues that API keys in source code are an IAM and identity lifecycle problem, not a code security problem.
Why it matters: That matters because practitioners who treat exposed secrets as a code defect will miss the real control point: issuance, rotation, revocation, and verification inside the identity system.
👉 Read Truffle Security's analysis of why source code secrets are an IAM issue
Context
API keys do not become safer because they were discovered in a repository. Once a secret is exposed, the governing question is whether the credential can still authenticate and what systems it can reach before anyone revokes it.
That is why this topic belongs in IAM and IGA basics as much as in application security. The failure mode is lifecycle control over a credential, not code hygiene.
The source article is describing a common programme gap: security teams often discover secrets through source scanning, but the authoritative fix still sits in identity operations, not in the pull request.
Key questions
Q: What should teams do first when they find an API key in source code?
A: Treat the discovery as a live credential incident, not a code defect. Revoke or rotate the key at the issuing identity system, then verify that it no longer authenticates anywhere it is used. Only after that should teams clean up repository history, branches, and copies that may still contain the secret.
Q: Why do exposed secrets keep creating risk after they are detected?
A: Because detection does not stop a credential from remaining valid, and exposed values often persist in repositories, logs, backups, and configuration files. Risk remains until revocation, cleanup, and dependency removal are complete, which is why exposed secrets are really lifecycle failures rather than alerting failures.
Q: How do organisations know whether secret scanning is actually working?
A: Look for fewer valid secrets left in circulation after detection, not just higher detection counts. Working programmes can show fast owner assignment, reliable false-positive suppression, and automated invalidation before a secret can be reused. If alerts do not change credential status, the control is informational rather than protective.
Q: What is the difference between secret scanning and secret revocation?
A: Secret scanning finds exposure, while secret revocation removes the ability to authenticate with the exposed credential. Scanning reduces blind spots, but revocation is what actually breaks attacker reuse and shrinks blast radius.
Technical breakdown
Why source-code secret leaks are really credential lifecycle failures
A leaked API key is not just sensitive text in a repository. It is an active authenticator that may still work across branch history, deleted commits, cloned laptops, CI logs, and other storage locations. The security problem is that the identity that issued the credential still trusts it until the key is revoked at the source system. That is why static review can identify exposure but cannot complete the remediation loop. Practical distinction matters here: discovery tools find the leak, but IAM controls determine whether the credential remains valid. See the API Key Management Guide.
Practical implication: Treat secret scanning as detection support and require the identity system to be the system of record for revocation.
Why CI/CD checks miss the actual risk window
CI/CD is built to inspect code artifacts moving through a pipeline, but an exposed secret is already compromised before the pipeline can evaluate it. A build can pass even when the credential exists in old branches, dangling commits, or files outside the checked path. The mechanism failure is temporal: pipeline controls look forward, while secret exposure often lives in historical artifacts the pipeline never reprocesses. That mismatch makes “block the build” an incomplete response when the credential is already usable elsewhere. Read Guide to the Secret Sprawl Challenge.
Practical implication: Extend detection beyond active branches and enforce live-key validation after any exposure event.
Why key management policy, not application code, controls blast radius
The control that matters is how the credential was created, scoped, and revoked in the identity platform. If key generation is too permissive, if scope is broad, or if rotation is slow, the blast radius remains large even when code security tooling flags the leak quickly. This is a classic NHI governance pattern: the weak point is not the repository, but the credential lifecycle around the repository. Effective governance therefore treats exposed keys as identity events with operational consequences, not as software defects awaiting a code patch. See the Secrets Management Guide.
Practical implication: Review key issuance and revocation settings as part of every secret exposure workflow.
Threat narrative
Attacker objective: Use a live leaked credential to gain authenticated access to systems, data, or cloud services that trust the compromised key.
- Entry occurs when an API key is exposed in source code, Slack, Jira, S3, or similar storage rather than kept only in the intended runtime boundary.
- Credential access follows because the leaked key can still authenticate even after the code is moved out of main or hidden from ordinary review.
- Impact occurs when attackers or unintended users reuse the live credential to reach cloud services, SaaS accounts, or downstream data.
- Persistence continues when the same key remains live in history, branches, or deleted commits, leaving the exposure unresolved after discovery.
Breaches seen in the wild
- OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Secrets in source code are an IAM lifecycle problem, not a code security problem. The article is right to reject the idea that source control tooling can remediate a live credential. Once an API key is exposed, the meaningful control is whether the identity platform can revoke, rotate, and verify it quickly enough to reduce exposure. Practitioners should read this as a governance boundary, not a tooling preference.
Secret scanning is a detection layer, not the control plane. Discovery tells you where a credential appeared, but it does not tell you whether the key is still live, who can use it, or whether it was cloned into history and endpoints. That makes the operational ownership problem sharper, not smaller. The right mental model is credential incident response, not source remediation.
Long-lived secrets create identity blast radius. The article’s core warning is that exposed keys often survive in branches, deleted commits, and copied workstations long after the repository view is cleaned up. That creates an exposure window that code review cannot see. The practitioner conclusion is straightforward: the issue is not merely leakage, but the continued validity of the leaked identity.
The strongest NHI control here is revocation accountability. When a secret leaves its intended boundary, someone must own the authoritative revoke-and-verify loop in IAM rather than assuming the engineering team can close the issue inside the repository. The governance gap is not visibility alone, but ownership of the credential after exposure. Without that ownership, every scan becomes a report instead of a fix.
From our research library:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Read next: Secrets Management Guide
What this signals
Secret exposure is now an identity governance metric, not just a developer hygiene metric. Teams should measure how quickly a discovered credential becomes unusable, because exposure without revocation still leaves a live authenticator in circulation. The programme signal is simple: if response ownership sits only with engineering, the identity side of the incident is under-controlled.
Exposure windows persist because repositories are not the only secret store. Truffle Security’s argument becomes more urgent when you combine it with the reality that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. That pattern pushes practitioners toward cross-system discovery and away from repository-only thinking.
Identity blast radius is the governing concept here. The point is not whether a key was found in code, but whether it can still authenticate, what it can reach, and how far copied history has spread it across endpoints and non-code systems. NHI identity basics frame this better than code-centric control models do.
For practitioners
- Prioritise live-key revocation workflows Route every discovered secret to the identity system first, then confirm the credential is no longer accepted before closing the case.
- Expand scanning beyond active branches Include old commits, deleted commits, dangling references, and non-code storage such as Slack, Jira, S3, and containers in secret discovery.
- Tighten key issuance and scope Reduce the default reach of newly generated API keys and make creation policy stricter so exposed credentials have less blast radius.
- Verify revocation at the source Use a live validation check against the issuing platform rather than relying on code review to prove the key is dead.
- Assign ownership for secret incidents Make IAM or identity operations the final owner of any exposed credential so remediation does not stall after the first scan result.
Key takeaways
- Exposed API keys are a credential governance problem because the real risk is continued authentication, not the fact that the secret appeared in code.
- The article shows that static review and CI/CD checks can miss live secrets that survive in history, branches, deleted commits, and non-code storage.
- The limiting control is revocation at the identity source, backed by validation that the leaked credential no longer works.
Related NHI Mgmt Group resources: API Key Management Guide · Secrets Management Guide · Guide to the Secret Sprawl Challenge · NHI Lifecycle Management Guide
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 CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set 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 secrets exposed in code and other storage locations. |
| NHI-07 — Long-Lived Secrets | The core risk is that leaked keys can stay valid long after discovery. | |
| NHI-04 — Insecure Authentication | A live leaked key is an authentication weakness, not just a visibility problem. | |
| Recommendation — Map exposed secrets to NHI-02 and revoke any leaked credential before closing the incident. Reduce the lifetime of machine credentials and eliminate long-lived secrets where possible. Review how keys authenticate and remove any pattern that allows leaked credentials to remain usable. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on controlling entitlements behind exposed machine credentials. |
| Recommendation — Tighten credential permissions so exposed keys cannot authenticate to broad downstream resources. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential issuance, rotation, and revocation are the central controls discussed. |
| Recommendation — Apply authenticator management controls to rotate and revoke exposed API keys immediately. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article is about managing machine accounts and their credentials across their lifecycle. |
| Recommendation — Use account management controls to inventory, revoke, and govern exposed machine credentials. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Leaked secrets create direct credential access opportunities for attackers. |
| Recommendation — Track leaked secrets as credential access events and prioritise response on any still-valid key. | ||
Key terms
- Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
- Authenticator Management: Authenticator Management is the lifecycle control of MFA authenticators such as passwords, passkeys, security keys and recovery codes. It covers enrolment, binding, rotation, revocation and recovery. Weak management leaves orphaned authenticators, unsafe resets and account takeover paths, so defenders need inventory, strong identity proofing for recovery and prompt removal when devices are lost or users leave.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
What's in the full article
Truffle Security's full article covers the operational detail this post intentionally leaves for the source:
- Examples of leaked keys surviving in branches, deleted commits, and cloned laptops
- Operational guidance for validating whether a compromised key is still live
- Direct workflows that connect secret discovery to IAM revocation actions
- Additional examples of secrets found in Slack, Jira, S3, and CI/CD systems
Deepen your knowledge
NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org