Current Behavior
We currently only create findings whenever an analyzer first identifies them, but we never remove them.
This is unfortunate because:
- Analyzers might report a false positive. When the analyzer and / or its data source is fixed, the finding that was erroneously raised remains. Users have to manually suppress it.
- Users may disable analyzers that turned out to be too noisy. The findings that were previously raised by those analyzers remain, again requiring manual suppression.
- Users may modify a component such that it no longer applies to a vulnerability. The findings previously raised against it remain.
Proposed Behavior
- A finding that is no longer reported by any analyzer should be automatically suppressed.
- The auto-suppression must be recorded in the finding's audit trail. We can't have findings disappear out of nowhere.
- The auto-suppression must be automatically reversed when analyzers start reporting the finding again.
- The auto-reverse must not happen for findings that were suppressed via user action.
- The auto-suppressed status must be voided when an analysis is modified manually.
When implementing this, the following must be considered:
- We currently only record the first analyzer that reports a finding (via
FindingAttribution).
- To implement this feature, we need to track multiple.
- This also has implications for the UI, and REST endpoints.
- Auto-suppression will need to be tracked in
Analysis.
- There must be a differentiation between an analyzer failing, and it not reporting a finding anymore.
Checklist
Current Behavior
We currently only create findings whenever an analyzer first identifies them, but we never remove them.
This is unfortunate because:
Proposed Behavior
When implementing this, the following must be considered:
FindingAttribution).Analysis.Checklist