One API key in three repositories: investigating shared credentials

Updated October 4, 2026. The previous version described an invented Stripe breach with precise copy counts, simultaneous outages, and a dollar loss as though they were measured facts. It also made unsupported claims about competing tools. This guide replaces that story with the evidence a team can collect when one credential is found in several connected sources.

What three findings tell you

If the same credential appears in three GitHub repositories, it has at least three observed source locations in that connected scope. The locations may differ in visibility and access. Record the repository, file, commit, current public status, and time of each observation. Do not assume the three repositories are the only copies, that three services use the key, or that an attacker has used it.

A repository location is not a runtime dependency. One repository can feed several deployments, while another contains only an example or an obsolete value. The key’s issuing service is needed to determine whether the value is still valid and what it can access. The owners of the workloads must identify which jobs actually read it.

Check the key, its reach, and its owner

Identify the credential type before treating it as a secret. Stripe, for example, distinguishes publishable keys from restricted and secret keys. A publishable key is designed for client-side use; a live restricted or secret key must be protected. Stripe recommends restricted keys with only the permissions an integration needs and provides rotation and expiration controls in its Dashboard.

For a sensitive key, check the issuer’s current status and permissions, and find the owner responsible for replacement. A supported verification result is a point-in-time signal. A source author may know how a value entered a repository but may not own the current payment or batch workload. Review issuer request logs for the relevant window if exposure or misuse is suspected, and record what the logs do and do not show.

Plan replacement without inventing a dependency map

Ask each service owner where the key is supplied: a deployment secret, a build setting, a configuration file, or a shared vault entry. List the workloads that would lose access when the old value is disabled. Then issue appropriately scoped replacements, update the confirmed consumers, test their requests, and expire or revoke the old key at its issuer. Check that the old value is rejected and remove avoidable copies from approved sources.

If a sensitive key is public or suspected compromised, contain it promptly. A long migration window can leave an attacker access; availability concerns should be handled alongside the incident response. There is no universal rule to wait until every possible copy is found before revocation. Conversely, deleting one repository line does not rotate a key at Stripe or another issuer.

What Cremit’s Over-shared Key item means

CRE-004 flags an active or manually active credential when the same finding has been seen in at least three distinct connected targets of one scan-source type. Three GitHub repositories are one possible example. A separate checklist item concerns findings across different platform types. The count is limited to what has been connected and scanned; it does not inventory local developer machines, every CI setting, or every use of the key at runtime. It also does not calculate how many services would fail if the key were revoked.

Use the finding locations as the starting list for an owner-led investigation. Check source visibility, issuer status, permissions, actual consumers, and response evidence. Cremit can help route supported findings and verification results; the issuer remains the place to rotate or revoke the credential.

Primary sources

Stripe Docs — API key types, permissions, and rotation

GitHub Docs — Secret scanning scope and response

GitHub Docs — Removing sensitive data from a repository