Version-Aware CVE Matching: Killing the False Positive

Here's a finding that wastes an enormous amount of security time: "Apache HTTP Server — CVE-2021-41773 — Critical." It looks urgent. But CVE-2021-41773 only affects Apache 2.4.49. If you're running 2.4.25 or 2.4.51, you are not vulnerable to it at all. A product-level match would still flag you. A version-aware match would not.

Product matching is not enough

A CVE record describes the affected configurations as version ranges — "affects 2.4.49," ">= 1.0, < 1.4.2," and so on. Matching only on the product ("this host runs Apache") ignores the ranges entirely and produces a flood of findings that don't apply. Those false positives are corrosive: teams either drown in them or, worse, start ignoring the tool.

Getting the version right

Version-aware matching is only as good as the version you attribute, so the hard part is fingerprinting. Argus reads banners, response headers, and behavioural signals, resolves them to a precise CPE, and only then evaluates the CVE's version ranges against the version actually observed.

• In range → the finding stands, with the evidence shown.
• Out of range → it's suppressed, not surfaced as noise.
• Version unknown → it's caveated honestly rather than over-claimed.

The distro back-port trap

There's a subtle failure mode here. Linux distributions back-port security fixes without changing the upstream version string — a Debian package may report 2.4.25 while carrying patches from a much later release. Naive version-range matching over-claims on these. Argus treats an upstream-range match on a distro package as a caveated signal, not a confirmed hit, so you don't chase a vulnerability that was already patched downstream.

A finding you can't trust is worse than no finding at all — it trains your team to ignore the tool.

Version-aware matching is unglamorous plumbing, but it's the single biggest lever on signal-to-noise. Get it right and the list shrinks to things that are actually true.