A Scanner's False Positives Are a Pattern

Run a vulnerability scanner against a real fleet for a few weeks and you notice something: the same false positives keep coming back. Not random ones — the same findings, on the same kinds of hosts, week after week. That repetition is information. A scanner’s false positives aren’t noise; they’re a pattern, and the pattern is rooted in how the scanner decides something is vulnerable. Once you understand its detection method, the recurring false alarms become predictable — and predictable means you can stop re-investigating them from scratch every time.

The biggest pattern: detecting by version banner

The classic false positive comes from a scanner reading a version string instead of checking what’s actually installed. A service advertises a version in its banner; the scanner sees “version 7.4,” looks up the CVEs filed against 7.4, and fires.

The catch: enterprise Linux distributions backport security fixes. They patch the vulnerability while keeping the upstream version number in the banner, so a fully-patched host still advertises the old version. The scanner reads the banner, not the package changelog, and reports a vulnerability that was fixed months ago. The finding is, strictly, wrong — the fix is present — but the scanner has no way to know because it never looked at the package, only the label it announces.

A scanner that detects by version banner is reading the cover, not the book. Backported fixes live inside the book.

This single pattern accounts for a huge share of recurring noise, especially the findings that have been “open” for years. A vulnerability that’s been flagged for hundreds of days and never exploited is usually not an unpatched risk — it’s a detection artifact that nobody’s formally dispositioned.

True-but-unfixable is not the same as false

Here’s the distinction that keeps you honest, and it’s easy to blur. On a general-purpose Linux host you maintain, the banner finding is a genuine false positive — the backported fix is right there, provable. But on a vendor appliance running an old embedded version with no patch available, the same finding may be technically accurate and simply unfixable by you.

Those are different cases that need different responses. One is “this is wrong, the fix is installed, here’s the proof.” The other is “this is correct, but there’s no remediation available and the risk is accepted.” Lumping them together — calling everything a false positive — erodes your credibility the first time someone checks and finds a real, unpatched appliance. Catalog the pattern, but always sort each hit into false versus true-but-unfixable. The triage is cheap; the lost trust from getting it wrong is not.

Validate read-only before you claim it

A pattern is a hypothesis, not a verdict. Before challenging a finding as a false positive, confirm it on a reachable host — read-only, no changes. For the banner-versus-backport case that means checking what’s actually installed and proving the fix is in: look at the installed package version, look at the package’s changelog for the specific fix, and compare the banner the scanner saw against the reality on disk.

If the installed package post-dates the vulnerability’s fix, you have evidence, and you can submit a proper exception citing the distribution’s security advisory rather than pointlessly “re-patching” something already patched. The discipline: recognize the pattern to move fast, but verify before you act on it, because the cost of waving off a real vulnerability as a known false positive is exactly the kind of mistake you can’t afford in security work.

Watch how a flag propagates

One more pattern worth naming, because it inflates scary numbers: how a scanner attributes a flag across bundled findings. When many vulnerabilities are grouped into one finding — say, dozens of CVEs all closed by a single kernel update — a “known exploited” marker set at the finding level can read as if it applies to every CVE inside the bundle. Count naively and you get an alarming tally of critical items that’s really one finding flagged once.

The fix is to understand the granularity of each flag — does it apply per finding or per CVE? — and count at the right level. A lot of “the numbers look terrifying” turns out to be one flag echoing across a bundle. Knowing your tool’s data model is part of reading its output honestly.

Turn the patterns into a living catalog

The payoff from all this is a written catalog of your scanner’s recurring false positives: the detection mechanism behind each, how to validate it read-only, and how to disposition it. That document is what converts a weekly slog into a fast triage — when a known pattern shows up, you recognize it, confirm it quickly, and point at the existing disposition instead of starting an investigation from zero.

It also reframes the relationship with the tool. The scanner isn’t lying to you; it’s detecting the only way it can, and its blind spots are consistent. Consistent blind spots are learnable. Learn them, write them down, keep the distinction between false and unfixable sharp, and you spend your real attention on the findings that are actually new and actually exploitable — which is the whole point of treating vulnerability management as triage instead of a treadmill. If you maintain your own false-positive playbook, I’d love to compare notes.