Reduce False Positives#

When vulnerability scanners report security findings, 50-80% often turn out to be false positives - erroneous alerts that waste security team time and create alert fatigue. To reduce false positives effectively, you need to understand why they occur, combine more accurate data sources, and assess each finding in the context of your actual deployment.

Why False Positives Occur#

Version Matching Errors#

Vulnerability databases may incorrectly specify affected versions. A CVE might state "all versions < 3.0.0" are vulnerable when only 2.9.x contains the flaw. Your version 2.8.1 gets incorrectly flagged.

Backported Patches#

Linux distributions (Debian, Ubuntu, RHEL) backport security fixes to older versions while keeping original version numbers. A system running "OpenSSL 1.0.2k-fips" contains backported patches for CVEs officially fixed in "1.9.5", but scanners see "1.0.2k" and report already-patched vulnerabilities.

Example: Debian patches CVE-2023-12345 in their libssl1.1 package version 1.1.1n-0+deb11u4. Standard scanners only recognize the upstream fix in version 1.1.1p and flag the Debian package as vulnerable - a false positive.

Cross-Ecosystem Confusion#

Package "utils" exists in npm, PyPI, and Maven as completely different software. When CVE-2023-98765 affects Python's "requests-cache", scanners may incorrectly flag the unrelated npm package with the same name.

Unused Code Paths#

A vulnerability deep in your dependency tree may affect code your application never executes. Your app uses web-framework's routing but not its database module - vulnerabilities in database dependencies can't be exploited through your code paths.

This is why DevGuard tracks vulnerabilities per dependency path, not just per (CVE, package) pair. The same vulnerable package reached through different paths may be exploitable in one context and completely harmless in another. By recording each path separately, false positive assessments can be precise - dismissing the vulnerability along one path without affecting others. This path-based model also enables crowdsourced VEX, where tools and organizations share exactly which paths are not affected rather than making blanket statements.

How DevGuard Reduces False Positives#

DevGuard reduces false positives through four complementary mechanisms:

22+ Vulnerability Data Sources: GitHub Security Advisories, OSV, and ecosystem-specific databases provides more accurate version information than single-source scanners.

Backported Patch Detection: Specialized recognition of Debian, Ubuntu, RHEL, and SLES distribution patches eliminates the most common enterprise false positives.

Dependency Tree Analysis: Visibility into which code paths actually reach vulnerable dependencies helps distinguish theoretical from exploitable vulnerabilities.

Continuous Updates: Multiple daily updates incorporate vulnerability database corrections as they become available.

Practices to Reduce False Positives Further#

Tooling cuts the bulk of the noise, but your workflow determines how much remains. These practices help reduce false positives over time:

Document Justifications: When dismissing findings as false positives, document why to prevent repeated investigation.

Prioritize by Risk: Focus on high-severity findings first. Lower-priority investigations can wait.

Accept Inevitability: Some false positive rate is unavoidable. Plan workflows that handle reasonable rates rather than expecting perfection.

Track Patterns: Notice common false positive sources in your environment to guide configuration improvements.

Related Documentation#

• Vulnerability Lifecycle - How to classify vulnerability impact
• Mitigation Strategies - Responding to vulnerabilities
• Vulnerability Risk Assessment - Risk calculation methodology