Secrets that leaked
Near misses: secrets that ended up somewhere they should not be. None is known to have been used by an attacker. Each one had to be rotated.
How it happens
What we found
| Where | What | Fix |
|---|---|---|
| Application logs | User tokens in query strings and a service key in a header, for weeks, readable by everyone with log access | Redaction list and test; key rotated |
| A git remote URL | A personal access token written into .git/config of a cloned repo | Token revoked; credential helper or SSH instead |
| A committed readiness doc and the app binary | The fixed store-review code, live in production | Turned off in production; rotated elsewhere |
| A chat message | A database master password, during a handover | Rotated |
A server's .env | Payment credentials encrypted with a local key instead of KMS | Moved to KMS envelope encryption |
Rules
Rule
A secret that has been in a log, a repo, a chat or a binary is burned. Rotate it the same day. Deleting the message or rewriting history does not un-leak it.
Rule
Share secrets only through the team vault or the secret store, never in chat, email or docs.
- Run a secret scanner (for example gitleaks) in CI and on any repo you import.
- After rotating, check who could read the old value and for how long. If personal data was exposed, follow Breach response.