OpenVAS: A Deep Dive into Open-Source Vulnerability Scanning

Finding vulnerabilities before attackers do.

OpenVAS — the Open Vulnerability Assessment Scanner — is the world's most widely deployed open-source vulnerability scanner. Originally forked from Nessus when Tenable moved to a proprietary licence in 2005, OpenVAS has grown into a comprehensive scanning engine backed by over 180,000 Network Vulnerability Tests (NVTs) and maintained by Greenbone Networks under the Greenbone Vulnerability Management (GVM) framework.

Where Nmap tells you what is running, OpenVAS tells you what is wrong with it. It probes discovered services against a continuously updated database of known vulnerabilities, misconfigurations, default credentials, missing patches, and policy violations — then produces structured results that map directly to CVEs, vendor advisories, and compliance frameworks.

For penetration testers, OpenVAS serves a specific and important role: it provides broad, automated coverage across large target sets, identifies the low-hanging fruit that every competent attacker would find, and — critically — frees the tester to spend their limited engagement time on the manual exploitation, chain analysis, and business-context work that no scanner can replicate. It is not a replacement for manual testing. It is the foundation that makes manual testing efficient.

Understanding the GVM stack.

OpenVAS is not a single binary. It is one component within the Greenbone Vulnerability Management (GVM) framework — a collection of services that work together to manage feeds, schedule scans, store results, and present findings. Understanding this architecture matters because most troubleshooting — scans that hang, feeds that fail to update, results that seem incomplete — traces back to a misconfigured or unhealthy component in this stack.

The data flow is straightforward: you create a scan task via the GSA web interface (or the gvm-cli command line tool). gvmd receives the task, passes it to ospd-openvas, which launches the openvas-scanner process. The scanner loads NVTs from its feed, pulls runtime data from Redis, probes the targets, and writes results back through ospd-openvas to gvmd, which stores them in PostgreSQL. The web interface queries gvmd to display results.

Getting a production-ready deployment.

OpenVAS can be installed from source, from distribution packages, or — most commonly for professional use — via Docker containers provided by Greenbone. The containerised deployment is strongly recommended: it manages the complex inter-service dependencies, ensures compatible versions, and simplifies feed updates. For Ubuntu, the installation workflow uses Docker Compose.

Your scanner is only as good as its last update.

OpenVAS relies on four distinct data feeds, each serving a different purpose. A scanner running stale feeds is worse than useless — it provides false confidence. Feed currency should be verified before every engagement.

The Greenbone Community Feed is free and comprehensive but updates are delayed by approximately two weeks compared to the Greenbone Enterprise Feed. For professional engagements where the latest CVEs matter — and they always matter — this delay should be understood and communicated to clients. If a critical CVE was published last week, the Community Edition may not yet have a check for it.

Choosing what to test and how aggressively.

OpenVAS ships with several pre-built scan configurations that control which NVTs are executed. Choosing the correct configuration is one of the most important decisions in any scanning engagement — too light and you miss vulnerabilities, too aggressive and you risk service disruption or spend days scanning when the engagement window is measured in hours.

Beyond the pre-built configurations, professional testers frequently create custom scan configurations. This is done through Configuration → Scan Configs → Clone (clone an existing config, then modify). Common customisations include disabling NVT families irrelevant to the target (there is no value running Windows checks against a Linux-only environment), enabling specific brute-force modules against in-scope authentication services, adjusting concurrent host and NVT limits based on target network capacity, and adding custom NASL scripts for organisation-specific checks.

The difference between looking at the door and walking through it.

An unauthenticated scan examines a target from the outside — it can see open ports, identify services, detect remotely exploitable vulnerabilities, and check for misconfigurations visible to an anonymous connection. A credentialed scan logs into the target with valid credentials and examines it from the inside — installed software versions, missing patches, local privilege escalation paths, configuration file contents, registry settings, and file permissions.

The difference in coverage is dramatic. An unauthenticated scan of a typical Windows server might identify 5–15 findings. A credentialed scan of the same server routinely identifies 50–200. This is not because the scanner is inventing problems — it is because the vast majority of vulnerabilities are not visible from the network. They require local access to detect: a missing KB patch, an outdated third-party application, a weak registry setting, a world-readable credential file.

From target definition to actionable results.

The operational workflow in OpenVAS follows a consistent pattern: define targets, select or create a scan configuration, optionally attach credentials, create a task that binds these together, and execute the task. Each element is reusable — you can run the same configuration against different targets, or the same targets with different configurations.

Scan duration depends on target count, port range, scan configuration, network latency, and concurrency settings. A Full and Fast credentialed scan of a /24 network (approximately 254 hosts) with default concurrency settings typically takes 4–8 hours. Increasing Max Hosts reduces wall-clock time but increases network load — on shared production networks, aggressive concurrency can trigger IDS alerts, overwhelm switches, or cause service degradation. For production environments, start conservative and increase only after confirming network stability.

Automation and scripted workflows.

