Trivy provides various methods for filtering the results.
Similar to the functionality of filtering results, you can also limit the sub-targets for each scanner.
For information on these settings, please refer to the scanner-specific documentation (vulnerability , misconfiguration, etc.).
Trivy supports the following vulnerability statuses:
unknown
not_affected: this package is not affected by this vulnerability on this platform
affected: this package is affected by this vulnerability on this platform, but there is no patch released yet
fixed: this vulnerability is fixed on this platform
under_investigation: it is currently unknown whether or not this vulnerability affects this package on this platform, and it is under investigation
will_not_fix: this package is affected by this vulnerability on this platform, but there is currently no intention to fix it (this would primarily be for flaws that are of Low or Moderate impact that pose no significant risk to customers)
fix_deferred: this package is affected by this vulnerability on this platform, and may be fixed in the future
end_of_life: this package has been identified to contain the impacted component, but analysis to determine whether it is affected or not by this vulnerability was not performed
Note that vulnerabilities with the unknown, not_affected or under_investigation status are not detected.
These are only defined for comprehensiveness, and you will not have the opportunity to specify these statuses.
Some statuses are supported in limited distributions.
OS
Fixed
Affected
Under Investigation
Will Not Fix
Fix Deferred
End of Life
Debian
✓
✓
✓
✓
RHEL
✓
✓
✓
✓
✓
✓
Other OSes
✓
✓
To ignore vulnerabilities with specific statuses, use the --ignore-status <list_of_statuses> option.
To skip all unfixed vulnerabilities, you can use the --ignore-unfixed flag .
It is a shorthand of --ignore-status affected,will_not_fix,fix_deferred,end_of_life.
It displays "fixed" vulnerabilities only.
This feature might change without preserving backwards compatibility.
When the extension of the specified ignore file is either .yml or .yaml, Trivy will load the file as YAML.
For the .trivyignore.yaml file, you can set ignored IDs separately for vulnerabilities, misconfigurations, secrets, or licenses1.
Available fields:
Field
Required
Type
Description
id
✓
string
The identifier of the vulnerability, misconfiguration, secret, or license1.
The list of file paths to ignore. If paths is not set, the ignore finding is applied to all files.
purls
string array
The list of PURLs to ignore packages. If purls is not set, the ignore finding is applied to all packages. This field is currently available only for vulnerabilities.
expired_at
date (yyyy-mm-dd)
The expiration date of the ignore finding. If expired_at is not set, the ignore finding is always valid.
statement
string
The reason for ignoring the finding. (This field is not used for filtering.)
$cat.trivyignore.yaml
vulnerabilities:
-id:CVE-2022-40897
paths:
-"usr/local/lib/python3.9/site-packages/setuptools-58.1.0.dist-info/METADATA"statement:Accepttherisk
-id:CVE-2023-2650
-id:CVE-2023-3446
-id:CVE-2023-3817
purls:
-"pkg:deb/debian/libssl1.1"-id:CVE-2023-29491
expired_at:2023-09-01
misconfigurations:
-id:AVD-DS-0001
-id:AVD-DS-0002
paths:
-"docs/Dockerfile"statement:Theimageneedsrootprivileges
secrets:
-id:aws-access-key-id
-id:aws-secret-access-key
paths:
-"foo/bar/aws.secret"
licenses:
-id:GPL-3.0# License name is used as IDpaths:
-"usr/share/gcc/python/libstdcxx/v6/__init__.py"
Since this feature is experimental, you must explicitly specify the YAML file path using the --ignorefile flag.
Once this functionality is stable, the YAML file will be loaded automatically.
This feature might change without preserving backwards compatibility.
Rego is a policy language that allows you to express decision logic in a concise syntax.
Rego is part of the popular Open Policy Agent (OPA) CNCF project.
For advanced filtering, Trivy allows you to use Rego language to filter vulnerabilities.
Use the --ignore-policy flag which takes a path to a Rego file that defines the filtering policy.
The Rego package name must be trivy and it must include a "rule" named ignore which determines if each individual scan result should be excluded (ignore=true) or not (ignore=false).
The input for the evaluation is each DetectedVulnerability and DetectedMisconfiguration.
A practical way to observe the filtering policy input in your case, is to run a scan with the --format json option and look at the resulting structure:
trivyimage-fjsoncentos:7
...
"Results":[{"Target":"centos:7 (centos 7.9.2009)",
"Class":"os-pkgs",
"Type":"centos",
"Vulnerabilities":[{"VulnerabilityID":"CVE-2015-5186",
"PkgID":"audit-libs@2.8.5-4.el7.x86_64",
"PkgName":"audit-libs",
"InstalledVersion":"2.8.5-4.el7",
"Layer":{"Digest":"sha256:2d473b07cdd5f0912cd6f1a703352c82b512407db6b05b43f2553732b55df3bc",
"DiffID":"sha256:174f5685490326fc0a1c0f5570b8663732189b327007e47ff13d2ca59673db02"},
"SeveritySource":"redhat",
"PrimaryURL":"https://avd.aquasec.com/nvd/cve-2015-5186",
"Title":"log terminal emulator escape sequences handling",
"Description":"Audit before 2.4.4 in Linux does not sanitize escape characters in filenames.",
"Severity":"MEDIUM",
"CweIDs":["CWE-20"],
...
Each individual Vulnerability, Misconfiguration, License and Secret (under Results.Vulnerabilities, Results.Misconfigurations,
Results.Licenses, Results.Secrets) is evaluated for exclusion or inclusion by the ignore rule.
The following is a Rego ignore policy that filters out every vulnerability with a specific CWE ID (as seen in the JSON example above):
For more advanced use cases, there is a built-in Rego library with helper functions that you can import into your policy using: import data.lib.trivy.
More info about the helper functions are in the library here.
You can create a whitelist of checks using Rego, see the detailed example. Additional examples are available here.
license name is used as id for .trivyignore.yaml files. ↩↩
This doesn't work for os package licenses (e.g. apk, dpkg, rpm). For projects which manage dependencies through a dependency file (e.g. go.mod, yarn.lock) path should point to that particular file. ↩