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.
Why the first move is revocation, not cleanup
An api key in source code should be treated as an active bearer credential with immediate blast radius, not as a simple coding mistake. The first priority is to invalidate the credential at the issuing identity system so the exposed value can no longer authenticate. That preserves the real control boundary and prevents an attacker, a scanner, or an indexing service from continuing to use the secret.
For teams that need a practical reference on lifecycle handling, API Key Management Guide covers how to revoke exposed keys, scope them more tightly, and manage the full key lifecycle.
What to confirm before you call it contained
After revocation or rotation, teams should verify that the old key no longer works anywhere it was used. That means checking production systems, test systems, automation, and any partner integrations that may have cached the credential or exchanged it for a session or token. The issue is contained only when the revoked value is rejected consistently and the replacement credential is verified in the legitimate path.
Incidents involving exposed secrets often show how quickly source code exposure becomes wider access. EmeraldWhale Git config credential theft is a useful reminder that exposed repository material can be used to reach far beyond the original file that held the secret.
What to clean up after the credential is no longer live
Only after the exposed key is dead should teams clean repository history, branches, mirrors, local clones, build artifacts, tickets, and chat logs that may still contain the secret. Cleanup matters because code history is durable and searchable, but it is secondary to killing the credential itself. If the secret still authenticates, history rewriting is housekeeping, not containment.
The same sequence appears in breach reporting where leaked tokens later enabled renewed access. Internet Archive breach 2024 illustrates why unrotated or still-valid tokens are the real incident, while repository cleanup only removes evidence of the exposure.
Risk and Threat Considerations
A key in source code is often easier to find, copy, and reuse than teams expect, especially when it lands in public history, forks, build logs, or cloned developer machines. The main risk is not the file itself, but the credential’s continued ability to authenticate long after discovery.
Failure mechanism: An attacker or scanner pulls the exposed key before cleanup, then uses it against the live service because the issuing system still accepts it. If the credential has broad scope or long lifetime, the exposure can extend to data access, admin actions, or lateral movement through connected services.
Impact: Teams can end up with unauthorized API calls, silent data access, configuration changes, or repeated re-entry even after the original repository has been scrubbed. Delayed revocation also increases the chance that logs, caches, and downstream systems will keep accepting the old value until explicit invalidation occurs.
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 addresses the attack and risk surface, while CIS Controls v8, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Exposed API keys in code are leaked secrets that can be reused immediately. |
| NHI-07 — Long-Lived Secrets | A source-coded API key is risky when it remains valid beyond the exposure window. | |
| Recommendation — Revoke the leaked key at the source and scan for any other exposed secrets. Shorten secret lifetime and rotate keys as soon as exposure is discovered. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Finding secrets in source code is an application security failure that needs secure coding and secret handling discipline. |
| Recommendation — Remove embedded secrets from code and enforce secret scanning in the development pipeline. | ||
| OWASP ASVS | V14 — Data Protection | ASVS data protection requirements address preventing sensitive secrets from being exposed in code and repositories. |
| Recommendation — Protect secrets at rest and keep them out of source-controlled assets. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | API keys are authenticators whose lifecycle must be controlled through issuance, rotation, and revocation. |
| Recommendation — Revoke the exposed authenticator and replace it with a newly issued one. | ||
Practitioner Guidance
Decision rule: If the value can still authenticate, treat the incident as active compromise until proven otherwise. Revoke first, verify rejection everywhere second, and defer cleanup until you have a dead credential and a known-good replacement.
What to verify: Confirm whether the key was used in automation, shared with a third party, embedded in deployed code, or exchanged for tokens that may outlive the original secret. Those paths determine whether you also need to rotate dependent credentials, sessions, or downstream access grants.
Practitioner takeaway: Source-code exposure is a discovery event; containment only starts when the issuing system stops honoring the secret.
Related resources from NHI Mgmt Group
- What should product security teams do first when a data breach exposes source code, certificates, or API secrets?
- What should teams do first when they find high-risk Active Directory exposure?
- How should security teams correlate WAF alerts with source code context in API security programs?
- How should security teams connect cloud workload findings to source code so they can fix exploitable issues faster?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org