Improve handling for ignored vulnerabilities that are no longer a problem

[rethab]

The .trivyignore file gets bigger and bigger as new vulnerabilities are added. From what I understand, the best way to know when a line could be removed is to run the scan again and see if it shows up again.

It would be nice if trivy provided better support for this. This could be done either by:

• log a warning for any vulnerability that is ignored but not present anymore
• add a flag to fail the scan if a vulnerability is ignored but not present anymore

This would greatly help with maintaining the .trivyignore file.

If you accept this request, I'm happy to give it a try. Personally, I'd prefer option 2, although both options could be implemented.

[davidteal]

Agreed, this would be very useful

[afdesk]

@rethab @davidteal thanks for your interest!

Trivy has several ways to manage skipped vulnerabilities.
at first, a few releases ago there was added expiration dates in .trivyignore: https://aquasecurity.github.io/trivy/v0.29.2/docs/vulnerability/examples/filter/#by-vulnerability-ids

also you can use different .trivyignore files for different use cases:

$ trivy image --ignorefile skip-cve1 alpine:latest
$ trivy image --ignorefile skip-cve2 alpine:latest
...

don't these options cover your cases? thanks

[rethab]

Hi @afdesk thanks for your comment. This certainly helps! :)

However I still think flagging ignored vulnerabilities that aren't present anymore would be very helpful just to keep this file clean.

[3XC1T3D]

Yep, we have the same issue/problem 😅 would be nice flagging ignored vulnerabilities that aren't present anymore. To have a clean ignore list.

[AnaisUrlichs]

Hmm from a user perspective, I would actually prefer the first option that a scan would just report the vulnerability IDs (maybe with the AVD) that are present in the .ignore file but are not detected in the scan anymore

log a warning for any vulnerability that is ignored but not present anymore

Otherwise, it seems like a task that is manual and separate from the routine scan

[3XC1T3D]

Yep, your right. It would be the better choice. 👍

[3XC1T3D]

Is there any progress in this idea in the future? 😅

[asmundo]

I do like the expiration date! And will use it. In addition from a CI perspective I would like to force an up to date .trivyignore file. So I would like something like:

--ignore-strict Exit non 0 if exceptions in ignore file that do not match an existing issue in the scanned code

The output should list what should be removed from .trivyignore.