trivy --ignore-unfixed and .trivyignore
trivy --ignore-unfixed drops vulnerabilities that have no released fix, and a .trivyignore file suppresses specific CVE IDs.
Not every CVE is actionable today. --ignore-unfixed keeps the gate focused on what you can patch, while .trivyignore lets you accept a reviewed risk with an audit trail.
What it does
--ignore-unfixed removes any vulnerability whose package has no fixed version available, so the report and the exit code only reflect fixable issues. A .trivyignore file lists CVE IDs (one per line) that Trivy will exclude from results, optionally with an expiry date.
Common usage
trivy image --ignore-unfixed --severity HIGH,CRITICAL myorg/app:ci
# .trivyignore in the repo root
cat .trivyignore
# CVE-2023-12345
# CVE-2024-0001 exp:2026-12-31
trivy image --ignorefile .trivyignore myorg/app:ciOptions
| Flag | What it does |
|---|---|
| --ignore-unfixed | Exclude CVEs that have no fixed version |
| --ignorefile <file> | Use a specific ignore file (default .trivyignore) |
| exp:<date> | Per-line expiry in .trivyignore, after which it re-appears |
| --exit-code <n> | Combine with the above to gate only on what remains |
In CI
Commit .trivyignore so suppressions are reviewed in pull requests, and add an exp: date to each entry so accepted risks resurface for re-review instead of being forgotten. Use --ignore-unfixed on the gating step so the build is not blocked by unfixable CVEs.
Common errors in CI
A CVE you expected to be suppressed still failing the build usually means the .trivyignore is not in the working directory Trivy runs from; pass --ignorefile with an explicit path. An expired exp: line silently stops suppressing, which is by design. Note that a malformed line is ignored, so a typo in a CVE ID quietly does nothing.