-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(aws): key error for detect-secrets #6710
fix(aws): key error for detect-secrets #6710
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #6710 +/- ##
=======================================
Coverage 88.76% 88.76%
=======================================
Files 1195 1195
Lines 34471 34469 -2
=======================================
+ Hits 30597 30598 +1
+ Misses 3874 3871 -3
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Hey! @kagahd thanks for your contribution! I'll review it when I get a chance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this @kagahd 👏🏼 🔝
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation and see the Github Action logs for details |
Context
PR #6537 introduced a bug which this PR will fix.
Description
Both prowler checks
ecs_task_definitions_no_environment_secrets
andawslambda_function_no_secrets_in_variables
will throw a key error if the potential secret is not the whole but only a part of the value.Since PR #6537, the whole value was sha1 hashed and associated to its variable name in order to get the variable name back by passing the found potential secret which was also sha1 hashed by detect-secrets. However, detect-secrets hashes only the part of the value which was detected to be a potential secret but not the whole value as PR #6537 did.
For example, if the value is
srv://admin:pass@db
, detect-secrets will hash onlypass
and not the whole value. Therefore, the hash will differ from the hash computed by PR #6537 and as such it will not be retrievable, leading to a key error and therefore missing the finding.As you see in this PR, the fix consists in associating the line number with the variable name. Since detect-secrets returns the line number, we are still able to get the variable name for easy spotting the potential secret.
The line number is off by 2 because the array
original_env_vars
starts at 0 while the json, passed to detect-secrets, starts with a curly bracket in line 1.I added some more unit tests to cover cases with secrets found on different lines in different order with different detectors.
Checklist
License
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.