OpenVAS Guide: Open Source Vulnerability Scanning With Greenbone

OpenVAS gives organisations a free, open source network vulnerability scanner, but running it safely and getting trustworthy results takes more than starting a container. This guide explains how OpenVAS and the wider Greenbone Community Edition fit together, what the Community Feed does and does not cover, how to deploy and tune scans without disrupting production, how to protect scan credentials and results, and what the licences mean. It is for vulnerability management, infrastructure and security operations teams scanning assets they own or are authorised in writing to test. Attack usage and exploitation are out of scope.

Key takeaways

• OpenVAS is one part of a stack. The scanner runs the vulnerability tests; gvmd manages targets, tasks and results; GSA is the web interface. Greenbone documents them as the Greenbone Community Edition.
• Authorisation comes first. Scan only assets you own or have written permission to test. Unauthorised scanning may be unlawful under laws such as the UK Computer Misuse Act 1990 or the US Computer Fraud and Abuse Act.
• The free feed has gaps by design. Greenbone states that since 2017 the Community Feed excludes vulnerability tests for enterprise products, so coverage of commercial enterprise software is weaker than in the paid feed.
• Safe defaults exist; keep them. The "Full and fast" scan configuration runs with safe_checks=yes and excludes very invasive and denial-of-service tests.
• Credentials make or break results. Authenticated scans see installed software and patch levels; the scan accounts behind them are privileged non-human identities and need vault storage and monitoring.

What the tool does

OpenVAS describes itself as a full-featured vulnerability scanner supporting unauthenticated and authenticated testing, many internet and industrial protocols, performance tuning for large scans and an internal programming language for writing vulnerability tests (VTs). Greenbone has developed it since 2006. Greenbone's current product naming places the scanner in its commercial OPENVAS SCAN product family, and the open source modules together form the Community Edition; the documentation site still uses the name Greenbone Community Edition, with release history running from OpenVAS 9 through GVM 10, 11, 20.08 and 21.4 to Greenbone Community Edition 22.4.

Architecture

The openvas-scanner repository also contains a Rust implementation intended to replace the openvas-scanner, ospd-openvas and notus-scanner stack over time; the container deployment already includes an openvasd service. Expect component names to keep changing between releases, and never mix components from different releases: Greenbone's FAQ warns that gvmd, ospd-openvas and openvas-scanner are especially prone to breaking when mixed.

Community and commercial editions

Defender use cases

• Internal vulnerability scanning: CIS Controls v8.1 Safeguard 7.5 expects internal automated scans at least quarterly, authenticated and unauthenticated. OpenVAS is a common way for smaller teams to meet it without a commercial licence. See the Vulnerability Scanning Guide.
• External exposure checks: Safeguard 7.6 expects externally exposed assets to be scanned at least monthly. Scanning from an outside host shows what the internet sees, and complements discovery from the Attack Surface Management Guide.
• Validating emergency patching: when a widely exploited flaw is disclosed, a targeted rescan confirms which hosts still run vulnerable versions. In the MongoBleed case (CVE-2025-14847), Censys counted more than 87,000 potentially vulnerable MongoDB instances on the internet; the NHIMG page also stresses that patching does not revoke secrets already leaked, so a clean rescan should trigger credential rotation, not close the incident.
• Lab and pre-production checks: scan new builds and images before they reach production, where tuning mistakes cost nothing.
• Training and evaluation: Greenbone positions the container setup for testing and getting familiar with the software, which makes it a low-cost way to learn scanning before choosing a platform.

Findings arrive as CVE references with CVSS scores and a Quality of Detection (QoD) value. Prioritise with exploitation evidence and context rather than base score alone: see the CVSS v4 Guide, the SSVC Guide and the CVE, CWE and CPE Guide.

Deployment and safe use

Authorisation

Hold a written scanning authorisation from the asset owner listing ranges, scanner source addresses, schedules and the scan configurations allowed. The Nmap project's legal guidance, which applies equally to any scanner, notes that legality depends on jurisdiction and that written permission is the safest basis; it also warns that fragile legacy devices can crash during scans. Cloud, hosting and SaaS assets need the provider's testing policy checked or written agreement.

Install and harden the platform

• Choose the right build: Greenbone's container guide states it is not intended for production setups and gives minimum resources of 2 CPU cores, 4 GB RAM and 20 GB storage (recommended 4 cores, 8 GB and 60 GB). For production, use a source build or supported product and size for your target count.
• Change the default admin password: the container setup creates admin with password admin, which the guide calls insecure. Change it before the first scan with gvmd --user=admin --new-password, and create named accounts with roles for each operator.
• Keep the web interface local or behind access control: the container binds GSA to localhost on ports 443 and 9392 with self-signed TLS. Publish it only through an authenticated reverse proxy or management network, with a trusted certificate.
• Understand container privileges: ospd-openvas runs with NET_ADMIN and NET_RAW capabilities and with seccomp and AppArmor confinement disabled. Run it on a dedicated, patched host, not a shared container platform.
• Wait for and monitor the feed: feed data loads after start-up and must be complete before scanning. Schedule greenbone-feed-sync and alert when the last sync is stale; greenbone-nvt-sync is deprecated.

