Add `--ignore-unlikely-affected` flag to filter vulnerabilities in packages unlikely to affect the artifact

[knqyf263]

Description

Add a new --ignore-unlikely-affected flag that filters out vulnerabilities in packages that are unlikely to affect the artifact in its operational context.

Motivation

There are packages that exist in artifacts but are unlikely to be affected by their vulnerabilities in practice. For example, in container images, the kernel is shared with the host, so vulnerabilities in kernel-related packages are unlikely to affect the container image itself.

However, we cannot say with certainty that these packages are never affected. For instance, the "linux" package includes tools like "bpftool" that could potentially be used. Therefore, always filtering these packages could lead to false negatives.

This flag allows users to filter out such vulnerabilities at their own discretion, while still being able to view the filtered vulnerabilities using the --show-suppressed flag for transparency.

Proposed Solution

Implement a --ignore-unlikely-affected flag that filters out vulnerabilities in these types of packages.

Filtering Rules

1. Kernel packages (only in container images):

   • Packages with source name linux or linux-* (Debian/Ubuntu/Alpine)
   • Packages with source name starting with kernel (RHEL/CentOS/Fedora/SUSE/Amazon Linux)
   • Only filtered in container images, not in filesystem or VM scans

2. Non-runtime packages: Packages that don't contribute to runtime functionality (all artifact types):

   • Documentation packages: -doc, -docs suffixes
   • Debug symbol packages: -dbg, -debug suffixes
   • License packages: -license suffix

Example Usage

# Filter unlikely affected packages
$ trivy image --ignore-unlikely-affected python:3.8.5

# See which vulnerabilities were filtered
$ trivy image --ignore-unlikely-affected --show-suppressed python:3.8.5

Example Output with --show-suppressed

...
Suppressed Vulnerabilities (Total: 2)

┌────────────────┬───────────────┬──────────┬─────────┬────────────────────────────────────┬────────────────────────────┐
│    Library     │ Vulnerability │ Severity │ Status  │             Statement              │           Source           │
├────────────────┼───────────────┼──────────┼─────────┼────────────────────────────────────┼────────────────────────────┤
│ linux-libc-dev │ CVE-2023-6270 │ HIGH     │ ignored │ Package is unlikely to be affected │ --ignore-unlikely-affected │
│                ├───────────────┤          │         │                                    │                            │
│                │ CVE-2021-3640 │          │         │                                    │                            │
└────────────────┴───────────────┴──────────┴─────────┴────────────────────────────────────┴────────────────────────────┘

Implementation Details

• The filtering is context-aware - kernel packages are only filtered in container images
• Filtered vulnerabilities are tracked in ModifiedFindings with the reason "Package is unlikely to be affected"
• The flag is available for vulnerability scanning only (not misconfigurations, secrets, or licenses)
• Can be combined with other filtering options like --severity, --ignore-unfixed, etc.

Benefits

• Reduces noise in vulnerability scan results
• Helps users focus on vulnerabilities that actually matter
• Improves the signal-to-noise ratio for security teams
• Context-aware filtering ensures accuracy (e.g., kernel packages are important in VM scans)

[knqyf263]

@itaysk @DmitriyLewen What do you think? Suppressing vulnerabilities is possible with OPA or VEX, but since users often want to apply this filter, we intend to provide convenient flags on our side.

• Add option to ignore kernel vulnerabilities #4816
• kernel-headers shows up in report with trivy image scan #8132
• Trivy found Vulnerabilities in Linux Kernel #7302
• trivy detecting vulnerabilities in linux header packages? #6562
• False postive on Debian images #5993
• Kernel packages are not detected in CentOS images #2271

I thought it was a good idea, so I created an issue, but if it seems like more discussion is needed, I’ll move it back to a discussion.

[DmitriyLewen]

Looks good to me.

Just an idea:
We already have many different flags, and I don't want to use flags with single (logical) value.

What if we add a status for these packages or a suffix (e.g. will-not-fixed (unlikely-affected))

Then users will be able to filter by status.
On the one hand, the user has to write down all the other statuses themselves, but on the other hand, this is also a special case.

[knqyf263]

Do you mean this status? This represents the status of the patch and is different from the attributes of the package. I also tried to fit it into one of the existing flags, but I couldn't find any that matched the current ones.
https://trivy.dev/latest/docs/configuration/filtering/#by-status

[itaysk]

This is great, but might overlap with our non-oss feature set (prioritization/automatic suppression of vulnerabilities).
As for the UX, I have two thoughts:

1. the action is called "ignore" while the category is called "suppressed" (this reflects in flag names and UI). I guess this is fine since "ignore" is prevalent and we already use it for other flags. Do we say that ignores are a subset of suppressions? if so, should we update this model?
2. I suppose we will have more forms of automatic suppressions in the future (see my comment about non-oss above), so just need to consider that.

[knqyf263]

Do we say that ignores are a subset of suppressions? if so, should we update this model?

Yes, currently "ignore" is one of the methods under the broader category of "suppression." The "ignore" action is used when a vulnerability may have an impact, but the user has consciously decided to take responsibility and ignore it. That’s why we use "--ignore" in this case and in Rego. (The --ignore-unfixed flag was added in v0.0.1, at a time when there wasn’t really a structured flag system, so if it’s not appropriate, I think it could be changed to something like --filter-unfixed.)

"Suppression," on the other hand, is a broader concept than just "ignore." That’s because, in the context of VEX, it’s not always about ignoring something — there may be cases where something like call graph analysis has confirmed that the vulnerability is not actually affected (i.e., "not_affected"). Strictly speaking, it might make sense to separate "ignore" and VEX, but I felt that introducing too many categories would make things overly complex, so for now, I've grouped them under "suppression."

2. I suppose we will have more forms of automatic suppressions in the future (see my comment about non-oss above), so just need to consider that.

I made the suggestion considering the large number of requests from the community and the simplicity of the feature, but if it's going to be added as a non-OSS feature, I'm fine with withdrawing it.

[maxammann]

This is a bit strange, just today we got swamped with CVEs in linux-libc-dev. Is anyone aware of an upstream change that introduces those CVEs now? Is a trivy data source including way more CVEs from the kernel now?

[maxammann]

I wonder what VEX could do here for filtering. For now I added this Rego filter:

package trivy

default ignore = false

ignore {
    input.PkgName == "linux-libc-dev"
}