Public API key in a repository: what to check first
A public commit proves exposure, not misuse. Check validity, permissions, issuer logs, and dependent workloads before closing the incident.
On this page(5)
Table of Contents
Updated October 4, 2026. An earlier version presented an unverified bot-discovery timeline and a long illustrative attack chain as if they described a measured incident. Those details did not establish what happened to any specific key. This guide starts with what a public repository actually proves and what a responder must still check.
What a public repository proves
If a credential appears in a public commit, it was exposed to people and systems that could read the repository. Record the repository, commit, path, time you first observed it, credential type, and likely issuer. Limit who can see the raw key during investigation. A commit author is a lead, not necessarily the owner of the service that uses it.
Exposure does not show whether the key still works, what it can access, or whether anyone used it. Do not turn an illustrative attack path into an incident finding. GitHub scans supported secret patterns in repositories, but its detection and validity checks have documented coverage limits. A missed alert is not proof that a key is safe.
Check validity, permissions, and dependencies
Identify the issuing service and the workload that depends on the key. Where the issuer supports a safe validity check, confirm whether it remains active. Determine its permissions and scope: a key limited to one read-only API is different from an administrator key. Note expiry, source restrictions, and every environment using the same value. For unsupported types, work with the owner rather than testing a live key against an unknown endpoint.
Treat a potentially active exposed key as compromised while the response is coordinated. Make a replacement plan for dependent workloads, but keep the exposed value usable for as little time as possible. The owner should revoke or rotate it at the issuer and confirm the old value no longer works. GitHub recommends revocation or rotation before trying to remove sensitive data from repository history.
Investigate use without inventing a timeline
Review the issuer’s audit records and usage metrics for the exposure window. For an AWS access key, check the account for unauthorized activity and inspect CloudTrail and relevant service logs. CloudTrail Event history has scope and retention limits, so an empty search does not prove the key was never used. Preserve what the logs actually show and separately record any missing coverage.
After containment, search for copies in branches, forks, build artifacts, deployed files, chat messages, and other approved sources. Removing a line from the latest commit does not revoke a key or erase earlier copies. Rewriting Git history can have side effects for collaborators; coordinate it only after the credential is invalidated. Fix the path that let the key enter the repository, such as a committed configuration file or an absent push control.
Where Cremit helps
Cremit Platform can scan supported connected sources, verify supported credential types with their issuers, and route findings to a responder. Confirm the connected repositories and key types before relying on that coverage. Cremit does not prove an attacker used the key or rotate it automatically. The issuer and its logs remain the source for access and use evidence.
Primary sources
GitHub Docs — Removing sensitive data from a repository
GitHub Docs — Secret scanning scope
Read next
Your Dashboard Says 14,000 Secrets. The Number That Matters Is 525.
Every secret scanner hands you a big number, and almost nobody can act on it. When we checked the findings we could verify against the service that issued them, a five-figure detection count became a three-figure inventory of credentials that actually work, plus a set we could not check automatically. This is what that collapse means for how you prioritize, what you suppress, and what you tell your board.
The machine access behind an exposed API key
An exposed key is a lead. Connect it to its issuer, principal, permissions, workload, and owner before closing the access path.
Unrotated API Keys: Why Years-Old Credentials Still Run Production (NHI Kill Chain #3)
A single AWS key, never rotated for 3 years, spread across 7 systems. When a supply chain attack hit a Terraform CI plugin, the key gave attackers full infrastructure access. Inside the Aged Key kill chain and how to defend against long-lived credentials.
Get the next one in your inbox
Monthly NHI security brief from Cremit. One email, high signal.