Trivy "--ignore-unfixed" vs .trivyignore confusion in CI
Many base-image CVEs have no upstream fix yet, so you cannot patch them by rebuilding. --ignore-unfixed tells Trivy to report only vulnerabilities that have a fixed version, which stops a gate from blocking on things you cannot act on. It is different from .trivyignore, which suppresses named IDs.
What this error means
The gate fails on CVEs whose FIXED VERSION column is empty, so no base-image bump clears them and the pipeline stays red on unactionable findings.
Total: 5 (HIGH: 4, CRITICAL: 1)
| zlib1g | CVE-2023-YYYY | HIGH | 1.2.13 | (no fix) |
| ... | | | | |
Error: Process completed with exit code 1.Common causes
The gate counts vulnerabilities with no available fix
Without --ignore-unfixed, Trivy reports every matching CVE, including those with no released patch, so the build blocks on findings you cannot remediate.
Confusing --ignore-unfixed with .trivyignore
--ignore-unfixed is a broad flag for all unfixed CVEs; .trivyignore is a targeted allowlist of specific IDs. Reaching for the wrong one leaves the gate misconfigured.
How to fix it
Add --ignore-unfixed to focus on actionable CVEs
Fail only on vulnerabilities that have a fix, so a base bump can clear the gate.
trivy image --ignore-unfixed \
--exit-code 1 --severity HIGH,CRITICAL myimage:latestKeep .trivyignore for reviewed one-off exceptions
When you must allow a fixable CVE temporarily, list it in .trivyignore with a justification and expiry, not a blanket ignore.
# .trivyignore - remove after base bump, review 2026-09-01
CVE-2024-XXXXHow to prevent it
- Use --ignore-unfixed so gates block only on remediable CVEs.
- Reserve .trivyignore for specific, expiring exceptions.
- Track unfixed CVEs so you rescan when upstream patches land.