OpenVAS, ZAP, Nmap and Nuclei: Why One Vulnerability Scanner Leaves Blind Spots

Most SaaS teams and MSPs start vulnerability scanning the same way: they pick one tool, point it at a production hostname, and treat the resulting report as the full picture. It is a reasonable first step, but every scanner is built around a specific way of looking at a target. A network scanner sees ports and services. A web application scanner sees pages, forms, and parameters. A template scanner sees known fingerprints. Anything outside a tool's method is simply invisible to it, and a clean report only tells you that the tool found nothing it was designed to find.

This guide explains what each of the four open source engines behind Panoptic Scans - OpenVAS, ZAP, Nmap, and Nuclei - is good at, where each one goes quiet, and how to combine them into a scanning plan that closes the most common blind spots without burying your team in duplicate findings.

Why a single scanner always has blind spots

Scanners differ in three ways that matter: the layer they test (network, service, or application), the method they use (fingerprinting a version, sending crafted requests, or crawling and attacking a live app), and the feed of checks they rely on (a vulnerability test feed, a script library, or community templates). A gap in any one of those three is a gap in your coverage.

A few common examples:

• A network scanner can tell you that port 443 is open and that the TLS service has a weak configuration, but it will not log in to your app and try to inject a script into the profile page.
• A web application scanner can find reflected cross-site scripting on your marketing site, but it will never notice the forgotten database port on a staging server that has no web front end.
• A template scanner can flag an exposed admin panel within seconds, but only if a template for that panel exists.

NIST makes the same point in SP 800-115, the Technical Guide to Information Security Testing and Assessment, which treats vulnerability scanning as one of several complementary techniques rather than a single complete test. The practical answer for a small team is not to buy more products. It is to run the right engine against the right type of target.

OpenVAS: deep network and host assessment

OpenVAS is a full network vulnerability scanner. It probes hosts and the services running on them using a large feed of network and application tests, and it reports CVEs, misconfigurations, and outdated software. In Panoptic Scans, OpenVAS scans take IP addresses, hostnames, or CIDR ranges rather than web URLs, because the scanner is assessing infrastructure, not crawling a site the way a browser does.

Where it shines: broad CVE coverage across servers, VPN gateways, mail servers, databases, and anything else that listens on the network. It is the engine most teams lean on for SOC 2 network vulnerability scanning evidence.

Where it goes quiet: OpenVAS is not designed to explore the business logic of a signed-in web application. It will not follow your onboarding flow, submit forms as a logged-in user, or test the API calls your single-page app makes behind the scenes. Full assessments are also heavier than a quick port scan, and duration ranges from minutes to hours depending on how many hosts and ports are in scope.

For private networks, Panoptic Scans supports internal network scanning with OpenVAS on the Pro plan. That mode runs the scanner on an Ubuntu VM you provide with Docker and at least 8 GB of RAM, so you can assess hosts that are not reachable from the internet.

Nmap: fast discovery of what is actually exposed

Nmap is the classic network discovery and port scanning tool. Its service and version detection interrogates open ports to work out which software and version is listening. In Panoptic Scans, Nmap runs with the vulners NSE script, which takes the software identifiers from version detection and looks up known vulnerabilities and CVSS scores for them.

Where it shines: speed and inventory. Nmap runs are typically much quicker than full OpenVAS assessments, which makes them a good way to map your external attack surface before deeper testing and to spot a newly opened port the week it appears.

Where it goes quiet: CVE results from banner and version matching are only as good as the version information the service reveals. A backported security patch can make a version look vulnerable when it is not, and a service that hides its banner may produce no CVE match at all. Nmap also does not test web application behavior. Treat its findings as a map and a first signal, then confirm with a deeper engine.

ZAP: dynamic testing of running web applications

ZAP is a dynamic application security testing (DAST) scanner. Instead of fingerprinting versions, it crawls a running web application, discovers pages and parameters with its spider, and sends attack requests to find runtime issues such as cross-site scripting, SQL injection, CSRF weaknesses, and security misconfigurations. Many of these map to the categories in the OWASP Top 10.

In Panoptic Scans, ZAP scans take a single full https:// URL per scan, so each app or API entry point gets its own scan. On Basic, Premium, and Pro plans you can add authenticated scanning, where a Selenium Python login script signs ZAP in before the crawl and attack phases so it can reach protected routes.

Where it shines: the code you wrote. Network scanners have no idea how your signup form handles input. ZAP does, and it is the closest thing in this stack to an automated attacker poking at your product.

Where it goes quiet: ZAP only tests what it can reach and crawl. It does not scan bare IPs or non-HTTP services, so it will miss an exposed SSH daemon or database port entirely. Without authentication it only sees your logged-out surface, which for most SaaS products is a small fraction of the real application.

