Expiry date for ignore rules

[rmkanda]

What would you like to be added: Adding an optional expiry date for the ignore rules

Why is this needed: For example, there is a vulnerability on a package and it is valid. but the team needs a week to fix it. In those situations, we can have an expiry date for the ignore rules - so that it alerts again if the issue is not fixed.

Example

ignore:
   - vulnerability: CVE-2008-4318
      expiry: 2021-12-30 01:00:00 UTC

[ghost]

This would help me migrate from Trivy and OWASP Dependency Check to grype (both of them support CVE expiry rules).

[kzantow]

#1148 mentioned a slightly different naming suggestion:

ignore:
  # This is the full set of supported rule fields:
  - vulnerability: CVE-2008-4318
    fix-state: unknown
    valid-until: 03-03-2023      <---- new field for time-limit
    package:
      name: libcurl
      version: 1.5.1
      type: npm

[Atharex]

Still interested in this one. Any updates?

[dkahn22]

Still interested in this one as well. Are there any updates?

[wagoodman]

Today we're more focused on improving match quality rather than increasing the CLI/config surface area to add more features. Additionally we're hesitant to add this feature because it seems to nudge grype further into evaluation and remediation workflow than it does as as a pure scanning tool that produces data. Today we have similar filtering capabilities, but the time element is really relative to a user attempting to "snooze" a remediation rather than declare that a finding is not accurate relative to the project the config is captured in.

I think the question that arises out of this is: should grype evaluate results against a policy? If so, then this kind of feature makes sense. If not, then this is the kind of feature that we should keep out of grype and into something else that is downstream of grype.