Is your feature request related to a problem? Please describe
Unfortunately, I noticed that the Trivy parser has been manipulating the finding status since PR trivy: map status field. In particular, the verified status is being altered by the parser. This is now causing various problems for us.
Usually, our users set the verified status manually, and not automatically through a tool.
Furthermore, this new behavior of the Trivy parser results in findings being automatically transferred to JIRA, because some of the findings have the status verified = true.
In addition, we now have a discrepancy with other tools — for example, findings from Anchore Grype do not have a verified = true status, which causes confusion during deduplication.
Describe the solution you'd like
We would like to have the previous behavior back, or at least an option to disable this mapping.
Describe alternatives you've considered
The only alternative that comes to mind at the moment is for us to create our own Trivy parser. Nevertheless, I believe that the current mapping in the Trivy parser does not fit the DefectDojo concept, since other parsers do not perform such mapping and the verified status was likely intended to be set by the user.
Is your feature request related to a problem? Please describe
Unfortunately, I noticed that the Trivy parser has been manipulating the finding status since PR trivy: map status field. In particular, the verified status is being altered by the parser. This is now causing various problems for us.
Usually, our users set the verified status manually, and not automatically through a tool.
Furthermore, this new behavior of the Trivy parser results in findings being automatically transferred to JIRA, because some of the findings have the status verified = true.
In addition, we now have a discrepancy with other tools — for example, findings from Anchore Grype do not have a verified = true status, which causes confusion during deduplication.
Describe the solution you'd like
We would like to have the previous behavior back, or at least an option to disable this mapping.
Describe alternatives you've considered
The only alternative that comes to mind at the moment is for us to create our own Trivy parser. Nevertheless, I believe that the current mapping in the Trivy parser does not fit the DefectDojo concept, since other parsers do not perform such mapping and the verified status was likely intended to be set by the user.