Nuclei: quick template checks for known exposures

Nuclei, from ProjectDiscovery, runs YAML templates against targets to flag known CVEs, misconfigurations, exposed admin panels, and similar issues. The templates come from the community-curated nuclei-templates repository, and Panoptic Scans keeps them updated so new checks arrive without you managing template bundles. Nuclei scans take hostnames, IPs, or domains without a URL scheme.

Where it shines: fast, broad passes across many assets. When a widely discussed CVE lands and a template follows, Nuclei is often the quickest way to check whether any of your hosts match.

Where it goes quiet: a template scanner can only find what someone has written a template for. It does not reason about your custom application logic, and a missing template means a missing finding, not a safe host.

Which scanner fits which target

The table below summarizes how the four engines line up. It reflects how each one is configured in Panoptic Scans, as described in the Running Scans documentation.

Engine	Target format	Best at	Main blind spot
OpenVAS	IPs, hostnames, CIDR ranges	Deep CVE and misconfiguration checks on hosts and services	Signed-in web application logic
Nmap	IPs, hostnames, CIDR ranges	Fast port and service discovery with CVE lookups	Accuracy depends on exposed version data; no app testing
ZAP	One full http:// or https:// URL per scan	Runtime web flaws such as XSS and SQL injection	Non-HTTP services and anything it cannot crawl
Nuclei	Hostnames, IPs, domains without a scheme	Quick checks for known CVEs and exposed panels	Issues with no template

A practical layered scanning plan for SaaS teams and MSPs

You do not need to run every engine against every asset every day. A simple rhythm covers most small SaaS products and most MSP client environments.

1. Start with an inventory

Run Nmap against every public IP and hostname you own. The goal is a clear list of what is listening. Anything surprising, such as a database port, an old staging host, or a remote desktop service, becomes a fix or a deeper scan target. MSPs can repeat this per client as part of external attack surface monitoring.

2. Assess infrastructure in depth

Point OpenVAS at the same hosts on a recurring schedule. Panoptic Scans supports daily, weekly, monthly, quarterly, and yearly schedules, so a weekly or monthly OpenVAS run alongside a more frequent Nmap run is a common pattern. If you have private infrastructure and the Pro plan, add internal scans for hosts that never face the internet.

3. Test each web application with ZAP

Create one ZAP scan per application URL and per public API root. For your main product, set up an authenticated scan so ZAP reaches the parts of the app your customers actually use. This is where most SaaS-specific risk lives, and it is the layer network scanners cannot see.

4. Sweep for known exposures with Nuclei

Run Nuclei across your hostnames regularly, and run it again when a high-profile CVE is announced. Its speed makes it a good complement to the heavier OpenVAS assessment rather than a replacement for it.

5. Review findings together, not in silos

Running several engines means some findings overlap. The same outdated web server might appear in Nmap, OpenVAS, and Nuclei results. Treat that overlap as confirmation rather than noise, record one remediation item for it, and use the vulnerability management statuses to mark issues as Unresolved, Resolved, Accepted, or False Positive. If you want help separating real issues from scanner noise, our guide on verifying false positives walks through it, and our post on vulnerability prioritization covers what to fix first.

On Premium and Pro plans, Panoptic Scans can also generate an attack narrative for eligible scans: an AI-written description of how an attacker might chain the findings together. It is a useful way to explain to a founder or client why a medium-severity web issue and an exposed service matter more together than apart. Like any automated output, it is a starting point for human review, not a verdict.

What layered scanning means for compliance evidence

Auditors and enterprise customers increasingly ask not just whether you scan, but what you scan and how. A SOC 2 auditor reviewing your vulnerability management process will want to see that scanning covers the systems in scope and that findings are tracked to resolution. Showing a network scan of your infrastructure plus an authenticated application scan of your product is a much stronger story than a single external port scan. Our SOC 2 vulnerability scanning guide goes deeper on what that evidence typically looks like, and Panoptic Scans can push results into Vanta through the Vanta integration.

Be honest about limits, too. Automated scanning, even with four engines, does not replace a manual penetration test for complex business logic, and it only covers systems you have added as targets. Our comparison of vulnerability scanning and penetration testing explains when you need both.

Conclusion

Every scanner has a blind spot because every scanner has a method. OpenVAS sees hosts and services in depth, Nmap shows what is exposed quickly, ZAP tests how your web application behaves under attack, and Nuclei sweeps for known exposures at speed. Used together on the right targets, they cover far more of your real attack surface than any one of them alone.

Panoptic Scans runs all four as hosted scanners, with scheduling, authenticated ZAP scans, and SOC 2-ready reports, so you can build a layered plan without maintaining the tools yourself. Review the plans and pricing or look at a sample report to see what the output looks like. Only scan systems you own or have written permission to test.