I used to think deleting a secret from a file was enough, but Git keeps the earlier version in its history. Pre-commit hooks and CI usually inspect only the changes being introduced, so a secret can be committed, removed in the next change, and still remain usable in an older commit.
That makes scheduled full-history scans important, but detection alone does not contain the exposure. The secret still needs to be revoked or rotated. I have several side projects from years ago and no longer remember what may have been committed, so some old credentials could still be active.
Do you run periodic scans of the complete repository history in addition to pre-commit and CI checks? When an old secret turns up, do you always rotate it, or do you assess whether the repository was public and whether the related service or account still exists?
5 Answers
Long-lived credentials create most of this historical risk. Where possible, replace them with short-lived tokens or workload identity such as OIDC, and keep secret files out of version control with environment files, ignore rules, and a proper secret manager. Expiring credentials reduce the damage from anything accidentally left in old commits.
Use hooks and CI to prevent new secrets from being committed, but once a credential has entered the repository, assume it is exposed and rotate or revoke it. Removing the line only prevents future use from the current files; it does not invalidate the old value.
Treat every discovered credential as compromised, regardless of whether the repository was public. You cannot prove that nobody copied or used it. Check whether the related account is still active, revoke the credential if possible, and review provider audit logs for activity under the old key. For forgotten services, searching old signup and API-key emails can uncover accounts that are still open and billing-enabled.
Searching old email for service signups and API-key messages is a useful idea. I had not considered that as part of the cleanup.
Be careful during rotation, especially with webhook signing keys. Do not temporarily replace a missing secret with an empty value: many HMAC libraries treat an empty string as a valid key, which could let anyone create a matching signature. Validate that the secret is present before verification, and fail without acknowledging the event so the sender can retry after the configuration is fixed.
Keep the pull-request check focused on changed files so it can block new leaks quickly, then run a scheduled scan against the complete Git history. Tools such as Gitleaks, TruffleHog, or git-secrets can help with this. A history rewrite can remove the value from old commits, but rotation comes first, and rewriting history is risky if other people or systems have cloned the repository.
A scheduled full-history scan makes sense. I will look into adding one alongside the existing pipeline checks.
That is where I landed too. I am mainly unsure how far to chase credentials from services I no longer use or may not even have an account with anymore.