Safe scan settings

For OT and safety systems, prefer passive discovery and vendor-approved methods; see the OT Asset Visibility Guide.

Rollout

1. Scope: build targets from the CMDB with owners, exclusions and maintenance windows. Record them in a change under the Change Management Policy Template.
2. Pilot: run a discovery-only configuration, then Full and fast unauthenticated, on one low-risk subnet. Check device health with owners.
3. Add credentials: attach SSH and SMB credentials for a pilot group and measure the login success rate before expanding.
4. Extend in rings: servers, then user ranges, then external ranges, with fragile segments excluded or on reduced concurrency.
5. Integrate: export results through GMP with gvm-tools into the vulnerability management or ticketing system.
6. Roll back: stop the task, add the affected host to the exclusion list, inform the owner, and review the scan config and concurrency before rescanning.

Where identity fits: scan credentials

Authenticated scans need SSH, SMB, ESXi or SNMP credentials stored in gvmd. Greenbone notes that Windows checks work better with administrative accounts while an unprivileged Linux account sees most relevant data, and that the scanner's login is probably logged on the target. These are privileged non-human identities (NIST SP 800-53 RA-5(5) Privileged Access): use dedicated accounts per zone, least privilege, SSH keys rather than passwords, SNMPv3 rather than community strings, rotation on a schedule, and alerts when a scan account logs in from anywhere other than the scanner or outside the window. See the Service Account Security Guide.

Data handling and licensing

• Results are sensitive: reports list hosts, versions and exploitable weaknesses. Restrict GSA roles, encrypt exports, and apply the Data Retention and Secure Deletion Guide to the PostgreSQL database and report files.
• Licences differ by component: the openvas-scanner README states GPL-2.0-only for the C module (with some files GPL-2.0-or-later, and the Rust code GPL-2.0-or-later with an OpenSSL exception); gvmd and GSA are licensed AGPL-3.0-or-later. The AGPL matters if you modify gvmd or GSA and offer them to others over a network, for example as a managed service. Feed advisories from DFN-CERT and CERT-Bund are provided under a GPL-compatible licence. Confirm terms in each repository before redistributing.

Detection and hardening value

Adversaries run the same checks: ATT&CK lists T1595.002 Vulnerability Scanning and T1046 Network Service Discovery. Register scanner addresses and windows with the SOC so authorised scans are recognised, but keep alerting on scans from any other source. See the SIEM Guide.

Metrics

• Coverage: percentage of CMDB assets scanned within the CIS 7.5 and 7.6 intervals.
• Authenticated success rate: percentage of targeted hosts where credentialed login succeeded.
• Feed freshness: hours since the last successful feed sync.
• Time to remediate: median days from first detection to verified fix, by severity. See the Remediation SLAs and Vulnerability Exceptions Guide.
• Scan safety: scan-related device faults per quarter.

Framework mapping

Alternatives

Small organisations: one well-sized Community Edition host with staggered weekly tasks can meet CIS 7.5 and 7.6. Large organisations: the lack of vendor support, the feed coverage gap and the scale of credential management usually justify a supported product, with OpenVAS kept for labs or second opinions. See the Vulnerability Management Guide.

Common failure patterns

• Default admin password left in place: a scanner holding privileged credentials and a full vulnerability map, protected by admin/admin.
• Stale feed: scans run against an out-of-date VT set and report a clean estate. Alert on feed age.
• Silent credential failure: hosts where authentication failed appear scanned with few findings. Report login success per host.
• Assuming the free feed covers everything: enterprise product checks are excluded from the Community Feed, so absence of findings on commercial software proves little.
• Mixed component versions: upgrading one component from a distribution package breaks the stack; upgrade the release as a whole.
• Treating a clean rescan as closure: as MongoBleed showed, patched hosts may already have leaked secrets that still need rotating.

Practitioner checklist

• Hold written authorisation for every target range, with scanner addresses and windows.
• Change the default admin password and create named, role-based accounts.
• Restrict GSA to a management network or authenticated proxy with a trusted certificate.
• Run the scanner on a dedicated hardened host and keep all components on one release.
• Schedule feed sync and alert when it is stale.
• Use Full and fast with safe checks, add UDP ports deliberately, and exclude fragile devices.
• Store scan credentials as privileged NHIs: dedicated, least privilege, rotated and monitored.
• Track authenticated login success and coverage against CIS 7.5 and 7.6.
• Export results to ticketing and prioritise with exploitation evidence, not CVSS alone.
• Check each component's licence before modifying or offering it as a service.

Standards and references

• Greenbone: Community Edition Architecture and Background
• Greenbone: Community Containers Setup
• Greenbone: Manual, Scanning a System
• OpenVAS: Open Vulnerability Assessment Scanner
• Greenbone: openvas-scanner Repository and Licence
• CIS: Controls v8.1, Control 7 Continuous Vulnerability Management
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Vulnerability Scanning

Related NHI Mgmt Group resources: Vulnerability Scanning Guide · Vulnerability Management Guide · Network Ports and Protocols Security Guide · Risk-Based Vulnerability Management Guide