Compare vulnerability scanners on four things: where they look (network, host or code), what access they need, how they rank what they find, and how many findings turn out to be false. A feature table will not answer these. A trial against your own systems will.
What kinds of scanning exist?
NIST SP 800-115, the technical guide to security testing, describes vulnerability scanning as identifying hosts and host attributes such as operating systems, applications and open ports, and also attempting to identify vulnerabilities instead of relying on a person to interpret the results. It lists two main styles.
Network-based scanning probes from outside the host. NIST calls a scanner a relatively fast and easy way to quantify exposure to surface vulnerabilities, meaning weaknesses that exist in isolation. It also lists weaknesses: it finds vulnerabilities only on active systems, can have a high false positive rate, needs an expert to interpret results, and generates significantly more network traffic than a port scan, which can affect the hosts or segments being scanned.
Local or host-based scanning installs a scanner on each host. NIST says it detects vulnerabilities in greater detail than network scanning, because it usually has local access and an administrative account, and it finds both network-exploitable and locally exploitable issues. Some scanners can also repair local misconfigurations.
A third style, scanning application code and dependencies, is outside what that document covers. It works by reading source, manifests or build artifacts instead of probing a running system, and it answers different questions: which libraries you ship and whether the vulnerable function is reachable.
How should findings be ranked?
Three public sources do different jobs, and a good comparison asks which ones a scanner uses.
CVSS, maintained by FIRST, captures the principal characteristics of a vulnerability and produces a numerical severity score, which can be translated to low, medium, high or critical. FIRST says the current version is 4.0. Severity is not likelihood.
EPSS, also from FIRST, is a data-driven model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days. It publishes a 0 to 1 probability for every CVE each day, free of charge.
CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities exploited in the wild, and CISA tells organizations to use it as an input to their prioritization framework. The catalog page showed 1,748 entries when fetched on 18 October 2026.
CISA's BOD 26-04 combines four variables for urgency: whether the asset is publicly exposed, whether the CVE is on the KEV list, whether an adversary can automate the whole exploit, and whether exploitation gives partial or total control. A scanner that can feed those variables is more useful than one that outputs only a severity color.
What cadence is reasonable?
BOD 23-01 sets agency requirements that serve as a public yardstick: automated asset discovery every 7 days, vulnerability enumeration initiated every 14 days across discovered assets including laptops, privileged credentials where feasible, and signature updates within 24 hours of the vendor's release. It also says full enumeration may not finish in 14 days, but it should still be initiated regularly.
A constructed example
You trial two scanners on the same staging environment. Scanner A reports 480 findings, mostly network-level, and 300 are informational. Scanner B reports 140, with host access, and tags each with KEV status and exposure. Ten are KEV and public. The team fixes those first. The comparison metric that mattered was not the count. It was how many findings per hour of engineer time turned out to be real and urgent.
How to check or apply this
- List what you need to scan: hosts, cloud accounts, containers, applications, dependencies.
- For each scanner, record the access it needs: network position, credentials, agents or repository access.
- Run all trials against the same targets, including a few known issues planted by your team.
- Measure false positives by sampling 30 findings and checking each by hand.
- Check ranking inputs: CVSS version, EPSS, KEV, exposure, reachability.
- Check scan impact: traffic and load on production, using NIST's warning as the reason.
- Test the fix workflow: ticketing, pull requests, re-scan to confirm closure.
- Compare how fast new signatures arrive against the 24-hour reference.
For the code and dependency layer, Safeguard offers SBOM and dependency scanning with reachability analysis, and a free in-browser scan of up to 100 dependencies at gold.safeguard.sh/scan. It does not scan hosts or networks.
Quick check
Does a higher CVSS score mean a vulnerability is more likely to be exploited?
No. CVSS describes severity. EPSS estimates the probability of exploitation in the next 30 days, and the KEV catalog lists vulnerabilities already exploited in the wild.
Why can network scanners report false positives?
NIST notes they infer vulnerabilities from a system's responses to probes, and can report vulnerabilities that do not exist. An expert should interpret the results.
Sources
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
- FIRST, Common Vulnerability Scoring System
- FIRST, Exploit Prediction Scoring System
- CISA, Known Exploited Vulnerabilities Catalog
- CISA, BOD 26-04: Prioritizing Security Updates Based on Risk
- CISA, BOD 23-01
Last reviewed: 18 October 2026.
