Replies: 2 comments
-
I would suggest think about - move check to separate repo, then i can use prowler as is with default checks, or set repo with checks/providers which will add more flexibility on usage and give opportunity whith out changing core write extensions with own set of rules |
Beta Was this translation helpful? Give feedback.
0 replies
-
I'm closing this discussion because it's moved to a feature request: #6522 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello dear prowler team, what do you think about making DetectSecrets detectors configurable? Instead to have all the detectors hard coded in utils.py, they could/should be in config.yaml. This would make it easier to deactivate detectors aka plugins.
For example, the
KeywordDetector
finds a lot of false-positives because even if the keyword is suspicious (e.g.DB_PASSWORD
) the value may be harmless (e.g. the ARN to the secret in AWS secrets manager). Even worse, the user could only mitigate the "potential risk" by renaming the keyword, not its value, to make the check pass.However, I wouldn't wipe the
KeywordDetector
one for all because it can be used for manual audits. Thus, making the used detectors configurable would be a good solution.Beta Was this translation helpful? Give feedback.
All reactions