Stop Secrets Before They Reach Git: A Pre-Commit Setup

Each layer catches what the previous one misses:

• Pre-commit hook: fastest feedback, runs on the developer's machine, scans only staged changes. Anyone can bypass it with a flag, or may never have installed it.
• CI check: runs on every pull request in a controlled environment, and can't be skipped without changing the pipeline. Slower to give feedback, but reliable.
• Push protection on the server: the git host blocks a push containing a recognized secret pattern. GitHub Advanced Security offers this for supported patterns, which makes it a useful backstop for people who skip hooks.

If you only do one, do the server-side or CI layer, since it doesn't depend on every laptop being configured. The hook is what makes the experience pleasant.

Use a hook manager that keeps configuration in the repository, so everyone gets the same behavior.

1. Choose an open-source secret scanner that supports staged-file scanning and custom rules.
2. Add a pre-commit configuration file to the repository that runs the scanner against staged changes only, so it stays fast.
3. Document the one-line install command in your README and in the new-hire setup checklist.
4. Add a check to onboarding that confirms the hook is installed, for example a script that fails the first build if it isn't.
5. Test it by staging a fake key in a scratch branch and confirming the commit is rejected.

Keep execution time low. If the hook takes several seconds, people will disable it. Scanning only what changed, and skipping lockfiles and generated files, keeps it quick.

Noisy scanners get turned off, so plan for tuning from day one. Test fixtures, example values in documentation and high-entropy hashes will trigger detections.

Add allowlist entries narrowly: a specific file path and pattern, not an entire directory of code. Prefer a visible inline annotation on the line, with a comment saying why, so reviewers see it. Review the allowlist in pull requests like code. If a fixture must look like a key, make it obviously fake, such as a string that spells out 'example'. Finally, run a one-time scan of existing history to establish a baseline and clean up old findings separately, so the hook only judges new changes.

Assume any secret that reached a remote repository is compromised, even in a private one and even if you delete it quickly. Rewriting history doesn't help with clones, forks and caches.

1. Revoke or rotate the credential first, before anything else.
2. Check the provider's logs for use of the key since it was committed.
3. Remove it from the code and, if you choose, from history, after rotation.
4. Replace the hard-coded value with a reference to a secrets store or environment injection.
5. Note the incident, and decide whether it needs formal handling under your incident process.

If the secret gave access to customer data, involve your attorney about notification duties.

Scanning catches mistakes, but the better fix is fewer places for secrets to exist. Move credentials into a secrets manager and inject them at deploy or run time, so developers rarely handle raw values. A tool like Doppler syncs secrets to each environment and cuts the sprawl of local .env files, while AWS-native teams often use AWS Secrets Manager; the tradeoffs are in HashiCorp Vault vs AWS Secrets Manager vs Doppler and the cost side in the AWS Secrets Manager cost calculator. Add dependency checks in the same pipeline with dependency vulnerability scanning on GitHub.