> Why do code reviews fail at finding secrets in source code?
Hmm, what?
Unless the code is highly obfuscated to hide the secrets, in which case reviewers should be asking what that piece of code actually does and/or what those magic numbers are (and you should have a rule that all constants must be documented in the code), secrets like API keys are trivial to find during code reviews.
For the secret to be added it must pass code review as the point is to vet what is added to the repository.
If at the point of the review that code has already found its way into the repository, which should then be purged, that is an action that can be taken when the secret is found during review. Granted that means a manual operation, but obviously only when a secret is found, which should hardly ever happen if everyone is clear about internal coding rules and basic security (which the team should be).
No you can add and delete without going through code review. And this is was happens most of the time as we're all constantly committing deletions and additions that we push on a feature branch for example before it is being reviewed and merged.
There should be only a single commit, vetted by the code review.
What happens before on a private branch (usually on a local copy of the repo) can be purged (and probably should be purged as a matter of course) if there is a worry of what might be contained in there.
The bottom line for is that the most important is to define a good process first before trying to use tooling to correct process deficiencies. A good process brings many benefits by 'forcing' good outcomes and avoid a lot of headaches.
Hmm, what?
Unless the code is highly obfuscated to hide the secrets, in which case reviewers should be asking what that piece of code actually does and/or what those magic numbers are (and you should have a rule that all constants must be documented in the code), secrets like API keys are trivial to find during code reviews.