As a new user of Trivy, coming from tfsec, Trivy scans and reports for potential findings in my repositories that tfsec never looked for.
To support adding Trivy to existing repository CI systems, it is useful to temporarily ignore or filter some findings.
In existing Terraform use cases, inline filtering works fine. However, Trivy supports scanning some configuration formats that will be non-trivial to add inline comment-filtering to (e.g. Dockerfiles #2961)
But, this comes with a huge caveat: the .trivyignore file has repo-wide scope.
In case a new vulnerability of a known-and-intentionally-ignored type (for example, risks in a local dev VM aren't the same as production, but the code for both might share a repository), Trivy might miss a new finding.
Request:
Rather than wait for perfect inline filtering in every possible configuration format, we could enable per-file, per-path, or per-pattern filtering of findings in files before making any output or reporing.
For example, I could imagine a today-simple .trivyignore file like
CVE-123
CVE-456
AVD-DS-0002
becoming a more powerful and improved .trivyignore.yaml file:
Context:
.trivyignore
file (https://aquasecurity.github.io/trivy/v0.39/docs/vulnerability/examples/filter/#by-vulnerability-ids).trivyignore
file has repo-wide scope.Request:
Rather than wait for perfect inline filtering in every possible configuration format, we could enable per-file, per-path, or per-pattern filtering of findings in files before making any output or reporing.
For example, I could imagine a today-simple
.trivyignore
file likebecoming a more powerful and improved
.trivyignore.yaml
file: