Vulnerability Research

Open Source Vulnerability Scanner Guide: 6 Tools Compared

Compare Greenbone, Nuclei, Trivy, OSV Scanner, ZAP, and Nmap by the evidence each collects and the work each leaves behind.

Chris Seymour, Cofounder and Principal at Artemes AI
Chris Seymour
Cofounder, Principal
Sep 9, 2026 10 min read
Six open source vulnerability scanners arranged around the evidence target each one observes

An open source vulnerability scanner is not a cheaper version of one commercial platform. It is a set of focused engines, and the team running them owns every gap between those engines.

That distinction decides whether an open source program works. Greenbone can assess network services and hosts. Nuclei runs explicit templates against reachable targets. Trivy and OSV Scanner inspect packages and build artifacts. ZAP observes a live web application. Nmap discovers ports and fingerprints services. They share a category label, not an evidence model.

Current ranking pages tend to compare check marks: containers, web, network, CVEs, reports. The missing question is what each check mark actually proves. This guide answers that question, gives you commands checked against current project documentation, and shows where operator labor replaces a license fee.

Infographic

Choose the scanner by evidence source

Open source tools overlap at the word vulnerability, but they observe different systems and failure modes.

Open source vulnerability scanner evidence mapSix scanner cards map Greenbone to network services, Nuclei to templates, Trivy to images, OSV Scanner to dependencies, ZAP to live web behavior, and Nmap to ports and service versions.The targetdefines the evidencethe tool must collectGreenboneNetwork services and host checksChallenge feed and credential healthNucleiTemplate defined service checksChallenge template trust and scopeTrivyImages, files, and configurationChallenge package matching and runtime useOSV ScannerLockfiles, source, images, and SBOMsChallenge manifest and ecosystem coverageOWASP ZAPLive web requests and responsesChallenge authentication and crawl depthNmapPorts, protocols, and service versionsChallenge inference and script safety

What is an open source vulnerability scanner?

It is software whose source is available under an open license and whose scanning logic can be inspected, changed, or extended within that license. That does not guarantee an open feed, a simple deployment, free hosting, support, or complete coverage. Read the licenses for the engine, templates, feeds, and any dashboard separately.

The practical benefit is control. You can pin a version, inspect a rule, add a test for an internal condition, keep data inside your environment, and automate output without waiting on a vendor roadmap. The trade is ownership. Someone has to secure the scanner, refresh data, tune checks, protect credentials, schedule jobs, normalize results, and prove that the pipeline still runs.

What changed in open source scanning during 2026?

Template execution became a security boundary, not just a convenience. Nuclei 3.11.0, released July 6, 2026, requires custom templates that use the JavaScript protocol to be digitally signed. The Nuclei release history says the change continued earlier sandbox and network policy hardening. That is the recent development many older lists miss. A community template can contain executable behavior. Treat the template channel like a software supply chain.

Greenbone changed too. Its documentation release 26.2.0 landed February 24, 2026, and the current Greenbone Community documentation changelog describes newer container handling, PostgreSQL migration support, and current component versions. A five year old OpenVAS tutorial can still install something, but that does not mean it installs a supported stack. Use the project documentation, not an abandoned recipe.

Demand also changed. Verizon published its 2026 Data Breach Investigations Report on May 19 and found software vulnerability exploitation started 31 percent of breaches. Fast template checks matter, but speed without known scope only makes an incomplete answer arrive sooner.

Which open source vulnerability scanner fits each job?

ToolUse it forDo not assumeOperator burden
Greenbone Community EditionNetwork and host assessmentSimple production operationHigh
NucleiKnown checks across exposed servicesComplete asset or host coverageMedium
TrivyImages, repositories, IaC, and SBOMsNetwork exposure or live reachabilityLow to medium
OSV ScannerOpen source dependency matchingOperating system configuration checksLow
OWASP ZAPWeb and API behaviorServer package inventoryMedium
Nmap with NSEDiscovery and targeted service scriptsA vulnerability management systemMedium

Greenbone is the closest option here to a traditional infrastructure scanner. It brings a manager, scanner, feeds, and a web interface. That breadth costs memory, storage, feed time, and operational care. The official container guide says its container setup is for testing and learning, not production. If you need production, design backups, updates, TLS, capacity, access, and recovery before adding targets.

Nuclei is better understood as a fast template runner. Its strength is explicit, reviewable checks that can move quickly when a new exposure appears. Its weakness is the same design. No template means no test. Broad scans can also touch fragile endpoints, so approve target scope and template set before execution.

Trivy and OSV Scanner belong close to developers. They read packages, lockfiles, images, manifests, and SBOMs. A package match can establish that affected code is present in an artifact. It usually cannot prove that a vulnerable path runs in production or that the service is reachable. That is not a false positive by itself. It is a boundary the workflow must preserve. Our guide to the OSV and GHSA databases explains how advisory identity affects that match.

What does each open source scanner miss?

Greenbone can scan a reachable server and still miss the laptop that never joins the network. A successful network check can also say little about a library buried inside an application image. Put one offline device and one custom application artifact in the truth set. If there is no collection path, record the gap instead of pretending a clean report covers it.

Nuclei has no magic outside its selected templates. A check may confirm one exposed behavior with precision, yet say nothing about adjacent configuration or local package state. Record the exact template identifiers and the selection expression. Otherwise tomorrow's scan can change when the template repository changes, even though the command looks the same.

Package scanners depend on names, versions, distributions, manifests, and advisory ranges. Backports can make a version string look vulnerable after a vendor applied the fix. Files copied outside a package manager can disappear from ordinary inventory. Vendored code may not appear in a lockfile. Seed one example of each pattern you use in production and inspect the underlying match, not only the CVE label.

ZAP sees the application state it can reach. If authentication fails, a crawler may cover the login page and report success while missing the product. Modern client rendering, role differences, APIs, and state changing workflows need explicit plans. Nmap sees the network from one source. A filtered port does not prove the same result from another segment. These are observation limits, not reasons to discard the tools.

What commands should you use for a safe first test?

Only scan systems you own or have written permission to assess. Start with a disposable lab target, pin the tool version in repeatable automation, and save machine readable output. These examples match the current official command syntax.

Nuclei against one approved URL

nuclei -u https://lab.example -severity high,critical -jsonl -o nuclei-results.jsonl

The official Nuclei running guide confirms the target, severity, JSON Lines, and output flags. Review the selected templates before moving beyond the lab.

Trivy against one image

trivy image --severity HIGH,CRITICAL --format json --output trivy-results.json alpine:3.15

Current Trivy image documentation supports those flags. Do not start with --ignore-unfixed. First measure what it removes, then decide whether repair availability belongs in triage or collection.

OSV Scanner against a source tree

osv-scanner scan source -r ./approved-project

ZAP passive baseline against a lab application

docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t https://lab.example

ZAP documents this as a short spider followed by passive analysis. That is safer than an active scan, but it still sends requests. Written scope and a lab target are not optional.

How should you combine open source scanners?

Use a coverage contract. Write one row for each asset type, the question you need answered, the engine that collects evidence, the output format, the owner, and the maximum acceptable age. A basic stack could use Nmap for discovery, Greenbone for infrastructure checks, Trivy for images, OSV Scanner for source dependencies, and ZAP for a running web application. Nuclei handles selected checks where a reviewed template adds speed.

Do not dump every result into one queue without provenance. Preserve the target, scanner version, rule or template identifier, feed time, observed value, and raw evidence. Deduplicate after preserving origin. Two tools can report the same CVE for different reasons, and that difference can matter when one saw a package and another only inferred a banner.

How do you normalize results without erasing evidence?

Create a shared record with fields for asset identity, observation time, scanner, rule, vulnerability identifier, observed value, source advisory, confidence, owner, and state. Keep the native result beside that record. Normalization should help routing and comparison. It should never replace the evidence that supports the claim.

Merge only when the asset and condition match. A Nuclei response from a public host and a Trivy package match inside an image may share a CVE, but they answer different questions. The first can show reachable behavior. The second can show affected code in an artifact. Joining them as one finding without lineage destroys useful context.

Suppression needs an owner, reason, scope, expiration, and verification event. A global ignore file with no expiry is where blind spots go to become permanent. Review suppressed items when the scanner, advisory, asset, or control changes.

The simple math is uncomfortable. Six engines at two hours a week each for updates, failed jobs, tuning, and review is 12 hours. Across 50 weeks, that is 600 hours. At $80 per loaded hour, a zero dollar stack costs $48,000 in annual labor before compute and storage. Open source can still win. Make it win on control, evidence, and fit, not on a fake zero.

What governance keeps the stack trustworthy?

Pin engine and container versions. Verify release artifacts where the project provides signatures or provenance. Admit template changes through review. Keep scan credentials in a vault and restrict when they can be used. Separate collection accounts from administration. Log who changed scope, rules, suppressions, and schedules.

Test the scanner itself after every meaningful upgrade. One known positive proves the rule path still works. One known negative catches overmatching. A deliberately expired credential proves failure is visible. Restore a saved result into the reporting pipeline to test parsing. Boring controls keep free tooling useful.

If the stack finds plenty but the team still cannot decide what deserves work, more scanners will make the queue worse. Artemes approaches that later decision with deep endpoint context and AI driven analysis, while keeping evidence and practitioner review visible. Collection scope still has to be honest.

Frequently asked questions about open source vulnerability scanners

Is OpenVAS the same as Greenbone?

OpenVAS is the scanner component inside the broader Greenbone Community Edition stack. People still use OpenVAS as shorthand for the full system, which includes management, feeds, services, and a web interface.

Which open source vulnerability scanner is best?

Greenbone is the closest fit for broad network assessment. Nuclei fits reviewed template checks. Trivy and OSV Scanner fit artifacts and dependencies. ZAP fits live web behavior. The target decides the answer.

Can open source scanners replace a commercial platform?

They can replace defined collection jobs when the team can own deployment, updates, credentials, normalization, reporting, support, and closure. They do not create an operating model for free.

Are community templates safe to run?

Treat them as code. Review the source, verify provenance, pin the version, restrict network scope, and execute first against a lab. Signed templates improve trust but do not replace review.

The executive takeaway

Name the evidence you need before choosing an open source vulnerability scanner. Run one approved target, retain raw output, break one dependency on purpose, and count weekly operating hours. Add a second engine only when it closes a documented coverage gap. That is how a tool set becomes a program instead of a pile of jobs.

Artemes AI

Put more evidence behind vulnerability decisions

Artemes AI combines endpoint telemetry, sourced vulnerability intelligence, and analysis with practitioner review so teams can examine the evidence, missing context, and recommended next step together. We are accepting early access requests now.

Chris Seymour, Cofounder and Principal at Artemes AI

Chris Seymour

Cofounder, Principal

Chris writes about vulnerability prioritization, exploitability, remediation supported by AI, and the engineering realities of turning scanner output into remediation decisions.

Contextual Scanning
CVE Analysis
Security Automation
Found this useful? Share it.

Get articles like this in your inbox.

Security research and occasional Artemes AI product updates.