The National Vulnerability Database entered September 2026 carrying more than 27,000 unprocessed CVEs, a backlog that grew from roughly 13,000 in mid-2024, according to a June 2026 inspector general report from the US Commerce Department. In April 2026, NIST reclassified close to 29,000 of those backlogged entries as “Not Scheduled,” meaning they get no automatic enrichment unless they appear on CISA’s Known Exploited Vulnerabilities catalog, affect a federal system, or meet the criteria in Executive Order 14028. The same report found that NVD severity scores were wrong 88% of the time in a sampled review. If you are still waiting on the federal government to tell you what is dangerous on your network, you are waiting on a system that is, by its own auditor’s admission, broken.
That is the practical argument for running your own vulnerability scans instead of relying on a single feed. This tutorial walks through building a real scanning setup with three free, actively maintained tools: Nmap for network discovery, Greenbone/OpenVAS Community Edition for full-stack vulnerability assessment, and Nuclei for fast, template-driven checks against web apps and APIs. By the end you will have a working scan pipeline you can point at your own lab or authorized infrastructure, a way to read and prioritize the results without leaning on a single broken scoring source, and a cron-driven automation script that turns a one-time scan into a repeatable habit. Budget about 90 minutes for the full walkthrough, longer if this is your first time working with Docker or a Linux vulnerability manager.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What a Vulnerability Scan Actually Checks (and What It Doesn’t)
A vulnerability scan is an automated process that probes hosts, services, and applications, then compares what it finds against a database of known weaknesses. It is not a penetration test. A scanner tells you a service is running an outdated OpenSSH build with a known CVE. It does not chain that finding into a working exploit or prove an attacker could actually reach your database from that entry point. Vulnerability scanning is the detection layer. Penetration testing is the exploitation layer. Most organizations need both, but they need scanning far more often, because scanning is cheap enough to run every week and a pentest is not.
Three categories of tool cover most of what a small team needs. Network and infrastructure scanners like Nmap and Greenbone/OpenVAS look at open ports, running services, TLS configuration, and known CVEs tied to specific software versions. Template-driven scanners like Nuclei check web applications and APIs against a library of proof-of-concept style rules, which makes them fast at catching things like exposed admin panels, default credentials, and specific CVE signatures in HTTP responses. Commercial platforms like Nessus, Tenable.io, and Qualys bundle discovery, assessment, and reporting into a single paid product with broader plugin coverage and compliance templates — a market Mordor Intelligence sized at $5.58B in July 2025 and MarketIntelo put slightly higher at $5.8B the following month, with Business Research Insights separately valuing the narrower vulnerability scanner software segment at $1.29B in August 2025 and even niche verticals like automotive vulnerability scanning reaching $1.8B that same month per MarketIntelo; sorting through that spread of paid options is worth its own comparison and not the focus here.
Vulnerability scanning also has real limits. A scanner only finds what its plugin or template database already knows about, so it is structurally blind to genuinely new, unpublished flaws. It generates false positives, sometimes a lot of them, especially on network scanners doing banner-based version detection. And a scan against a live production system without care can crash a fragile service or trip an intrusion detection system, which is exactly why the first two steps below are about authorization and scope, not tooling.
Prerequisites: Tools, Versions, and a Safe Lab Environment
Set up the following before you touch a scanner. All version numbers below reflect the current stable releases as of early September 2026.
- A Linux host or VM running Ubuntu 24.04 LTS (Noble), with at least 4GB RAM and 20GB disk free for OpenVAS/Greenbone’s feed data
- Docker Engine and Docker Compose v2, since the recommended way to run Greenbone Community Edition in 2026 is via its official Community Containers
- Nmap, currently at version 7.991 upstream (Ubuntu’s own APT repository ships an older packaged build, more on that in Step 3)
- Nuclei by ProjectDiscovery, currently at v3.9.0, released June 10, 2026, with template releases as recent as v10.4.3 in May 2026 adding deeper CISA KEV coverage and AI/LLM attack-surface templates
- Optional: Nessus Essentials (Tenable’s free, IP-capped tier) if you want a second engine to cross-check results
- A target you are actually authorized to scan: a local VM, a deliberately vulnerable box like Metasploitable2, or your own homelab network, never a system you do not own or have written permission to test
- Basic comfort with the Linux command line and a text editor
Scanning any system without explicit authorization can violate the Computer Fraud and Abuse Act in the US and equivalent computer-misuse laws elsewhere, regardless of your intent. Everything in this tutorial assumes you are scanning infrastructure you own, a lab environment, or a target where you hold a signed authorization letter.
Step 1: Get Written Authorization and Define Scope
Before any command runs, write down what you are allowed to scan, when, and how aggressively. Even inside your own company, an unannounced scan against a production database cluster has taken down services before, because some scan checks (particularly denial-of-service and buffer-overflow probes) can crash a fragile daemon. A one-page scope document covering IP ranges or hostnames in scope, excluded systems, scan window, and an emergency contact takes fifteen minutes to write and saves a very bad afternoon.
If you are testing for this tutorial, your scope is simple: a local lab VM or a container you control. If you are rolling this out at work, get sign-off from whoever owns the network and the systems in scope, in writing, even if that is just a Slack message with a manager’s thumbs-up reaction. Keep that record. It is the difference between authorized security testing and something that looks, from a log file, exactly like an attack.
Step 2: Build a Safe Scan Target
Do not point your first scan at anything that matters. Spin up a disposable, intentionally vulnerable VM instead. Metasploitable2 remains a common, free training target because it ships with deliberately outdated services (old FTP, Samba, and web server builds) that produce clean, teachable findings. Any Ubuntu 22.04 VM with a couple of outdated packages left un-upgraded works too.
# On your host machine (not the target), confirm the target VM's IP
ip addr show
# Ping the target to confirm reachability before scanning
ping -c 3 192.168.56.101Replace 192.168.56.101 with your actual lab VM’s address throughout the rest of this guide. Keep the scanner and the target on an isolated, host-only or NAT network so nothing leaks onto your production LAN.
Step 3: Install Nmap and Run Your First Discovery Scan
Nmap is the starting point for almost every scan workflow because it answers the first question a scanner needs answered: what is actually listening. On Ubuntu 24.04, the fastest path is the distro package, though it is worth knowing upfront that Ubuntu’s Noble repository currently carries an older packaged build (roughly 7.94, based on a 2023 upstream snapshot) rather than the latest 7.991 release from the Nmap project itself.
sudo apt update && sudo apt upgrade -y
sudo apt install -y nmap
nmap -VThe packaged version is fine for discovery and NSE vulnerability scripting. If you specifically need 7.991’s newer NSE scripts, download the source tarball from nmap.org and compile it, but for this tutorial the APT package is enough. Run a first discovery scan against your lab target:
# Service and version detection against every TCP port, output to a file
sudo nmap -sV -p- -oN nmap-discovery.txt 192.168.56.101
# Run Nmap's built-in vulnerability-detection scripts against discovered services
sudo nmap -sV --script vuln -oN nmap-vuln.txt 192.168.56.101The first command takes several minutes on a full 65,535-port sweep. Expect it to run faster if you restrict to common ports with -p 1-1000 during testing. The --script vuln flag loads Nmap’s NSE vulnerability category, which checks discovered services against known CVE signatures for things like outdated Samba, vsftpd backdoors, and SSL/TLS misconfiguration. Read the output carefully. Nmap will flag services and sometimes cite a CVE ID directly in the terminal output, which becomes your first triage list.
Step 4: Deploy Greenbone Community Edition (OpenVAS) With Docker
Nmap tells you what is open. Greenbone Community Edition, the free version of the OpenVAS scanning engine, tells you what is actually exploitable, correlated against its own feed of network vulnerability tests (NVTs), which the Greenbone project reports now covers more than 160,000 checks. In 2026 the supported way to run it is Greenbone’s official Community Containers via Docker Compose, replacing the older manual apt-based install that used to break constantly on version mismatches.
# Install Docker Compose plugin if you don't already have it
sudo apt install -y docker-compose-plugin
# Clone Greenbone's official community containers repo
git clone https://github.com/greenbone/openvas-docker.git
cd openvas-docker
# Pull images and start the full stack (Postgres, Redis, gvmd, gsad, openvas-scanner)
docker compose pull
docker compose up -dThe first startup triggers a full NVT feed download, which typically takes 15 to 30 minutes depending on your connection, while subsequent feed updates run in 5 to 10 minutes. Watch the logs to confirm the feed sync finished before you try to scan anything:
docker compose logs -f gvmd | grep -i "feed"Once the containers are healthy, open a browser and go to https://127.0.0.1:9392, the default port for the Greenbone Security Assistant web interface. Accept the self-signed certificate warning (this is a local lab instance) and log in with the admin credentials Docker Compose printed to the console during first startup, or generated in a Compose environment file if you set one.
Step 5: Configure a Scan Target and Task in Greenbone
Inside the web interface, go to Configuration, then Targets, and click the star icon to create a new target. Enter your lab VM’s IP address, leave the port list on the default “All IANA assigned TCP” unless you have a reason to narrow it, and save. Then go to Scans, then Tasks, click the star icon again, and create a new task pointing at the target you just made. Pick the “Full and fast” scan config for your first run, which balances thoroughness against runtime.
Start the task from the Tasks list. A full scan against a single lab VM usually finishes in 10 to 40 minutes, depending on how many services it finds and how deep the NVT checks go for each one. When it completes, click into the task and open the report. Greenbone groups findings by severity (High, Medium, Low, Log) using CVSS scoring pulled from its own NVT metadata rather than depending on NVD enrichment, which matters given how far behind NVD’s own enrichment queue has fallen this year.
Step 6: Add Nuclei for Fast Web and API Scanning
Greenbone and Nmap are strong at host and network-layer scanning. Neither is built for the modern web and API attack surface the way Nuclei is. ProjectDiscovery’s scanner runs a YAML-based template library against HTTP endpoints, DNS, and cloud configuration, and its community keeps that template set current, with releases in April and May 2026 specifically expanding coverage of CISA’s Known Exploited Vulnerabilities list and emerging AI/LLM-related attack surface. Install the latest binary release directly from GitHub:
wget https://github.com/projectdiscovery/nuclei/releases/download/v3.9.0/nuclei_3.9.0_linux_amd64.tar.gz
tar -xzf nuclei_3.9.0_linux_amd64.tar.gz
sudo mv nuclei /usr/local/bin/
nuclei -version
# Pull the current template set before your first run
nuclei -update-templatesRun it against any HTTP service your lab target exposes:
# Basic scan against a single target, using the default severity filter
nuclei -u http://192.168.56.101 -o nuclei-results.txt
# Restrict to high and critical severity templates for a faster, focused pass
nuclei -u http://192.168.56.101 -severity high,critical -o nuclei-critical.txtNuclei’s output includes the template ID it matched, which often maps directly to a CVE number, plus the exact request that triggered the match, which makes verifying a finding by hand much faster than with a traditional scanner. Update templates before every real scan (not just your first one) since new templates ship continuously as fresh CVEs get disclosed.
Step 7: Cross-Check With Nessus Essentials (Optional but Useful)
No single scanner catches everything, and running a second engine against the same target is a fast way to spot false positives and false negatives in your primary tool. Nessus Essentials, Tenable’s free tier, is worth adding for that cross-check even though it is capped to a small number of scannable IP addresses, which makes it useless for anything beyond a single host or a small lab, but sufficient for validating findings from Greenbone and Nuclei.
Download the Nessus Essentials installer from Tenable’s site, register for a free activation code, and install the .deb package on Ubuntu 24.04:
sudo dpkg -i Nessus-latest-ubuntu1404_amd64.deb
sudo systemctl start nessusd
sudo systemctl enable nessusdNessus runs its own web interface on port 8834. Complete the setup wizard, enter your free activation code, let the plugin feed download, then create a Basic Network Scan against your lab target the same way you configured a task in Greenbone. Compare the two reports side by side once both finish. Findings that show up in both tools deserve priority. Findings unique to one tool are worth a manual look before you dismiss or escalate them.
What Scan Output Actually Looks Like
Reading raw scanner output for the first time can be disorienting, so here is what a real (redacted) result looks like from each tool against a lab target running an outdated service. Nmap’s --script vuln output against a vulnerable FTP daemon looks like this:
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.3.4
| ftp-vsftpd-backdoor:
| VULNERABLE:
| vsFTPd version 2.3.4 backdoor
| State: VULNERABLE (Exploitable)
| IDs: CVE:CVE-2011-2523
| Description:
| vsFTPd version 2.3.4 backdoor, blah trigger
| Disclosure date: 2011-07-03
|_ Exploit results
Nmap done: 1 IP address (1 host up) scanned in 42.18 secondsA Greenbone report exported to CSV shows the same class of finding with its own severity metadata attached, independent of NVD:
IP,Hostname,Port,NVT Name,Severity,CVSS,CVE,Solution Type
192.168.56.101,metasploitable,21/tcp,VSFTPD Compromised Source Packages Backdoor Vulnerability,High,10.0,CVE-2011-2523,Mitigation
192.168.56.101,metasploitable,445/tcp,Samba Badlock Vulnerability,Medium,5.9,CVE-2016-2118,VendorFixAnd Nuclei’s terminal output against a web application with an exposed configuration file, using its default coloring stripped out for readability:
[exposed-config-file] [http] [medium] http://192.168.56.101/config.php.bak
[git-config] [http] [medium] http://192.168.56.101/.git/config
[apache-detect] [http] [info] http://192.168.56.101 [Apache/2.2.8]
[CVE-2011-2523] [http] [critical] http://192.168.56.101:21 [vsFTPd 2.3.4 backdoor]Notice the pattern across all three: severity, an identifier tying back to a specific CVE where one exists, and enough context to confirm the finding by hand before you escalate it. That confirmation step matters because scanner severity ratings still lean heavily on CVSS v3.x across most feeds today. The newer CVSS v4.0 specification from FIRST improves how scoring accounts for exploitability and downstream impact, but as of September 2026 most scan feeds, including the ones behind Nmap’s NSE scripts and Greenbone’s NVTs, still report predominantly v3.x scores, so do not expect the newer methodology to show up consistently in your reports yet.
Step 8: Understand the Tooling Landscape Before You Standardize
Before locking in a permanent toolchain, it helps to see the free options side by side, especially since the commercial side keeps shipping fast: Fortinet pushed its FortiCNAPP Vulnerability Scanner to version 0.29.0 in June 2026, and N-able announced software-scanner.exe 6.14.6 for its vulnerability management line alongside the N-central 2026.2 general release on June 26, 2026. Each free tool covered here earns its place in a different part of the workflow rather than competing head-to-head with those paid platforms.
| Tool | Current version (Sep 2026) | Best for | Cost | Key limit |
|---|---|---|---|---|
| Nmap | 7.991 (upstream); ~7.94 via Ubuntu 24.04 APT | Host/port discovery, NSE vuln scripts | Free, open source | No central reporting or ticketing |
| Greenbone/OpenVAS CE | Community Containers, 160,000+ NVTs | Full network + host vulnerability assessment | Free, open source | Docker/Postgres overhead; slower on large ranges |
| Nuclei | v3.9.0 (Jun 10, 2026); templates v10.4.3 (May 2026) | Web app/API/CVE template checks | Free, open source | Only as good as its template coverage |
| Nessus Essentials | Current free tier | Cross-checking small lab targets | Free, capped IP count | Not viable for full networks |
| Nessus Professional / Tenable.io | Current commercial release | Enterprise scanning at scale | Paid, per-year license | Licensing cost scales with asset count |
A workable free stack for most small teams looks like Nmap for discovery, Greenbone for the deep host and network pass, and Nuclei for anything with an HTTP front end. That covers the same ground commercial platforms like Tenable and Qualys sell as an all-in-one product, just without the unified dashboard and support contract.
Step 9: Read Results Without Trusting a Single Severity Score
This is the step most tutorials skip, and it is the one that matters most given the state of NVD enrichment this year. CVSS gives you a severity number, but that number is only as good as the data feeding it, and the inspector general’s June 2026 review found NVD’s severity scores wrong 88% of the time in the sample it checked. Do not treat a bare CVSS score as your prioritization system. Cross-reference three signals instead: the CVSS base score your scanner reports, whether the CVE appears in CISA’s Known Exploited Vulnerabilities catalog (meaning it has confirmed active exploitation), and whether the affected service is internet-facing or internal-only.
A handful of real 2025-2026 CVEs illustrate why this matters, and they double as realistic examples if you want to test detection logic in a lab you control (never against a live target):
| CVE | Affected product | CVSS | Why it matters |
|---|---|---|---|
| CVE-2025-5777 | Citrix NetScaler ADC/Gateway | 9.3 | Out-of-bounds memory read on a common perimeter appliance |
| CVE-2026-24061 | GNU Inetutils telnetd | Critical | Auth bypass tied to Qilin ransomware activity, dozens of public exploits |
| CVE-2026-34621 | Adobe Acrobat | High/Critical | Prototype pollution RCE, client-side attack surface scanners often miss |
| CVE-2026-41940 | cPanel & WHM | Critical | Auth bypass linked to ransomware and Mirai botnet exploitation |
| CVE-2026-20127 / -20128 | Cisco Catalyst SD-WAN Manager | Critical | Auth bypass and account takeover, exploited in the “XenShell” campaign |
None of these are hypothetical. Every one has documented active exploitation, per the vulnerability trackers that follow routinely targeted CVEs. A scanner that flags a CVSS 9.3 finding on an internal, firewalled test server deserves less urgency than a CVSS 7.5 finding on a public-facing login page that also happens to be sitting on CISA’s KEV list. Build your triage order around exploitation evidence and exposure, not the raw number alone.
Step 10: Build a Complete Working Project: Automated Weekly Scan Pipeline
A one-time scan tells you where you stood on the day you ran it. Given how fast exploitation now follows disclosure, industry research in 2026 has pointed to attackers beginning exploitation within days or weeks of a CVE going public, not months, which is the case for running scans on a schedule instead of once a year during an audit. Here is a complete, working automation project that ties Nmap, Nuclei, and Greenbone’s command-line interface together into a weekly cron job with basic diffing so you only get alerted about new findings.
First, install the Greenbone Vulnerability Management command-line tool so you can trigger scans and pull reports without the web UI:
sudo apt install -y gvm-tools
pip3 install python-gvmNext, save this as weekly-scan.sh. It runs an Nmap sweep, a Nuclei pass with updated templates, diffs the results against last week’s run, and emails a summary only when something new shows up:
#!/bin/bash
# weekly-scan.sh - automated vulnerability scan pipeline
set -euo pipefail
TARGET="192.168.56.101"
DATE=$(date +%Y-%m-%d)
SCAN_DIR="/opt/vuln-scans/${DATE}"
LAST_DIR="/opt/vuln-scans/latest"
mkdir -p "$SCAN_DIR"
echo "[*] Running Nmap discovery + NSE vuln scripts..."
nmap -sV --script vuln -oN "${SCAN_DIR}/nmap.txt" "$TARGET"
echo "[*] Updating Nuclei templates..."
nuclei -update-templates -silent
echo "[*] Running Nuclei scan..."
nuclei -u "http://${TARGET}" -severity high,critical -o "${SCAN_DIR}/nuclei.txt" -silent
echo "[*] Diffing against last scan..."
if [ -d "$LAST_DIR" ]; then
DIFF=$(diff "${LAST_DIR}/nuclei.txt" "${SCAN_DIR}/nuclei.txt" || true)
if [ -n "$DIFF" ]; then
echo "New or changed findings detected:" > "${SCAN_DIR}/diff-summary.txt"
echo "$DIFF" >> "${SCAN_DIR}/diff-summary.txt"
mail -s "New vulnerability scan findings: ${DATE}" [email protected] < "${SCAN_DIR}/diff-summary.txt"
else
echo "[*] No new findings since last scan."
fi
fi
rm -rf "$LAST_DIR"
cp -r "$SCAN_DIR" "$LAST_DIR"
echo "[*] Scan complete. Results in ${SCAN_DIR}"Make it executable and schedule it with cron to run every Monday at 3 a.m.:
chmod +x /opt/vuln-scans/weekly-scan.sh
crontab -e
# Add this line:
0 3 * * 1 /opt/vuln-scans/weekly-scan.sh >> /var/log/weekly-scan.log 2>&1That is a full, working project: a reproducible scan, a diff step so you are not re-reading identical results every week, and an alert path so new findings actually reach someone. Extend it by piping nuclei.txt and nmap.txt into a ticketing system's API, or by adding a Greenbone task trigger via gvm-cli for a deeper weekly pass alongside the faster Nmap/Nuclei checks.
Step 11: Triage, Assign, and Track Remediation
A scan report that sits in a folder does nothing. Every finding needs an owner, a deadline, and a status. Start with a simple rule set: critical findings on internet-facing systems get a 48-hour remediation window, high findings get a week, medium findings get a month, and low findings get tracked but not chased. Adjust those windows to match your organization's actual risk tolerance and change-management process, but write the rule down so triage does not depend on whoever happens to read the report first.
Feed confirmed findings into whatever your team already uses for tracking work, whether that is Jira, a GitHub Issues board, or a spreadsheet if you are a team of one — at the far end of that spectrum, dedicated findings-management platforms like Seemplicity were already processing 1.5 billion security findings a day as of August 2025, which gives a sense of how much volume this closed loop needs to absorb once scanning runs at real organizational scale. The goal is a closed loop: scan finds it, someone owns it, someone fixes it, the next scan confirms it is gone. Skipping that last confirmation step is how the same finding shows up in six consecutive monthly reports without anyone noticing it was never actually patched.
Step 12: Schedule Recurring Scans and Rotate Scope
Weekly automated scans, as set up in Step 10, cover your core infrastructure. Add a monthly full-depth pass with Greenbone's "Full and deep" scan config (slower, more thorough than "Full and fast") for anything that does not need real-time coverage, and a quarterly authenticated scan where the scanner logs into hosts with read-only credentials to check package versions directly rather than guessing from network banners. Authenticated scans catch far more than unauthenticated ones because they read installed package metadata instead of inferring versions from network responses, which is often wrong on hardened or reverse-proxied services.
Rotate your scan scope too. If your inventory is growing, a scan that only ever targets the same twenty servers will never catch the twenty-first one someone spun up last month and forgot to register. Pair your vulnerability scanner with an asset-discovery pass (even a scheduled full Nmap sweep of your entire IP range works) so shadow infrastructure gets pulled into scope automatically instead of staying invisible until it gets breached.
5 Common Pitfalls When Running Your First Vulnerability Scan
- Scanning without authorization or a documented scope. Even an internal scan against the wrong subnet can trigger an incident response process, alert a SOC team, or violate policy. Get the sign-off in writing before the first packet leaves your scanner.
- Running a full, aggressive scan against production during business hours. Some NSE scripts and vulnerability checks are intentionally intrusive and can crash fragile services. Schedule aggressive scans for maintenance windows, and use lighter, non-intrusive scan profiles for anything customer-facing during the day.
- Trusting raw CVSS scores as your only prioritization signal. Given how unreliable NVD's own severity data has been shown to be in 2026, a bare CVSS number without exploitation and exposure context leads teams to chase low-risk findings while ignoring actively exploited ones.
- Never updating scanner feeds or templates before a run. An out-of-date NVT feed or Nuclei template set means you are scanning against last month's threat landscape. Update before every scheduled run, not just the first one.
- Treating a single scan as done. New CVEs publish daily, new services get deployed constantly, and a scan from three months ago tells you almost nothing about your risk today. Scanning is a cadence, not a one-time checkbox.
Troubleshooting: 8 Common Issues and Fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Greenbone containers won't start | Insufficient RAM or Docker daemon not running | Confirm Docker is active with systemctl status docker; allocate at least 4GB RAM to the host |
| Web UI at :9392 times out | gsad container still starting, or firewall blocking the port | Check docker compose ps for container health; open port 9392 locally with ufw allow 9392 |
| Feed sync never completes | Slow or interrupted network connection during initial NVT download | Re-run docker compose up -d; check logs with docker compose logs -f for stalled downloads |
| Nmap reports every port as filtered | Host-based firewall on the target, or scanner running without sudo | Re-run with sudo; temporarily disable the target's firewall in your isolated lab only |
| Nuclei returns zero results on a known-vulnerable target | Outdated templates | Run nuclei -update-templates before every scan |
| Nessus Essentials activation fails | Expired or already-used activation code | Request a fresh code from Tenable's site; each free code ties to one install |
| Scan takes far longer than expected | Full port range plus deep NVT checks on a large target list | Narrow the port range for routine scans; reserve full-range deep scans for monthly passes |
| Cron job in Step 10 never runs | Script not executable, or cron using a different PATH than your shell | Confirm chmod +x was applied; use absolute paths for every binary inside the script |
Advanced Tips: Cutting False Positives and Feeding a SIEM
Once the basic pipeline runs reliably, three upgrades pay off fast. First, switch from unauthenticated to authenticated scanning wherever you control the target's credentials. Greenbone supports SSH and SMB credential-based scanning, which reads actual installed package versions instead of guessing from network banners, cutting false positives dramatically on hardened or proxied hosts. Second, export scan results in a structured format (Greenbone supports XML and CSV export, Nuclei supports JSON with the -jsonl flag) and forward them into whatever log pipeline your team already runs, whether that is a SIEM, Elasticsearch, or a simple log aggregator. Correlating scan findings against actual traffic and authentication logs turns a static report into something you can query alongside real incidents.
Third, do not rely on CISA's KEV catalog or NVD alone for exploitation context, since both have documented gaps and delays this year. Supplement with independent trackers that publish routinely-targeted-vulnerability data, cross-referencing scanner output against real exploitation telemetry rather than a single government feed. And if you eventually outgrow the free stack, the money is increasingly flowing toward automation layered on top of scanning rather than scanning alone — Mondoo raised $17.5M in September 2025 specifically to build out an agentic vulnerability management platform — so an enterprise scanner with broader plugin coverage and native compliance reporting, like the tools compared in this Tenable vs Qualys vs Rapid7 breakdown, becomes worth the license cost once your asset count and compliance obligations grow past what Nmap, Greenbone, and Nuclei can comfortably handle on their own.
Where Vulnerability Scanning Fits Into a Broader Security Program
Scanning is one layer, not a complete security program. Container images need their own scanning pass, since a clean host-level scan says nothing about a vulnerable base image sitting inside your Docker registry, which is why tools like Trivy exist specifically for that layer (see how to scan container images with Trivy for that workflow). Malware detection and threat hunting depend on a different skill set entirely, built around signature writing rather than CVE matching (covered in how to write YARA rules for malware detection). And a Kubernetes cluster running perfectly patched container images can still be wide open at the orchestration layer if RBAC, network policies, and pod security standards were never locked down, which is its own separate hardening pass (see Kubernetes security hardening).
Vulnerability scanning also feeds directly into government and industry threat intelligence. CISA's KEV catalog exists precisely because raw CVSS scores from NVD were never a reliable enough signal on their own (a problem the 2026 inspector general findings only confirmed), and keeping an eye on what CISA adds to that list (tracked in coverage like this recent CISA KEV update) is a fast way to know which of your scan findings just became genuinely urgent. Treat scanning as the detection layer of a program that also includes patch management, network segmentation, and incident response, not as a standalone checkbox exercise.
Frequently Asked Questions
How often should I run a vulnerability scan?
Weekly automated scans of core infrastructure, with a monthly deeper pass and a quarterly authenticated scan, is a reasonable baseline for most small and mid-sized teams. Given how quickly attackers now move from disclosure to exploitation, annual or quarterly-only scanning leaves too wide a window unpatched.
Is OpenVAS the same thing as Greenbone?
OpenVAS is the open-source scanning engine at the core of Greenbone's product line. Greenbone Community Edition packages that engine, a manager daemon, and a web interface into a free, self-hosted stack. Greenbone also sells paid enterprise appliances built on the same engine with broader support and additional feed content.
Can I run these tools against a system I don't own?
Only with explicit, written authorization from the system's owner. Scanning infrastructure without permission can violate computer-misuse laws even when no damage occurs, because unauthorized access itself is typically the offense, not just unauthorized damage.
Why did my scan find fewer issues than a commercial tool like Nessus Professional or Qualys?
Commercial platforms typically maintain larger, more frequently updated plugin libraries and dedicated research teams writing new checks, and they often include authenticated scanning and compliance templates out of the box. The free stack in this tutorial closes most of that gap for a small environment, but a large enterprise with strict compliance requirements will usually outgrow it.
What's the difference between a vulnerability scan and a penetration test?
A vulnerability scan is automated detection: it flags known weaknesses by matching software versions and responses against a database. A penetration test is manual (or semi-manual) exploitation, where a tester actually tries to chain findings together to prove real-world impact, like reaching a database from an exposed web app. Scanning is cheaper and faster to run often. Pentesting is deeper but expensive to run frequently.
Should I trust the CVSS score my scanner reports?
Use it as one input, not the whole decision. A June 2026 US Commerce Department inspector general report found NVD's own severity scores wrong 88% of the time in its sample. Cross-reference CVSS against whether a CVE is listed on CISA's Known Exploited Vulnerabilities catalog and whether the affected asset is internet-facing before deciding what to fix first.
Does Nuclei replace Nmap or Greenbone?
No. Nuclei is a complement, not a replacement. It excels at fast, template-based checks against web applications, APIs, and specific CVE signatures in HTTP responses. Nmap and Greenbone cover the broader network and host layer, including services with no web interface at all. A complete free stack uses all three together.
What should I do if a scan finds a critical vulnerability on a production system?
Verify the finding manually before you escalate, since false positives happen. Once confirmed, check whether the CVE is listed on CISA's KEV catalog to gauge active exploitation risk, apply a vendor patch or documented workaround as fast as your change-management process allows, and if immediate patching isn't possible, consider temporary network-level mitigation like restricting access to the affected service while remediation is in progress.
Related Coverage
- Set Up Content Security Policy: 12 Steps, 90 Min [2026]
- How to Encrypt Files: 12 Steps, 90 Min [2026]
- How to Scan Container Images With Trivy: 12 Steps [2026]
- Block API Credential Stuffing: 12 Steps, 100 Min [2026]
- Steam Guard Setup: Block Account Hacks in 12 Steps [2026]
