← All features
Leaked keysEarly access
A leaked key, handled from first sight to confirmed dead
A key rarely lives in one place. When one leaks, in a commit, a log or a provider breach, I find every place it is stored, work out what depends on it, and plan the rotation so nothing breaks. Once the new key works, I confirm the old one is disabled.
LEAKED KEYS
A commit to web-app 4 minutes ago added what looks like a live AWS access key in config/dev.ts.
The same key is set in GitHub Actions and in 2 Railway services. It belongs to the IAM user deploy-bot.
Plan: you create a new key and set it in Actions and both Railway services. Once a deploy passes, I deactivate the old one. Sound right?
New key is in. Deploy passed.
Deactivated the old key; IAM shows it as inactive. Closing the case.
Ask it like this
“Where does our Stripe key live?”“Someone pasted a key in #general”“Rotate the leaked OpenAI key”“Do we have keys that never expire?”
How it works
01Catch itI scan new commits for secrets and read GitHub’s secret scanning alerts. A key format I recognise is treated as high severity.
02Find every copyI check where secrets live: GitHub Actions secrets, Railway variable names, AWS Secrets Manager and long-lived keys in IAM. I read names, never values.
03Rotate in orderI plan the rotation so dependent services keep working. You make the changes my access doesn’t cover, and I do the ones it does, like deactivating the old AWS key.
04Confirm it’s deadWhere I can see it, as with AWS keys, I check the old key is disabled before closing the case.
GitHub
AWS
Railway
SlackGuardrails
- The secret itself never leaves the scanner. Evidence is a redacted record.
- I read where secrets are stored by name only, never their values.