# OpenVAS
OpenVAS (Open Vulnerability Assessment Scanner) is a free, open-source vulnerability scanning engine maintained by Greenbone Networks as the community-accessible core of the Greenbone Vulnerability Management (GVM) framework. It exists because organizations of every size need a reliable, repeatable method to identify exploitable weaknesses across their networks before attackers do. The problem OpenVAS solves is straightforward: unpatched software, misconfigured services, and default credentials are the most common entry points in real-world breaches, and most organizations lack continuous visibility into how many of those conditions exist on their own infrastructure. OpenVAS provides that visibility at no licensing cost, making credible vulnerability management accessible to security teams that cannot afford commercial scanners. It is not a complete security program on its own, but it is an essential instrument in any program that takes exposure reduction seriously.
---
OpenVAS is a network-based vulnerability scanner that executes automated tests against network hosts to identify known vulnerabilities, service misconfigurations, weak authentication, and compliance deviations. It operates as the scanning engine within the broader GVM framework, which also includes the Greenbone Vulnerability Manager (gvmd) for orchestration, a PostgreSQL database for result storage, and the Greenbone Security Assistant (GSA) web interface for operator interaction.
OpenVAS is not a penetration testing framework. It does not exploit vulnerabilities to achieve access; it detects and reports their presence. This distinction matters operationally: OpenVAS produces a prioritized list of findings that a human operator or remediation workflow must act on. It does not produce shells, pivot through networks, or demonstrate business impact the way a full red team engagement does.
OpenVAS is also not an intrusion detection system. It performs point-in-time or scheduled active scans rather than monitoring live traffic for attack patterns. Organizations sometimes conflate the two because both produce security findings, but they answer different questions. An IDS asks "is someone attacking right now?" while OpenVAS asks "what conditions exist that would allow an attack to succeed?"
The Greenbone Community Edition (GCE) distributes OpenVAS with the community NVT feed, which is updated regularly. The commercial Greenbone Enterprise product adds the Greenbone Enterprise Feed, which includes additional tests, compliance content, and faster update cycles. For the purposes of this article, OpenVAS refers to the open-source community edition unless otherwise specified.
OpenVAS is distinct from other open-source scanners such as Nikto (focused exclusively on web servers), Lynis (focused on local host auditing), and Nmap (a network mapping and port discovery tool without a deep vulnerability test library). OpenVAS combines broad network reachability scanning with a large NVT library, authenticated internal inspection, and structured result management in a single platform.
---
OpenVAS executes vulnerability assessment through a structured pipeline that moves from target discovery through test execution to result storage and reporting. Understanding each stage helps operators configure scans correctly and interpret results accurately.
Target Definition and Scope Configuration
Every scan begins with a target definition: one or more IP addresses, CIDR ranges, or hostnames that the scanner will probe. The operator also selects a scan configuration, which is a named collection of NVT families and individual test selections. GVM ships with several default configurations including "Full and Fast," which runs all NVTs with safe detection methods, and "Full and Very Deep," which includes more intrusive checks at the cost of longer scan durations and some risk of service disruption on fragile hosts. Operators managing production environments should test scan configurations against non-production hosts first to validate that intrusive checks do not cause service interruptions.
Port Scanning and Service Detection
Before NVTs execute, the scanner performs port discovery to identify open TCP and UDP ports on each target host. OpenVAS uses its own internal port scanner or can call out to Nmap for this phase. Service detection follows port discovery: the scanner sends protocol-specific probes to determine what application is listening on each open port. A port identified as running Apache HTTP Server version 2.4.49, for example, immediately flags a set of CVEs associated with that version for testing in the subsequent phase.
NVT Execution
The core of OpenVAS is its library of Network Vulnerability Tests written in NASL (Nessus Attack Scripting Language). Each NVT is a self-contained script that targets a specific condition: a particular CVE, a class of misconfiguration, a default credential pair, or a compliance requirement. The GVM scheduler assigns NVTs to detected services based on the service fingerprint and the selected scan configuration. NVTs run concurrently within limits set by the operator to control load on both the scanner and the target network.
A concrete example: a scan against a Linux server running OpenSSH 7.4 will trigger NVTs that test for CVE-2016-10009 (a privilege escalation via ssh-agent forwarding), CVE-2017-15906 (a file creation vulnerability), and several others documented against that version. Each NVT returns a result of High, Medium, Low, Log, or False Positive based on detection confidence and CVSS scoring.
Authenticated Scanning
Unauthenticated scans assess what an external attacker without credentials can detect. Authenticated scans go further by logging into target systems and inspecting installed package versions, file permissions, registry entries, and local configuration files. OpenVAS supports SSH credentials for Linux and Unix hosts, SMB credentials for Windows hosts, and ESXi credentials for VMware environments. Authenticated scans are significantly more accurate because they inspect the actual installed state of software rather than inferring it from banner strings, which can be modified or suppressed.
A practical scenario: an unauthenticated scan of a Debian server may not detect that a locally installed library is out of date if the service does not expose a version banner. An authenticated scan using a read-only SSH key will inspect the package database directly, identify that libssl is two minor versions behind the current security release, and generate a finding with the relevant CVE reference, CVSS score, and remediation step (apt-get upgrade libssl).
Result Storage and Reporting
All scan results are stored in a PostgreSQL database managed by gvmd. Results include the CVE identifier, CVSS base score, quality of detection (QoD) rating, affected host and port, a textual description of the vulnerability, and remediation guidance. QoD ratings are an OpenVAS-specific metric that indicates confidence in the detection method: a QoD of 99 means the test confirmed the vulnerability with certainty, while a QoD of 30 means the detection is based on indirect inference and requires manual verification.
The GSA web interface allows operators to view results by host, severity, CVE, or NVT family. Delta reports compare two scan results to show newly introduced vulnerabilities, resolved findings, and unchanged conditions. This delta capability is critical for tracking remediation progress over time and for demonstrating to management that vulnerability counts are moving in the right direction.
Scheduling and Integration
OpenVAS supports scheduled scans, allowing organizations to run weekly or monthly baseline scans automatically. The GVM API (using the GMP protocol over XML) allows integration with SIEM platforms, ticketing systems, and SOAR playbooks so that critical findings automatically generate remediation tickets or trigger alert workflows without manual operator intervention.
---
Vulnerability scanning is not optional for any organization that handles sensitive data, operates internet-facing systems, or falls under regulatory requirements such as PCI DSS, HIPAA, or SOC 2. OpenVAS provides the scanning capability necessary to meet those requirements without a per-host licensing fee that makes commercial scanners impractical for smaller organizations or large, dynamic environments.
The business case is simple: the cost of identifying and patching a known vulnerability before exploitation is almost always lower than the cost of responding to a breach. The 2021 compromise of Kaseya VSA, which affected over 1,500 downstream managed service provider customers, involved vulnerabilities that had been disclosed and were patchable. Authenticated vulnerability scanning of the Kaseya VSA instances would have identified those conditions before attackers did. The breach resulted in ransom demands exceeding $70 million and operational disruption across thousands of businesses. This is not a hypothetical risk class; it is the documented consequence of skipping routine vulnerability assessment.
A common misconception is that running a vulnerability scanner once at the start of a compliance cycle satisfies the intent of vulnerability management. It does not. Networks change continuously: new hosts are provisioned, software is updated (or not updated), configurations drift, and new CVEs are published daily. A scan result from 90 days ago describes the security posture of a different network. Continuous or frequent scanning is the only method that produces an accurate picture of current exposure.
A second misconception is that low and medium severity findings can be deferred indefinitely. Attackers chain findings. A medium-severity misconfiguration that allows service enumeration combined with a low-severity information disclosure finding and a default credential on an internal service can together provide a path to full domain compromise. Treating severity ratings as absolute prioritization criteria without considering chaining potential leads to systematically underestimating risk.
OpenVAS matters specifically because it removes the cost barrier to credible vulnerability management. Organizations that argue they cannot afford vulnerability scanning should understand that OpenVAS represents a significant capability available at no licensing cost, requiring only the operational investment to deploy, configure, and act on results.
---
CDA approaches vulnerability scanning through the Planetary Defense Model, specifically within the Vulnerability Surface Detection (VSD) domain. The governing methodology is Continuous Surface Reduction (CSR), expressed as a single operational commitment: "Every surface you expose is a surface we eliminate."
OpenVAS is a primary instrument in that commitment. CDA deploys OpenVAS as a recurring, authenticated scanning platform integrated into client environments with the following operational standards.
First, CDA requires authenticated scanning for all hosts where credentials can be supplied. Unauthenticated scans are acceptable for initial discovery and for systems where credential management is not yet in place, but they are treated as an incomplete baseline, not a satisfactory ongoing practice. The accuracy gap between authenticated and unauthenticated scanning is too large to accept as a steady state.
Second, CDA integrates OpenVAS findings directly into the client's remediation ticketing workflow using the GMP API. Critical and High findings generate tickets automatically within 24 hours of scan completion. Medium findings are aggregated into weekly remediation reviews. This removes the manual step of exporting reports and distributing them by email, which creates delays and loss of accountability.
Third, CDA uses delta reports as the primary accountability mechanism in client status reporting. Rather than reporting raw vulnerability counts, which fluctuate based on scan scope changes, CDA reports the number of new findings introduced since the last scan, the number of findings closed, and the net change. This gives clients and their leadership an accurate picture of whether their remediation programs are keeping pace with newly discovered conditions.
Fourth, CDA applies OpenVAS within a broader SPH (Security Posture Hardening) workflow: scan findings feed directly into hardening checklists derived from CIS Benchmarks. When OpenVAS identifies a misconfiguration, the remediation guidance is mapped to the corresponding CIS Control, so operators apply fixes within an established framework rather than treating each finding as an isolated problem.
CDA does not treat OpenVAS as a compliance checkbox. A completed scan with no remediation action is a waste of time and produces false confidence. CDA enforces closure rates as a measured outcome, holding client teams accountable for the proportion of identified findings resolved within agreed timeframes.
---
---
---