Understanding and Checking Trivy Status Values
Published: September 18, 2026
Introduction
Trivy vulnerability scans report findings both with and without available
fixes. When no fix is available, a deferred fix and a decision not to fix
require different follow-up. The Status field helps distinguish them.
Status: fixed does not mean remediation of the scanned image is complete.
It indicates that a fix is available for the reported vulnerability.
The installed and fixed versions are recorded in separate fields.
This article covers the following:
- Status values and how they differ from
FixedVersion. - Reading
fixedandfix_deferredin actual scan results. - Differences between data sources and the findings excluded by filters.
- What to check when deciding on remediation.
For scanning commands and the overall JSON structure, see Trivy Basics and How to Read Scan Results.
Status and FixedVersion
Vulnerability findings appear in Results[].Vulnerabilities[] in JSON.
The following fields describe package versions, remediation status,
and the source of the finding.
| Field | Meaning |
|---|---|
InstalledVersion |
Package version present in the scanned artifact |
FixedVersion |
Fix version recorded in the vulnerability information |
Status |
Vulnerability disposition on the target platform |
DataSource |
Source of the advisory used for detection |
A finding can have Status: fixed while the scanned artifact still
contains a version without the fix. Here, fixed means a fix is
available, not that it has been applied to the scanned artifact.3
Status values
The main remediation states defined by Trivy are listed below. Available states vary by OS and data source.1
| Status | Meaning |
|---|---|
fixed |
A fix is available on the target platform |
affected |
The package is affected, with no fix released yet |
fix_deferred |
The package is affected and the fix is postponed |
will_not_fix |
The package is affected, with no current plan to fix it |
end_of_life |
The impacted component is present, but applicability has not been analyzed because of support scope or related constraints |
Trivy also defines unknown, not_affected, and under_investigation
as Status values. These three values do not appear in the vulnerability
list of an ordinary scan report.21
Examples from a scan
The following excerpts come from a scan of the image ID for nginx:1.27,
made with Trivy 0.71.2 on September 12, 2026. The detected OS was Debian
12.11, and both records identify Debian Security Tracker as their
DataSource. These are saved results; current advisory states and new
scans may differ.4
A fixed finding
{
"VulnerabilityID": "CVE-2025-10148",
"PkgName": "curl",
"InstalledVersion": "7.88.1-10+deb12u12",
"FixedVersion": "7.88.1-10+deb12u15",
"Status": "fixed"
}
The scanned artifact contains 7.88.1-10+deb12u12, while
7.88.1-10+deb12u15 is recorded as the fixed version. The finding
identifies an update target; it does not establish that the update
has been applied or the container recreated.
A deferred fix
{
"VulnerabilityID": "CVE-2024-38949",
"PkgName": "libde265-0",
"InstalledVersion": "1.0.11-1+deb12u2",
"Status": "fix_deferred"
}
This record has no FixedVersion and records that the fix is deferred.
Grouping findings solely by whether FixedVersion is present would put
this together with affected and will_not_fix, losing the distinction.
fix_deferred is not a committed delivery date. Red Hat, for example,
explains that a future fix is not guaranteed for this state. When waiting
for a fix, check the relevant source for its reasons and progress.5
Where to check the fix policy
To interpret an OS package's Status, check the vulnerability information from the OS distributing that package. Trivy matches packages against vulnerability advisories provided by the OS vendor. For example, it uses Debian advisories for Debian packages.6
The will_not_fix status on a Debian 12 package describes the fix
policy for that package in Debian 12. It does not mean that a fix is
unavailable from the software's developer or in another OS release.7
When considering whether to wait for a fix or move to another release,
check the finding's DataSource. Look up the vulnerability ID and target
OS release in that source to find the reason for the decision and which
releases offer a fix.
Inspecting and filtering Status
These command examples use Trivy. Replace <image> with the
image name or image ID to inspect. First, save the scan results in JSON
format without filtering by Status.
Use --ignore-unfixed to show findings with available fixes, or
--ignore-status to exclude specific states.8
trivy image --scanners vuln --ignore-unfixed '<image>'
trivy image --scanners vuln --ignore-status will_not_fix '<image>'
The first command selects findings with fixes; the second excludes
will_not_fix. If both options are supplied, Trivy 0.71.2 gives precedence
to --ignore-status and ignores --ignore-unfixed.8
These filters also affect JSON output.9
Also check exclusion rules in configuration files, environment variables,
and .trivyignore.
What to check for each Status
Status helps organize what to check next.
| Status | What to check next |
|---|---|
fixed |
Check FixedVersion and the target release, then consider updating the package or base image |
affected or fix_deferred |
Track the advisory and consider mitigations or disabling affected functionality while awaiting a fix |
will_not_fix |
Check the reason and consider mitigations or moving to another release or package |
end_of_life |
Check the component and support scope, then consider moving to a supported configuration |
| Missing or unrecognized value | Preserve the original value and check the source and the Trivy version's behavior |
Status alone does not determine remediation order. Issues without fixes may still require action; consider severity, exploitation information, and exposure alongside availability of a fix. For exploitation information, see KEV Catalog Basics and Usage and EPSS Basics and How to Check Scores.
Summary
Status describes the vulnerability's disposition on the target platform,
while FixedVersion identifies the fix version. A fixed status means
a fix is available, not that it has been applied to the scanned artifact.
Read Status alongside InstalledVersion, FixedVersion, and the data
source. When no fix is available, distinctions such as affected,
fix_deferred, and will_not_fix help explain the distributor's response.
References
-
Excerpts from the saved Runtime Discovery report
1-root-30-300-p0-r2/trivy_all.json(September 12, 2026; Trivy 0.71.2). See the public development log for targets and collection procedure. ↩ -
Red Hat: CVE-page explanations of remediation states and support scope ↩
KestreLynx is open-source software that regularly scans images used by running Docker and Kubernetes containers with Trivy and sends changes since the last scan and priorities based on severity, CISA KEV, and EPSS to Slack or a webhook. For Docker and Compose, remediation plans and pull requests (experimental) support remediation from comparing update candidates to creating GitHub pull requests, with both features disabled by default. Users handle merging, rebuilding, and deployment.