Public API key in a repository

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.