Why is it hard to detect API keys in source code?
gitguardian.com
Why is it hard to detect API keys in source code?
1–10 of 11 posts
Re: Why is it hard to detect API keys in source code?
#2> 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.
Re: Why is it hard to detect API keys in source code?
#3> 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.
Even if the secret is added then deleted?
Re: Why is it hard to detect API keys in source code?
#4> 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.
Even if the secret is added then deleted?
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).
Re: Why is it hard to detect API keys in source code?
#5Earlier quoted context omitted.
Even if the secret is added then deleted?
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 eve…
Some people only review the final diff and don't go through the code commit by commit.
Re: Why is it hard to detect API keys in source code?
#6Earlier quoted context omitted.
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 eve…
Some people only review the final diff and don't go through the code commit by commit.
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.
Re: Why is it hard to detect API keys in source code?
#7Earlier quoted context omitted.
Even if the secret is added then deleted?
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 eve…
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.
Re: Why is it hard to detect API keys in source code?
#8Earlier quoted context omitted.
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 eve…
Some people only review the final diff and don't go through the code commit by commit.
[deleted]
Re: Why is it hard to detect API keys in source code?
#9Earlier quoted context omitted.
Some people only review the final diff and don't go through the code commit by commit.
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 pr…
I completely agree that this is how the review should be done.
But this is not the case in all companies.
Re: Why is it hard to detect API keys in source code?
#10Earlier quoted context omitted.
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 pr…
I completely agree that this is how the review should be done. But this is not the case in all companies.
> But this is not the case in all companies.
In that case it's worth fixing the process before adding layers of tooling.