New feature motivation
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.
Solution Proposed
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.
Describe alternatives you've considered
None so far
Additional context
No response
New feature motivation
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.
Solution Proposed
For example, the
KeywordDetectorfinds 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
KeywordDetectorone for all because it can be used for manual audits. Thus, making the used detectors configurable would be a good solution.Describe alternatives you've considered
None so far
Additional context
No response