GitHub secret scanning alert" api key exposed
Works a GitHub secret scanning alert for an exposed API key: confirm exposure, revoke and rotate the key, then resolve the alert. Use when a secret scanning alert fires on your repo. Not for push-protection blocks (different flow).
TL;DR
A secret scanning alert means GitHub (or a partner) found a credential pattern in your repo. Open the alert, revoke the exposed key at its provider, replace it everywhere it is used, then mark the alert resolved. Revocation comes before cleanup.
Error
"GitHub secret scanning alert" api key exposedSteps
- Open the alert in the repo's Security tab and read which file and commit exposed the key. Expected: you know the exact location and the key's prefix or fingerprint.
- Revoke the key at the provider's dashboard or API immediately. Expected: the provider confirms the key is dead.
- Issue a replacement key and update every consumer: app config, CI secrets, and any external integrations. Expected: services run on the new key with no downtime.
- Remove the exposed value from the repo (history rewrite if it is in an old commit). Expected: the value no longer appears in the codebase.
- Mark the alert as resolved in GitHub with a note of what was rotated. Expected: the alert moves to closed and stays closed.
When to use
- A secret scanning alert appears for a repo you own.
- The exposed value is an API key, token, or similar credential.
When not to use
- Push protection blocked the commit before it landed (nothing is exposed yet).
- The alert is on a fork you do not control (rotate your key; you cannot fix their repo).
Tool compatibility
- GitHub secret scanning and push protection; partner patterns plus custom patterns.
Variant phrasings
GitHub secret scanning found a token in my repo
Same workflow regardless of credential type.
secret scanning alert for a private key
Same steps; private keys need rotation of everything signed by them too.
Why it happens
Secret scanning runs on every push. Partner patterns catch known provider formats; anything matching gets an alert and, for partners, an automatic notification to the provider.
Edge cases
- Alerts on historical commits still mean the key was exposed the whole time it sat there; rotate even for old findings.
- If the same key is used across repos, one alert means all copies are burned; rotate everywhere.
- Dismissing an alert as a false positive without revoking is how breaches happen; revoke first.
Provenance
Resolved from the public thread: https://vectle.com/posts/pstShnAhACsCqOEQWTb81EJQ