What is the preferred Workflow to whitelist CVEs?

[PowerOfCreation]

I have spent some time reading the Trivy Operator documentation as well as the Helm Chart and the Trivy documentation. So far I couldn't find an official recommended way how I can whitelist CVEs on a per image base for the Trivy Operator. In the Trivy Operator documentation I didn't find anything about whitelisting CVEs at all, except this old discussion #489 and I'm hoping something has changed since then and I'm also interested in more general guidelines on how to deal with found CVEs, which is why I'm opening this new discussion.

Only in the values.yaml of the Helm chart I was able to find ignoreFile and ignorePolicy. The ignoreFile does only support whitelisting for the entire cluster. It also seems to be different from the .trivyignore file which can be used with the Trivy cli, as it's not a multiline string but just a array of strings meaning nesting and using functionality like in the trivyignore.yaml doesn't seem to be possible at all.

Now that leaves me with the ignorePolicy which can be set on a per namespace level and with Rego. Sadly I wasn't able to find out what exactly I can use in the input.. input.target sounds sounds right but in all my VulnerabilityReport CRDs vulnerabilities.target is an empty string.

Now I'm starting to think I'm looking in the wrong place because it seems to me that it's a very common pattern that I have a new CVE in my cluster and after evaluation I might decide that it doesn't affect me and I want to ignore it but only in the places where I have carefully evaluated whether the CVEs is relevant or not, not for the entire cluster. Ignoring for the entire cluster sounds dangerous to me.

I found that probably I could also put a .trivyignore file in each image itself, but this doesn't feel right either, as I don't have control over all images that I'm using in my cluster and would also mean I have to redeploy an image just to change my whitelisted CVEs.

Due the broken windows theory it feels like to me that ignoring/whitelisting CVEs should be a proper documented and streamlined process, but perhaps I misunderstand Trivy's role here and the ignoring part should happen at a later stage like in a Prometheus expression? Would be great if someone could point me in the right direction how to properly deal with the found vulnerabilities!

Thank you for your input!

[itaysk]

this doc explains trivy ignore file and rego ignore: https://trivy.dev/latest/docs/configuration/filtering/
you are right in that trivy ignore can't be scoped to images. that's becuase trivy CLI (not trivy-operator) is always scanning one given image.
you should be able to do what you're after with rego. as for your question what the input should look like, the document I linked says "The input for the evaluation is each DetectedVulnerability and DetectedMisconfiguration". Basically what you see when you scan with -f json

[PowerOfCreation]

Thank you for your quick response, @itaysk.

I noticed that the DetectedVulnerability type includes fields like PkgID, PkgName, and PkgPath. However, the VulnerabilityReport CRD doesn't expose these fields—instead, it provides a packagePURL, which seems related but doesn't appear to map directly to the Pkg fields from the CLI output.

Does this mean that, in order to determine what to ignore using a Rego policy, one would first need to manually run a Trivy CLI scan to retrieve the PkgName or related values? Ideally, I’d like to implement a GitOps-compatible process where it's possible to configure exclusions purely based on the contents of the VulnerabilityReport CRD, without requiring a separate scan.

Regarding scoping an ignore rule to a specific image: I haven’t found a field in the DetectedVulnerability that would allow this. Ignoring by PkgName would be more targeted than doing it cluster-wide or for the entire namespace, but it could still result in ignoring the CVE in more places than intended.

Would appreciate any clarification or guidance here.

[pacoguzman]

I have the same use case, as I explained here on trivy repository.

Which I've found too, it's that trivy-operator does not support loading a YAML file to specify vulnerability filtering, I know this is experimental but would be great to allow to be able to specify which file path to set as the file will be end load by trivy, I presume.

Besides, in our case we want to ignore any vulnerability under a specific path, but we need to specify each one of them instead. This is because id is required, maybe we can use a regexp or wildcare or even setting up as optional.