The frustration with container vulnerability scanner false positives is not unfounded. Teams that scan their images, investigate the top Critical findings, and discover that half of them are not applicable to their configuration have a legitimate grievance. Security tooling that cries wolf erodes trust.
Understanding why false positives occur in container scanning — and the distinction between genuine false positives and the larger category of technically-correct-but-irrelevant findings — points toward the real fix.
Categories of Inaccurate Container Scan Findings
True false positives: The scanner incorrectly identifies a CVE as affecting a package that is not actually affected. This happens when:
- Package version detection is imprecise (a version string that is a substring of another version)
- The CVE affects only specific configurations that the package is not using
- The package vendor backported a fix but kept the version number, while the scanner’s database only records fixed versions for the upstream release
True false positives require suppression configuration to remove from future scan output. They are annoying but manageable.
Technically correct, contextually irrelevant findings: The CVE is real. The package is really installed. The version is really affected. But the package is never executed during the application’s operation, so the CVE represents zero practical exploitation risk.
This is not a false positive by any strict definition. The CVE is accurately detected. But from the security engineer’s perspective, a finding in a package the application does not use is indistinguishable from a false positive in its actionability: it cannot be exploited, and the right response is to remove the package, not to upgrade it.
This category constitutes the majority of “false positives” that teams experience. It is not a scanner accuracy problem — it is a scanner relevance problem.
Vendor-disputed CVEs: Some CVEs are disputed by the package vendor, who asserts that the described vulnerability is not present in their code or is not exploitable in any realistic configuration. These appear in scanner output until the CVE is withdrawn from the database. They look like real findings but have no remediation path and no practical risk.
Why the Relevance Problem Is Larger Than the Accuracy Problem?
In a typical container image:
- True false positives: 5-10% of findings
- Technically correct but irrelevant (unused packages): 60-80% of findings
- Disputed or no-fix CVEs: 5-15% of findings
- Genuine actionable findings: 10-20% of findings
A security team focused on reducing false positives through suppression management is addressing 5-10% of the noise. A team focused on removing unused packages is addressing 60-80% of the noise.
The relevance problem dwarfs the accuracy problem, but most scanner configuration guidance focuses on suppression rules for known false positives rather than the structural approach that eliminates the larger category.
Using Runtime Data to Eliminate Irrelevant Findings
The container vulnerability scanner approach that addresses relevance, not just accuracy:
Step 1: Profile the application during representative testing
Run the container under profiling instrumentation while the test suite exercises representative functionality. Capture which packages are imported, which functions are called, which shared libraries are loaded.
Step 2: Classify packages by execution evidence
Every package in the container image falls into one of two categories:
- Used: execution evidence observed during profiling (imported modules, called functions, loaded libraries)
- Unused: no execution evidence during profiling
Step 3: Remove unused packages and rescan
Remove packages in the “unused” category from the image. Rescan the resulting image.
The rescan finding list contains only CVEs in packages that the application demonstrably uses. Every finding in the list is in code that executes during representative operation — which means each finding is worth investigating.
The container CVE count drops by 60-80% through this process. The findings that remain are the 10-20% that represent genuine risk.
Frequently Asked Questions
Why do container vulnerability scanners generate so many false positives?
Container vulnerability scanners produce high false-positive rates because they report every CVE in every installed package, regardless of whether that package is ever executed. In a typical container image, 60–80% of findings are technically accurate CVEs in packages the application never uses — not true false positives, but findings with zero practical exploitation risk. True false positives from version detection errors or vendor backports represent only 5–10% of the noise.
How do you handle false positives in vulnerability scanning results?
The most effective approach to container vulnerability scanner false positives is structural, not configurational: profile the application during representative testing to identify which packages actually execute, then remove unused packages entirely. This eliminates 60–80% of findings in one step. For remaining false positives in used packages, establish a disciplined suppression workflow that requires individual justification, an expiration date, and a reviewer for each suppression.
Which factors cause a vulnerability scanner to show false positives?
The main causes are imprecise package version detection (where a version string matches another unintentionally), vendor backporting (where a fix is applied but the version number is not incremented, while the CVE database only records fixed upstream versions), and CVEs that apply only to specific configurations the package is not using. Vendor-disputed CVEs that remain in the database without a remediation path also appear as findings with no actionable response.
How to get rid of false positives in container scanning?
Remove unused packages through runtime profiling rather than managing suppression rules. Run the container under profiling instrumentation during your test suite, classify each package as used or unused based on execution evidence, and remove the unused set. The container vulnerability scanner finding count drops by 60–80% on rescan, leaving only CVEs in code that the application demonstrably executes. Suppression rules then address only the small remaining set of genuine false positives.
Suppression Management for Remaining False Positives
After removing unused packages, the remaining findings still require false positive management. The suppression workflow:
Verify before suppressing: Before suppressing a finding, verify that the reported package and version are actually present in the image. Some scanners match CVEs to package names imprecisely; a suppression based on incorrect detection suppresses real findings.
Document suppressions: Each suppression should have a documented justification, an expiration date, and a reviewer. Suppressions that cannot be justified should not be added.
Review suppressions periodically: A CVE that was legitimately suppressed (vendor-disputed, backported fix) may become applicable again if the CVE database updates with new information. Monthly suppression review catches re-activated CVEs before they silently remain suppressed.
Do not suppress without investigation: The instinct to mass-suppress findings to clear the dashboard misses the point. Suppressions that are not individually justified may be hiding real findings. Investigate before suppressing.
The combination of structural noise reduction (removing unused packages) and disciplined suppression management (for genuine false positives in used packages) produces a finding list that security teams can trust. When developers receive findings from this process, they have learned that the findings are worth investigating — which is the foundation of a security program that works.