Back to Help Index

CVE Evidence Decisions

VersionGopher treats CVE matching as an evidence decision, not a simple filename and version comparison. The matcher uses product identity, vendor/platform context, component scope, and version authority to decide whether a candidate should be shown as actionable, marked for verification, or retained only as audit evidence.

The goal is fewer visible false positives without losing the trail of why a CVE candidate was considered.

Production scans are evaluated with the current evidence-decision model. Existing production scans were refreshed so normal CVE filters show current evidence lanes rather than stale broad matches.

Actionable

The product, vendor, component, and version evidence agree strongly enough that the CVE belongs in the normal remediation lane.

Needs Verification

The version or identity evidence is plausible, but exploitability, distro backports, bundled component reachability, or parent-product context needs an analyst check.

Audit Evidence

Suppressed and not-applicable candidates are hidden from visible CVE lanes by default, but the reason code and failed gates remain available for review.

False-Positive Classes The Matcher Blocks

Generic token collisions: bare names such as campaign.py, network, or db2 are not enough to claim a product CVE.
Child-file version overreach: a DLL, node addon, resource file, or bundled library version cannot automatically stand in for the containing product version.
ABI and SONAME confusion: Linux shared-object ABI numbers are separated from upstream package versions and distro-patched package versions.
Platform/vendor mismatch: an advisory for one vendor's product should not match an unrelated file just because the component name is common.
Ambiguous fixed-version state: real-looking matches with unknown reachability or no known fixed version can be moved to verification or mitigation guidance instead of being silently discarded.

How To Read The UI

Use CVE Lane filters to switch between all visible CVEs, Actionable, and Needs verification.
Open a file card to start with Decision Summary, Artifact Identity, Evidence Gates, and CVE Evidence Decisions before expanding the deeper evidence bucket.
Use the collapsed Evidence Decision and Decision Trace details when a candidate looks surprising or when an analyst needs to explain why something was hidden.
Version Observations show alternate versions found for the same scanned file and SHA-256; alternates are provenance, not separate CVE findings.
Metadata Probe, Binary Forensics, signature/trust details, classified strings, package evidence, and scan provenance live under Forensics & Evidence. Expand them when a reviewer needs the raw proof.

Needs verification is not a synonym for false positive. It means the evidence is not strong enough for automatic remediation, but the item still deserves analyst attention.

Operational Notes

Background CVE matching runs against materialized scan summaries so large scans can be filtered without recomputing every candidate on page changes.
After matcher logic changes, existing scans are refreshed to the current matcher version before the UI treats the scope as current.
PostgreSQL planner statistics are refreshed after matcher runs so all-scan actionable and verification lane searches keep using the intended indexed paths.
Package Risk and OSV package advisories remain separate from NVD/CPE CVE matching.