Why one scanner is never enough: layers, methods and feeds

One scanner, one blind spot

Most security teams pick a vulnerability scanner, put it on a schedule, and call that coverage. But what they have is one tool's view. A scanner looks at one part of your attack surface, with one detection method, reading from one vulnerability feed. Pick one and you get its blind spots along with its strengths.

None of this is a complaint about the tools. Nmap, OpenVAS, Nessus, OWASP ZAP, Nuclei and SSLyze each do their job well. The mistake is assuming one of them does every job. A single scanner covers 60 to 80% of your exposure, and NIST 800-53 recommends using more than one tool for exactly this reason.

Scanners look at different layers

Think of the attack surface as five layers: TLS, web application, services, host and network. Each scanner works on one or two of them and ignores the rest.

• TLS holds certificates, cipher suites and protocol versions. SSLyze covers it.
• Web app holds forms, parameters, sessions and application logic. OWASP ZAP and Nuclei cover it.
• Services are the open ports and the software answering on them. Nmap and Nuclei cover them.
• Host is the operating system and its installed packages. OpenVAS and Nessus cover it.
• Network is the reachable hosts and exposed infrastructure. OpenVAS and Nessus cover it.

What each one sees, and what it misses:

Nmap tells you what is listening. A full scan checks all 65,536 TCP ports on every target, including hosts that block ping, and a separate UDP scan picks up DNS, SNMP, NTP and the other services a TCP scan can't reach. What Nmap won't tell you is whether any of those services is vulnerable, because that was never its job.

OpenVAS (Greenbone Community Edition) starts with a port scan of every IANA-registered TCP port and the top 100 UDP ports, then runs tens of thousands of tests from the Greenbone Community Feed against whatever it found. Most of those tests work by inference, reasoning from a version string and a configuration to a likely CVE. That approach gives OpenVAS no view into your web application's logic, and it can't flag a CVE that hasn't reached the Greenbone feed yet.

Nessus covers the same host and network layers from Tenable's plugin library, which runs to 319,000+ plugins and 117,000+ CVEs, and it can scan from the cloud, from a scanner inside your network, or as an agent on the host itself. Because what Nessus finds depends on Tenable's plugins rather than Greenbone's, pointing both at the same server will give you two lists that don't fully overlap.

OWASP ZAP crawls your web application and probes it in two modes. The passive scan reads every response for insecure cookies, cross-domain misconfigurations and vulnerable JavaScript libraries, while the active scan submits forms and payloads to test for SQL injection, cross-site scripting and remote command execution. Everything underneath the app, meaning the firewall, the host and the operating system, is outside ZAP's view.

Nuclei runs 10,000+ signed templates maintained by the ProjectDiscovery community, each one a specific request paired with the response that confirms a specific issue. Together they cover 3,500+ CVEs along with exposed config files, open admin panels and default credentials across web, API and network targets. The limit is built into the method: if nobody has written a template for an issue, Nuclei won't find it.

SSLyze connects to a server and tries every protocol version from SSL 2.0 to TLS 1.3, records which cipher suites each one accepts, validates the certificate chain and tests for Heartbleed, CCS injection and ROBOT.

Same host, different methods

Two scanners working on the same layer still rarely look at it the same way, and across these six tools you'll find four distinct detection methods.

• Banner and version matching. The scanner reads what a service says about itself and looks that version up in a vulnerability list. It's fast and quiet, but it trusts the banner, so a backported patch that leaves the old version string in place reads as vulnerable while a service with its banner suppressed reads as clean.
• Authenticated checks. The scanner logs in with credentials and reads installed packages, config files and registry keys directly, which is how Nessus and OpenVAS find missing patches that no external probe could see. The trade-off is that it finds nothing on a host you haven't given credentials for.
• Active crawling and probing. ZAP walks the application link by link, submits input to every parameter it finds and watches how the app responds, which surfaces logic flaws that have no CVE number at all. A page the crawler can't reach, though, is a page that never gets tested.
• Template matching. Nuclei sends a precise request and matches on the response a vulnerable system returns, confirming a specific CVE on a specific product in seconds with few false positives. It can't flag anything that hasn't been written up as a template.

Run two of these against one host and the reports will disagree, because OpenVAS infers a vulnerability from a version string while Nuclei reports one only when the target responds the way the vulnerable software does. One scanner flags an outdated version the other confirmed is patched; one finds an injection point the other never crawled to. Neither report is wrong, and running both catches what either alone would miss.

They don't share a brain

Each scanner reads from its own vulnerability database, maintained by its own team on its own schedule: OpenVAS uses the Greenbone feed, Nessus uses Tenable's plugin library, and Nuclei pulls from a public template repository that anyone can contribute to. None of them sync with each other, and that has three consequences.

The first is update speed. Greenbone updates its Community Feed on a daily schedule, Tenable ships more than 100 new Nessus plugins a week, and the nuclei-templates project often has a new template within hours of a major disclosure. However thorough the scan, a scanner can't find a vulnerability its feed doesn't know about yet.

The second is breadth. Each feed decides for itself which products and which CVEs get a check written, so a niche appliance or an old software version may be well covered in one database and absent from another. Those gaps don't line up, which is the whole reason to run both.

The third is detection quality. Even when two feeds cover the same CVE, each team writes its own check for it: one might confirm the flaw with an active probe, another might infer it from a version banner. So the same CVE can be caught reliably by one scanner and missed, or wrongly flagged, by another, and which scanner does better changes from one detection to the next.

Teams tend to compare scanners on features and speed and treat the feed as a detail, but a scanner is exactly as current as the database behind it.

Coverage is a portfolio question

Coverage comes from knowing what each scanner can't see and closing that gap with another tool, not from picking the best one. Five questions make this concrete.

1. Which layers do you expose? A SaaS product with a public web app and a cloud footprint has all five, while an internal network with no web presence might have three. Map your layers before your tools.
2. Which layers does your current scanner cover, and which does it skip? A host scanner that reports "no findings" on a web app didn't pass the app, it never looked at it.
3. Where does one scanner's blind spot line up with another's strength? Nmap plus a host scanner tells you what's listening and whether it's vulnerable, and ZAP plus Nuclei covers both the logic flaws and the known CVEs in your web layer. OpenVAS plus Nessus gives you two independent feeds on the same host.
4. What happens when two tools disagree? Usually both are right about different things, so investigate the difference instead of picking a winner.
5. How current is each feed? Check update cadence as well as scan cadence, because a weekly scan against a stale feed is a weekly false sense of security.

Work through these and the answer is rarely one tool but a combination, chosen for the surface you have.

Scanners for every surface, in one place

Running six scanners is easy to agree with and hard to do: six installs, six update schedules, six report formats, and the work of reconciling them when they disagree. That overhead is why most teams settle for one.

HostedScan runs all six: OpenVAS, OWASP ZAP, Nuclei, Nmap and SSLyze come with every plan, and Tenable Nessus is added on the Professional plan. Each scanner stays current on its own feed, and every finding lands in one risk list, first and last seen dates, CVSS and EPSS scores and a health score per target. Authenticated web app scans, internal and external scanning, subdomain discovery and cloud asset sync for AWS, Azure, Google Cloud and DigitalOcean cover the rest of the surface from the same place.

Written by

Richard BlissProduct Manager

Share this post: