## Problem As appSec, I want to make sure that vulnerabilities that may no longer be present are filtered out of my views. I also want to make sure the dashboard aligns with the vulnerability report where I will cross reference data, and go deeper into specific vulnerabilities. While auto resolve policies are best to close out irrelevant vulnerabilities, filtering out the 'no longer detected' vulnerabilities can help when that policy is not enabled. ## Scope ### In scope 1. Any vulnerabilities _except_ exposed secrets should be **_automatically removed_** from the dashboard if they have 'No longer detected' activity associated with them. 1. Exposed secrets may still be vulnerable even if they are 'no longer detected' in the code, because they have leaked. 2. For modules that are presenting vulnerability counts from previous dates, the status/activity at that time for that vulnerability should still be honored even if the vulnerability is no longer detected at present day. 1. For example, if a vulnerability was open in June and no longer detected in present day, the vulnerability trends over time should count the vulnerbility as 'open' in June and be filtered out in present day. 2. As a rule, counts for present day should filter out 'no longer detected' and historical counts should factor in the status of the. vulnerability at that day. 3. As previously mentioned in various threads and meetings, if a vulnerability changes status from open-\>no longer detected/closed-\>open, it can remain open across all time points since there are ES limitations. ### Out of scope * n/a ## Designs n/a ## Dependencies * Security Infrastructure ## Functional Requirements ### Page Level Support * [x] Project * [x] Group * [ ] Pipeline \> Security (findings) * [ ] MR Security Widget (findings) * [ ] Security Center * [x] Security Dashboard ### Workflow * [ ] Requires an additional filter on the Vulnerability Report ([docs](https://docs.gitlab.com/development/internal_analytics/internal_event_instrumentation/quick_start/)) * [ ] Requires an addition to the Vulnerability Report export ([docs](https://docs.gitlab.com/user/application_security/vulnerability_report/#exporting)) * [ ] Requires an additional filter on the Dependency List ([docs](https://docs.gitlab.com/user/application_security/dependency_list/)) * [ ] Requires an addition to the Dependency List export ([docs](https://docs.gitlab.com/user/application_security/dependency_list/#export)) * [x] Requires ~documentation ## Non-Functional Requirements ### Product Usage * [ ] Requires new instrumentation ([docs](https://docs.gitlab.com/development/internal_analytics/internal_event_instrumentation/quick_start/)) ### Feature Flag Usage * [ ] This feature should be released behind a feature flag? ([docs](https://handbook.gitlab.com/handbook/product-development/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags)) ### Testing * [x] Requires new E2E test coverage ([docs](https://docs.gitlab.com/development/testing_guide/end_to_end/)) * [ ] Requires extended manual / UAT phase * [ ] Performance testing needed ([testing](https://docs.gitlab.com/ci/testing/load_performance_testing/)) ## Outstanding Questions | Question | Answer | Assignee | Priority | Blocking? | |----------|--------|----------|----------|-----------| | | | | | | ## Resources 1. [Epic Board](Milestone) showing issues across workflow stages. 2. Documentation links 3. Prior work/projects