Turn on blocking at push time first, scan your existing history second, and automate revocation and rotation third. Doing it in this order stops new leaks before you spend weeks cleaning old ones. Alerts alone do not fix anything, because a leaked key keeps working until someone revokes it.
Why does the order matter?
If you start with a history scan, you get hundreds of findings on day one and a team that learns to ignore the tool. If you start with push time blocking, the backlog stops growing, and the cleanup becomes a finite job.
What should go first?
Push protection. GitHub's push protection blocks hardcoded credentials before they reach a repository and explains why the push failed. Note the limits in its documentation: repository level protection is off by default and needs to be enabled by an administrator, and by default anyone with write access can bypass a block by giving a reason. Each bypass is logged, so review them.
Other platforms and CLI tools offer pre commit or pre receive hooks that do the same job. Pick one place where blocking happens and make it hard to skip.
What goes second?
History and current state. Scan all branches and past commits, plus CI configuration and build logs. Verification helps here: a tool that checks whether a found credential is still live lets you triage by real risk. Group findings by owner, not by scanner.
The OWASP cheat sheet suggests using more than one detection tool and correlating results to find gaps, and tuning rules to limit false positives.
What goes last?
Response automation. OWASP's order for a leak is revoke, rotate, remove, investigate and follow documented procedures. Do these in that order, because removing a secret from git history does not make it safe if it was ever public.
Longer term, move away from static secrets. Short lived credentials with narrow scope shrink the damage of a leak. OWASP also recommends treating CI/CD tooling as production: least privilege, no secrets in pipeline output, and logs kept for at least 90 days.
Where can this go wrong?
- Blocking only on the main branch, so secrets land in feature branches
- Scanning code but not CI variables, container layers or logs
- Letting developers bypass without anyone reading the alerts
- Rewriting git history and thinking the problem is solved
- Counting findings as the metric, instead of time to revoke
How do you handle developer pushback?
Developers push back when a block feels arbitrary. Show the finding, name the secret type, and tell them the fix in the same message. A message that says "possible AWS access key on line 12, remove it and use the secrets manager" gets acted on. A message that says "policy violation" gets bypassed.
Keep an eye on the false positive rate for a few weeks after rollout. Tune patterns that fire on test fixtures, and give teams a documented way to mark known safe values, with a reviewer, rather than a silent ignore list.
Finally, publish a short guide for the next time someone leaks a key. If the steps are written and rehearsed, the first hour of response goes to revoking, not to arguing about who owns what.
What to do
- Choose one blocking point at push or pre receive and enable it for all repositories.
- Enable bypass alerts and assign someone to read them weekly.
- Scan full history and group findings by owner.
- Verify which findings are live and revoke those first.
- Rotate every confirmed secret and record the date.
- Add scanning for CI variables, build logs and images.
- Move one high value secret to a short lived credential each month.
Quick check
Is it enough to delete the secret from the repo?
No. Treat it as compromised, revoke it and rotate it. History rewriting is cleanup after that.
Should the pipeline fail on every finding?
Block on verified or high confidence secrets. For low confidence patterns, report and review, or developers will route around the check.
Sources
Last reviewed: 18 October 2026.
