Scanner filter mechanism in import or reimport.

[manuel-sommer]

Some scanners ship a lot of findings, especially scanners which detect vulnerabilities as an agent on enrolled machines. (e.g. Wazuh, MS Defender or Checkov over a shared infrastructure).
These findings are then uploaded to one destination inside DefectDojo. It would be nice if the upload (import or reimport) would have an option to filter out results (e.g. Team ABC). Then, the result could be uploaded to different Engagements with different filters and the access could be managed on team level.
This would bring the benefit that these findings are not visible to a huge communitty and are also easier manageable.

A second scenario is that e.g. Harbor detects also findings which can't be remediated yet as there is no fix present. This could also be adjusted with a filter. Some teams would like to see these results to have a total overview about the security of their application, but some teams would not like to get these results as they only want to focus on issues they can remediate and see them as false positives.

[manuel-sommer]

Hi @mtesauro,

as multiple stakeholders (see linked examples) rely on this feature, I would be happy if you could bring this again into consideration between the maintainers if it is possible to approve this feature before 3.X? Especially because there is no clear release date for 3.X and because it sounds like that it will not happen in the next month. If this is possible, I would go for a PR to help here. I would like it to improve multiple parsers to finetune the behavior based on different usecases.

[manuel-sommer]

@mtesauro, Just a friendly reminder if I can start implementing this feature?

[manuel-sommer]

another use case: #12079
May I submit a PR here @mtesauro ?

[Maffooch]

Hi @manuel-sommer I was initially intrigued by your idea, and imagined a bunch of neat filtering rules that could be leveraged by a communication channel with the parsers. That's when it hit me - this is an open door that we cannot walk back through. I believe this will lead to many functionalities for different parsers over time that the project will have to own and maintain forever onwards.

I have learned a lot from DefectDojo over the years, and one of the most valuable lessons is that additional customization often comes as the expense of ease of maintenance and longevity. This lesson has been so impactful for both @mtesauro and I in the open source space that we have unofficially picked up a mantra: "Saying No is just for today, but a Yes is forever"

For that reason, we must say no to this idea today

[manuel-sommer]

Hi @Maffooch ,
as this issue was closed, would you accept a PR for an API call regarding GDPR? This could be done as a boolean value enabling GDPR or not for parsers. This setting could also be used in other scanners like https://github.com/newrelic/rusty-hog or #12079. I would be open to submit a PR