The GSA web interface is effective for interactive use, but professional engagements often require automation — scheduled scans, API-driven workflows, integration with ticketing systems, or batch operations across multiple targets. The gvm-cli tool communicates directly with gvmd via the Greenbone Management Protocol (GMP), providing full programmatic control over every function available in the web interface.

The Python API (python-gvm) is particularly powerful for engagement workflows. Common automations include: creating targets and tasks from a scope spreadsheet, launching scans at the start of an engagement window, polling for completion and automatically exporting results, parsing XML results into custom report templates, and feeding confirmed vulnerabilities into Metasploit's database for exploitation planning.

Separating signal from noise.

A typical credentialed scan of a /24 network produces hundreds to thousands of individual findings. Not all of them are real, not all of them matter, and understanding the difference is what separates a useful vulnerability assessment from a data dump. OpenVAS categorises each finding with a severity score, a quality of detection (QoD) rating, and detailed technical information that the tester must evaluate.

The Quality of Detection (QoD) rating is equally important and frequently overlooked. It indicates how confident the scanner is in the finding. A QoD of 100% means the scanner exploited the vulnerability or confirmed it definitively. A QoD of 70% means the scanner detected a potentially vulnerable version but could not confirm exploitability. A QoD of 30% means the detection is based on banner information alone — and banners can be misleading. Findings with QoD below 70% require manual verification before reporting.

Policy checks beyond vulnerability scanning.

OpenVAS is not limited to vulnerability detection. Through its compliance auditing capabilities, it can evaluate systems against defined security policies — checking configuration baselines, required settings, installed software, and security controls. This is particularly valuable for organisations operating under regulatory frameworks where demonstrable compliance is a requirement.

Compliance audits require credentialed access to the target systems. The audit results appear alongside vulnerability scan results but are categorised separately, showing pass/fail/error status for each policy check rather than vulnerability severity ratings. For penetration testing engagements, compliance audit results add valuable context: a system that fails CIS benchmark checks for password complexity, account lockout, and audit logging is far more likely to be compromised through the credential-based attack paths the tester is evaluating.

OpenVAS in a real engagement workflow.

OpenVAS does not operate in isolation during a penetration test. It is one tool in a coordinated workflow that begins with Nmap for discovery, uses OpenVAS for broad vulnerability identification, feeds confirmed targets into Metasploit for exploitation, and produces results that are combined with manual findings into the final report. The integration points between these tools determine how efficiently the engagement runs.

The key insight is phasing: OpenVAS runs during downtime (overnight, during Nmap enumeration) so that its results are available when the tester begins manual work. Running OpenVAS on day three of a five-day engagement wastes time. Running it on day one — while the tester is still mapping the environment — ensures that vulnerability data is ready precisely when it is needed.

Making scans faster without breaking things.

OpenVAS scan performance is determined by four factors: scanner concurrency settings, Redis configuration, PostgreSQL performance, and network conditions. Tuning these correctly can reduce scan times from hours to minutes for small networks, or from days to hours for large estates.

Troubleshooting when scans go wrong.

Where it fits in the scanning landscape.

OpenVAS competes with commercial vulnerability scanners — primarily Nessus (Tenable), Qualys VMDR, and Rapid7 InsightVM. Understanding its strengths and limitations relative to these tools helps testers choose the right scanner for the right engagement.

For penetration testing firms, the practical answer is often: use both. OpenVAS provides comprehensive coverage at zero marginal cost — especially valuable when scanning large networks where per-asset commercial licensing becomes prohibitive. Commercial scanners supplement with faster feeds, better reporting, and broader coverage of niche platforms. The scanner results are inputs to the tester's work, not the deliverable — the tool matters less than the skill interpreting its output.

Detecting and monitoring vulnerability scans.

If your organisation has deployed detection and monitoring capabilities, vulnerability scans — whether authorised or not — should be visible. Understanding what OpenVAS looks like on the wire helps defenders validate that their monitoring is working and helps testers understand what footprint they are leaving.

The commands you'll use every engagement.

The bottom line.

OpenVAS is the most capable open-source vulnerability scanner available. It provides broad, automated coverage that identifies known vulnerabilities, misconfigurations, default credentials, and compliance deviations across large network estates. For penetration testing engagements, it serves as the foundation layer — identifying the attack surface that manual testing then explores, exploits, and chains into the business-risk narratives that define a professional report.

Its limitations are real and important: it detects known vulnerabilities, not unknown ones. It identifies individual issues, not attack chains. It tests what the feed knows about, not what has been published since the last sync. It reports what it finds, not what it means. Every finding requires human judgement — verification, contextualisation, and prioritisation based on the specific organisation's architecture, threat model, and risk appetite.

The difference between a vulnerability scan report and a penetration test report is the human intelligence applied after the scanner finishes. OpenVAS generates the data. The tester generates the insight. Used correctly, it is the most cost-effective way to ensure that no engagement misses the obvious — leaving the tester's time and expertise for the work that actually matters.