Open agoncal opened 2 months ago
This issue is currently awaiting triage.
If contributors determine this is a relevant issue, they will accept it by applying the triage/accepted
label and provide further guidance.
The triage/accepted
label can be added by org members.
Hello!
Thanks for the request, I can see how this could be useful for rule authors, I do have a question if you can help me think of other use cases along with the hard coded password type of rule?
@shawn-hurley I can imagine organizations wanting to build custom rules to update their custom security libraries/frameworks, and not wanting snippets of that code living outside of their secured repositories. @agoncal any other use cases?
Today we can disable code snippets in the reports. That's very useful for privacy reason. But this is done on a per-assessment basis: either you show the code snippets in the report or not. But sometimes you want to show the code snippets in the report, except for specific rules (e.g. a rule that looks for hard-coded passwords and displays the password in the code snippet).
It would be good if there was a privacy level on a per-rule basis. We could have several levels, going from public to private, something like:
And when you run an analysis, you could specify the minimum level of privacy.
This mechanism is inspired from the Logging level of logging frameworks