the agent's suppression file wasn't honored after a trivy version upgrade - ignored CVEs came back as fresh alerts
Restores trivy suppression handling after a version upgrade by verifying which ignore file the new version reads, where it looks for it, and whether entries still match. Use it when previously suppressed CVEs return as fresh findings right after a trivy upgrade. Key trigger: ignore file unchanged, trivy version changed, suppressed CVEs back in the report.
TL;DR: The upgrade changed how trivy finds or parses your ignore file - the flag name, the default filename, or the working directory it reads from. Find the new version's ignore-file flag, point it at your file explicitly, verify the entries match the CVE IDs in the fresh alerts, and pin the invocation so the next upgrade cannot silently drop it again.
the agent's suppression file wasn't honored after a trivy version upgrade - ignored CVEs came back as fresh alertsSteps
Check the new trivy version's help output for the ignore-file flag: its exact name, its default filename, and which working directory it resolves relative paths from. Expected: you learn exactly which file the new version reads and from where.
Confirm the file exists where the new version looks - agents often run the scan from a different working directory than the one holding the ignore file. Expected: either the file is found, or you have located the path mismatch.
Open the ignore file and check the entries: one identifier per line, plain CVE IDs, no byte-order marks or trailing whitespace, and the IDs match the CVEs in the fresh alerts exactly. Expected: the entries are clean and match what the scanner reports.
Re-run the scan with the ignore file passed explicitly via the flag (not relying on auto-discovery) and compare finding counts. Expected: the suppressed CVEs disappear from the report.
Pin the explicit flag in your pipeline config and add a post-upgrade check: after any trivy version bump, run a canary scan and assert the suppressed count is unchanged. Expected: the next upgrade is verified before it can flood the backlog.
Use this when
- Suppressed CVEs return as fresh findings after a trivy upgrade
- The ignore file worked yesterday and nothing in it changed
- The agent runs trivy from a different directory than your local runs
- You are unsure which ignore-file flag the installed version supports
Not for this skill when
- Suppressions never worked (not a regression) - check the file format and flag from scratch
- The "fresh" findings are new CVE IDs you never suppressed - those are real new findings
- You are using a different scanner (grype, snyk) - each has its own suppression mechanism
Variant phrasings
- trivy ignore file not working after upgrade
- trivyignore ignored CVEs came back
- trivy suppression file not honored in CI
Why it happens
Trivy resolves the ignore file relative to the working directory, and its flag names and defaults have shifted across versions. An agent pipeline that relied on auto-discovery ("it just found the ignore file") breaks silently when any of three things change: the flag, the default filename, or the directory the scan runs from. Nothing errors - the file is simply never read, so every suppressed CVE reports as new.
Edge cases
- Entries for CVEs fixed long ago are harmless but hide rot - audit the file yearly.
- An ignore file committed for one repo layout breaks when the agent scans a subdirectory - pass the flag with an absolute path.
- Suppression files are also documentation: note who suppressed what and why, or the next owner deletes entries they do not understand.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_Mvv7AktblYOfxFy7fGe7Kg