Hacker News Reader

That's certainly a good idea. But the secrets shouldn't be in the codebase to begin with, certainly not production secrets. Production secrets should stay in production and no one has access. Whatever intends to use the production secrets should have first been developed in a dev environment and released to prod.

Gitleaks also offers a nice pre-commit hook: https://github.com/zricethezav/gitleaks#pre-commit

A nice approach, if you have sufficient control over the form of your secrets, is to prefix each secret with "MY_COMPANY_SECRET_DO_NOT_COMMIT:". Then you can add a commit hook that refuses to commit if any committed file contains that substring, etc. etc.

Great idea, but hard to enforce. Just use a scanning CLI like TruffleHog, Gitleaks, or ggshield from GitGuardian to catch all sorts of hardcoded secrets.

Code-reviews? Should be a ritual you do on your own code before commiting+pushing and should be a ritual that others will do in the PR before merge (arguable here a secret is already compromised).