Almost every organisation has secrets in places they should not be, and almost every one believes it does not. The reason is that secrets spread by ordinary, reasonable actions: an engineer pastes a connection string into a chat to unblock a colleague, a config file gets committed during a rush, a credential is emailed to a contractor. None of these are negligence. They are what happens without a mechanism that makes the right path easier than the wrong one.
Start by finding out what you actually have. Scan your git history, not just the current files - a credential removed in a later commit is still in the history and still valid unless it was rotated. Free tools do this well. The first scan on a codebase of any age is almost always uncomfortable, and it is the most valuable half-day of security work available to most teams.
Then rotate everything you find. This is the step people skip, because deleting the file feels like fixing it. It is not: if a key was ever committed, in any branch, it should be treated as compromised. The same applies to any credential a departing employee had access to - offboarding that revokes the account but leaves shared service credentials unchanged has not closed the door.
For storage, use a secrets manager - Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager - rather than environment variables baked into images or configuration checked into the repository. The properties worth having are access control per secret, an audit trail of who read what and when, and rotation without a redeploy. That audit trail is the thing you will want during an incident and cannot reconstruct afterwards.
Prevent recurrence at the two points where secrets enter: a pre-commit hook on developer machines and a secret-scanning step in CI that fails the build. The hook catches most of it at the cheapest moment; the CI check catches what the hook missed because someone bypassed it. Neither is sufficient alone, and together they change the default.
Two habits worth building beyond the tooling. Prefer short-lived, automatically rotated credentials over long-lived ones - most cloud providers support workload identity that removes the static credential entirely, which is strictly better than protecting one. And when someone does need to share a secret with a colleague, give them a sanctioned way to do it, because if the only options are a secrets manager they find awkward and a chat window, the chat window wins every time.
