A new CVE lands in the National Vulnerability Database every few minutes these days. Tenable’s own research counted 48,448 published CVEs in 2025 and projects the 2026 total will land near 59,000, with submissions up 33% year over year in the first quarter alone. If your team is still relying on manual patch audits or a spreadsheet of “known issues,” that gap is where attackers live. The good news: you don’t need a six-figure Tenable or Qualys contract to start closing it. Greenbone’s OpenVAS, distributed today as Greenbone Community Edition, is a free, self-hosted scanner that checks your servers, containers, and network devices against the same kind of vulnerability-test library commercial tools use.
This tutorial walks through a full OpenVAS / Greenbone Community Edition deployment on Docker, from a bare Linux host to a scheduled, authenticated scan producing a report you can hand to a remediation team. It covers prerequisites, 13 concrete setup steps, common pitfalls, troubleshooting for the errors people actually hit, and a complete working Docker Compose reference you can copy directly into a terminal.
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 Is OpenVAS (Greenbone Community Edition)?
OpenVAS started life as a fork of the Nessus engine back when Nessus was still open source. Today, “OpenVAS” refers to the scanner engine itself, while the full product that ships it is called Greenbone Community Edition, maintained by the German company Greenbone AG. It is not one program but a stack of cooperating services: a manager daemon (gvmd) that stores scan configurations and results in PostgreSQL, a web interface (GSA, served through gsad and an nginx front end), the scanning engine itself (openvas-scanner), a control layer called ospd-openvas that lets the manager start and stop scans, and a lightweight engine called Notus Scanner that runs passive version checks during every scan without extra configuration.
All of that logic needs data to work against. Greenbone ships that data as the Community Feed: vulnerability test scripts (NVTs), Notus data, SCAP data, DFN-CERT advisories, and CERT-Bund advisories, each distributed as its own container image that gets pulled and loaded into the stack. The OpenVAS Scanner project itself is on a fast release cadence; GitHub shows version 23.50.24 shipping on September 3, 2026, distributed as the ghcr.io/greenbone/openvas-scanner:stable image, while Greenbone’s broader changelog lists a 26.2.0 component release dated February 24, 2026. Because the Community Containers Compose file pins most services to a stable tag rather than a hardcoded version number, your stack updates automatically each time you pull, which is exactly the behavior you want from a vulnerability scanner.
How the GVM Architecture Fits Together
It helps to understand the data flow before you start clicking through the web interface, because most troubleshooting in this stack comes down to figuring out which layer stalled. When you launch a scan task from GSA, the request travels from gsad to gvmd over the Greenbone Management Protocol (GMP). gvmd doesn’t talk to the scanner directly; it hands the job to ospd-openvas over the OSP (Open Scanner Protocol), which is the layer that actually starts and stops the openvas-scanner process, feeds it the target list and the chosen scan configuration, and streams results back up the chain as they’re produced.
Notus Scanner sits slightly outside that loop. Rather than actively probing a target the way the core engine does, it runs passive version-comparison checks during every regular scan: it reads package and build version information gathered elsewhere in the scan and matches it against known-vulnerable version ranges, without needing its own network traffic. This is why authenticated scans tend to surface more Notus-sourced findings than unauthenticated ones; Notus has nothing to compare against until it has real installed-package data to work with. All of this activity, plus every report, target, schedule, and credential object, lives in the pg-gvm PostgreSQL database, with redis-server handling short-lived scan-state caching so the manager doesn’t have to hit the database for every status update during an active scan.
Why Run Your Own Vulnerability Scanner in 2026
Vulnerability scanning used to be a once-a-quarter compliance checkbox. It isn’t anymore. With roughly 59,000 CVEs expected to be published across 2026 according to Tenable’s projection, a quarterly scan cadence means a server can sit exposed to a fully public exploit for weeks before anyone notices. Attackers automate discovery of new CVEs faster than most IT teams can patch for them, which is exactly how mass-exploitation waves against edge devices and VPN appliances keep happening within days of disclosure.
A self-hosted scanner like OpenVAS gives a team three things a once-a-year penetration test cannot: continuous visibility, authenticated (credentialed) checks that see missing OS and application patches a network-only scan would miss, and a free entry point for organizations that cannot justify a Nessus Professional license at roughly $4,790 per year before support add-ons. That isn’t a knock on commercial tools; Tenable, Qualys, and Rapid7 all offer broader plugin libraries, cloud dashboards, and vendor support that a community project can’t match (we cover those tradeoffs later in this guide, and in more depth in our Tenable vs Qualys vs Rapid7 comparison). But for a team that needs scanning coverage today, on a budget of zero dollars, OpenVAS is the most mature open-source option available.
There’s also a compliance angle that often gets a self-hosted scanner funded faster than a “best practice” argument alone. Frameworks like PCI DSS and SOC 2 both expect documented, recurring vulnerability scanning with retained evidence of remediation, and auditors generally don’t care whether the tool generating that evidence costs $4,790 a year or nothing, as long as the scope, cadence, and findings are documented. A scheduled OpenVAS task with exported reports stored alongside your remediation tickets satisfies that evidence requirement for a fraction of the cost of a commercial platform, which matters most for startups and small IT teams who need to pass an audit before they can justify a bigger security budget.
Prerequisites and System Requirements
Before starting, confirm your host meets Greenbone’s documented requirements. The Community Containers documentation lists two tiers: a minimal setup for testing and evaluation, and a recommended setup for anything resembling real use. Feed loading in particular is memory-hungry the first time it runs, and undersized hosts are the single most common cause of a stack that “hangs” on first boot.
| Requirement | Minimum (testing) | Recommended (regular use) |
|---|---|---|
| CPU cores | 2 | 4 |
| RAM | 4 GB | 8 GB |
| Free storage | 20 GB | 60 GB |
| Docker Engine | 24.x or newer | Latest stable release |
| Docker Compose | v2 plugin | v2 plugin |
| Operating system | Any Linux distro with Docker support | Ubuntu Server 24.04 LTS or similar |
You’ll also need: outbound internet access on the host (the stack pulls images from GitHub Container Registry and Docker Hub, then downloads feed data directly from Greenbone), a user account with permission to run Docker, root or sudo access to install packages, and at least one test target that you are explicitly authorized to scan. Scanning systems you don’t own or lack written authorization for is illegal in most jurisdictions under computer-fraud statutes, so keep your first scans pointed at your own lab VM or a host you administer.
Step 1: Prepare Your Host and Install Docker
Start with a clean Linux host (this guide uses Ubuntu 24.04, but the steps are nearly identical on Debian). Update packages and install Docker Engine with the official convenience script, which also installs the Compose v2 plugin:
sudo apt update && sudo apt upgrade -y
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER
newgrp docker
docker --version
docker compose versionConfirm both commands return version numbers before continuing. If docker compose version fails, you likely have only the legacy standalone docker-compose binary installed; the Compose v2 plugin is required because Greenbone’s instructions use the docker compose (no hyphen) syntax throughout.
Step 2: Download the Greenbone Community Containers Compose File
Greenbone publishes a ready-made Compose file rather than asking you to assemble one from scratch. Create a working directory and pull it directly from Greenbone’s documentation site:
export DOWNLOAD_DIR="$HOME/openvas"
mkdir -p "$DOWNLOAD_DIR"
curl -f -O -L https://greenbone.github.io/docs/latest/_static/compose.yaml \
--output-dir "$DOWNLOAD_DIR"
ls -la "$DOWNLOAD_DIR"Open the file with a text editor and skim the services: block. You’ll see roughly a dozen services defined: redis-server for caching, pg-gvm running PostgreSQL for persistent storage, gvmd as the manager, gsad and gsa for the web interface, nginx as the reverse proxy, ospd-openvas as the scan controller, and a set of feed-data containers: vulnerability-tests, notus-data, scap-data, cert-bund-data, dfn-cert-data, data-objects, report-formats, and gpg-data. Each feed container exists purely to copy data into a shared Docker volume on startup; none of them run as long-lived processes.
Step 3: Pull the Container Images and Start the Stack
With the Compose file in place, pull every image and bring the stack up in detached mode:
docker compose -f "$DOWNLOAD_DIR/compose.yaml" pull
docker compose -f "$DOWNLOAD_DIR/compose.yaml" up -d
docker compose -f "$DOWNLOAD_DIR/compose.yaml" psThe pull step alone can take ten to twenty minutes on a typical broadband connection, since you’re downloading the full feed-data images in addition to the application containers. Expect the first docker compose ps run to show several containers in an “exited (0)” state almost immediately; that’s normal for the data-loading containers, which copy their payload into a shared volume and then stop on purpose. The services you want to see in a persistent “running” or “healthy” state are pg-gvm, redis-server, gvmd, ospd-openvas, gsad, gsa, and nginx.
Step 4: Set the Admin Password and Log In to GSA
The default install ships a built-in admin account with the password admin. Change it immediately, before you expose the web interface to anything beyond localhost:
docker compose -f "$DOWNLOAD_DIR/compose.yaml" exec -u gvmd gvmd \
gvmd --user=admin --new-password='Use-A-Long-Random-Passphrase-2026'Then open a browser on the same machine (or tunnel over SSH if you’re working remotely) and navigate to the Greenbone Security Assistant web interface, published on two ports by default: https://127.0.0.1:443 for the primary UI and an alternate API endpoint on 127.0.0.1:9392. Your browser will flag a self-signed certificate warning on first load; that’s expected for a fresh install and you can safely accept it for a local lab instance. For anything beyond a lab, put a properly signed reverse proxy in front of it instead of exposing the self-signed cert directly. Log in with the admin account and the new password you just set.
Step 5: Verify Feed Synchronization Before Scanning
This is the step most people skip, and it’s the most common cause of scans that silently return zero findings. Pulling the feed containers only downloads the data; the running services still need to import it into their databases and memory. In the GSA web interface, go to Administration > Feed Status and confirm every feed (NVT, SCAP, CERT) shows a recent update timestamp rather than “Never” or a sync still in progress. On first install, full feed synchronization can take anywhere from twenty minutes to over an hour depending on your host’s disk speed and the size of the current Community Feed, which includes tens of thousands of vulnerability test scripts.
You can also check from the command line by tailing the manager’s logs while synchronization completes:
docker compose -f "$DOWNLOAD_DIR/compose.yaml" logs -f gvmdDo not launch a real scan until the feed status page shows current data. A scan run against an unsynced feed will complete quickly and report nothing, which looks like good news until you realize the scanner had nothing to check against.
Step 6: Create Your First Scan Target
In the GSA interface, go to Configuration > Targets > New Target. Give it a descriptive name, enter the IP address or hostname of a system you are authorized to scan (your own lab VM for this walkthrough), and leave the default port list unless you have a specific reason to restrict it. For a first run, point this at an isolated test VM rather than production infrastructure. An unauthenticated OpenVAS scan is reasonably polite by default, but any new scanner deployment should prove itself against a disposable target first.
Step 7: Set Up Authenticated (Credentialed) Scanning
Unauthenticated network scans only see what’s exposed on the wire: open ports, service banners, and TLS configuration. Authenticated scans log in to the target with real credentials and check installed package versions, missing patches, and local misconfigurations, which is where most actionable findings come from. Under Configuration > Credentials > New Credential, create a dedicated, least-privilege account for scanning rather than reusing an administrator login:
- Linux/Unix targets: SSH credentials, ideally key-based rather than password-based
- Windows targets: SMB credentials for an account with local admin rights scoped to patch and registry reads
- Network devices: SNMP community strings or SNMPv3 credentials
Once the credential object exists, edit your target from Step 6 and attach the appropriate credential under “SSH Credential” or “SMB Credential.” Restrict the scanning account’s network access to the OpenVAS host’s IP where possible, and confirm the account can actually read package and patch metadata, not just log in; a credential that authenticates but can’t read /etc/os-release or installed package lists on Linux, or the registry on Windows, produces a report that looks clean but isn’t.
Step 8: Choose a Scan Configuration
Scan configurations control which vulnerability tests actually run. The built-in “Full and fast” configuration is the right default for most first scans: it runs the complete NVT library in an order optimized to find obvious issues quickly before moving to slower, deeper checks. Avoid “Full and very deep” for your first pass against any production-adjacent system; it enables every check, including some that can be disruptive against fragile embedded devices or older network appliances, and it takes substantially longer to finish.
Scan Types Explained: Discovery vs Full and Fast vs Full and Very Deep
Before launching anything beyond a lab test, it’s worth understanding what each built-in scan configuration actually does, since picking the wrong one is a common source of either wasted time or an unnecessarily disruptive scan. “Discovery” is the lightest option: it identifies live hosts and open ports without running the bulk of the NVT library against them, which makes it useful for mapping an unfamiliar network segment before committing to a full scan. “Full and fast” runs the complete, current vulnerability-test library, ordered so that cheap, high-confidence checks run before slower, more exhaustive ones, and it’s the right default for almost every recurring production scan.
“Full and very deep” enables every available check, including some brute-force and fuzzing-style tests that can trigger account lockouts, crash fragile services, or generate a large volume of log noise on the target. It exists for thorough, scheduled audits of systems you can afford to have misbehave briefly, such as a staging environment, not for a first look at production infrastructure. There’s also “Full and fast ultimate” and “Full and very deep ultimate,” which add a small number of denial-of-service-style checks; Greenbone explicitly scopes these for environments where you’re prepared to accept a service interruption during testing, so they should stay off your default rotation entirely.
Automating Scans With the GMP API and python-gvm
Clicking through the GSA interface works fine for a handful of hosts, but it doesn’t scale once you’re managing dozens of targets or want scans triggered from a CI/CD pipeline or a ticketing system. Greenbone exposes the same functionality the web UI uses through the Greenbone Management Protocol (GMP), and the official python-gvm library wraps that protocol in a scriptable client. Install it inside a virtual environment on a machine that can reach the GSA host:
python3 -m venv gvm-env
source gvm-env/bin/activate
pip install python-gvm
python3 - <<'EOF'
from gvm.connections import TLSConnection
from gvm.protocols.gmp import Gmp
from gvm.transforms import EtreeCheckCommandTransform
connection = TLSConnection(hostname="127.0.0.1", port=9392)
with Gmp(connection, transform=EtreeCheckCommandTransform()) as gmp:
gmp.authenticate("admin", "Use-A-Long-Random-Passphrase-2026")
version = gmp.get_version()
print(version)
tasks = gmp.get_tasks()
for task in tasks.xpath("task"):
print(task.find("name").text, task.find("status").text)
EOFFrom there, the same client can create targets, attach credentials, start tasks, and poll for report completion, which is the pattern most teams use to trigger an OpenVAS scan automatically whenever a new host joins an asset inventory, or to pull the latest report into a nightly job that posts a summary to Slack or opens tickets for new high-severity findings. Treat the GMP credentials you use for automation the same way you'd treat any other service account: a dedicated, least-privilege GSA user rather than the primary admin login, with its password stored in a secrets manager rather than hardcoded in a script.
Step 9: Launch and Monitor Your First Scan
Go to Scans > Tasks > New Task, select your target and scan configuration, and start the task. GSA shows live progress as a percentage, and you can drill into individual host progress from the task detail view. A single host with "Full and fast" and authenticated credentials typically finishes in anywhere from a few minutes to over an hour, depending on how many services are open and how deep the Notus package checks need to go.
Example of a healthy task list once synchronization and the first scan have completed:
Task Status Severity Reports
Lab-Server-01 Done High 1
Lab-Server-01 Done Medium 1Step 10: Read and Triage the Scan Report
Open the completed report from Scans > Reports. Each finding lists a CVSS severity score, an NVT description explaining what was detected and why it matters, and (where applicable) the matching CVE identifiers. Sort by severity first and work top-down: a single CVSS 9.8 remote code execution finding on an internet-facing host matters more than a dozen low-severity informational findings. For every finding, check the "Solution" field, which usually points to a specific patch version or configuration change, and cross-reference the CVE ID against the CVSS calculator at FIRST.org if you need to recalculate severity for your specific environment (exposure and exploitability can shift a vendor's base score up or down for your context).
Flag any false positives you confirm manually, since OpenVAS lets you add notes and overrides directly against a specific NVT result so it doesn't keep re-flagging the same confirmed non-issue on every future scan of that host.
Step 11: Schedule Recurring Scans
A one-time scan is a snapshot; a scheduled scan is a program. Under Configuration > Schedules > New Schedule, define a recurrence (weekly is a reasonable baseline for internal infrastructure, daily for anything internet-facing), then attach that schedule to your task under Scans > Tasks > Edit Task. Given that Tenable's research points to roughly 59,000 new CVEs landing across 2026, a monthly cadence leaves too wide a window; weekly authenticated scans against critical systems is the more defensible baseline for 2026.
Step 12: Automate Feed and Container Updates
Because most Compose services track a stable tag, keeping the stack current is mostly a matter of re-pulling images and feed data on a schedule. Greenbone's documented update sequence pulls the feed-data containers specifically, then restarts the stack so the running services pick up the new data:
docker compose -f "$DOWNLOAD_DIR/compose.yaml" pull \
notus-data vulnerability-tests scap-data dfn-cert-data \
cert-bund-data report-formats data-objects
docker compose -f "$DOWNLOAD_DIR/compose.yaml" up -dWrap this in a cron job that runs nightly, and add a full application pull (docker compose pull && docker compose up -d) weekly so gvmd, ospd-openvas, and the GSA components stay current too. A scanner running against a stale feed is only marginally better than no scanner, since it has no way to flag a CVE it doesn't know about yet.
Step 13: Export Reports and Harden Your Deployment
From the report view, use the export button to generate output in PDF, CSV, or XML for handoff to a ticketing or vulnerability-management system (teams running DefectDojo can ingest OpenVAS XML reports directly as a finding source). Before calling the deployment production-ready, lock down a few things: restrict inbound access to ports 443 and 9392 to a management VLAN or VPN rather than the open internet, replace the self-signed certificate with one from your internal CA or Let's Encrypt if the GSA interface needs to be reachable by more than one admin, rotate the admin password on a normal schedule, and create separate, role-limited GSA user accounts for each analyst instead of sharing the admin login.
Common Pitfalls When Deploying OpenVAS
Most failed OpenVAS deployments fail for the same handful of avoidable reasons. Here are the ones that come up most often:
- Scanning before the feed finishes syncing. A scan against an unsynced feed completes fast and reports almost nothing, which gets misread as "the target is secure" instead of "the scanner has no data yet."
- Undersizing the host. Running the full stack on 2 GB of RAM instead of the documented 4 GB minimum causes
gvmdor PostgreSQL to get OOM-killed mid-sync, corrupting the feed import. - Never changing the default admin/admin credentials. Internet-exposed GSA instances with default logins get found by scanners like Shodan within hours.
- Skipping authenticated scans entirely. Unauthenticated-only scanning misses the missing-patch findings that make up the bulk of real exploitable risk, giving a false sense of a clean report.
- Running "Full and very deep" against fragile production systems. Some deep checks can crash older embedded web servers or IoT management interfaces; test on a lab clone first.
- Ignoring the override/false-positive workflow. Teams that don't use notes and overrides re-triage the same confirmed non-issues every single scan cycle, wasting analyst time.
- Treating a point-in-time scan as a permanent answer. With tens of thousands of new CVEs published per year, last month's clean report tells you nothing about this month's exposure.
Troubleshooting Common OpenVAS Errors
These are the errors and symptoms most commonly reported by people running the Community Containers stack, with the fixes that resolve them. Before digging into any of these, your first diagnostic move should always be the same: run docker compose -f "$DOWNLOAD_DIR/compose.yaml" ps to see which container actually stopped or shows unhealthy, then check that specific container's logs with docker compose logs <service-name> rather than guessing from the symptom alone. Nine times out of ten, the log output names the exact missing dependency or resource constraint.
| Symptom | Likely Cause | Fix |
|---|---|---|
| GSA won't load in browser | Port 443 or 9392 already bound by another service | Run docker compose ps and ss -tulpn to find the conflict; stop the competing service or remap the port in compose.yaml |
| Scan reports zero findings on a known-vulnerable host | Feed data not yet synchronized | Check Administration > Feed Status; wait for all three feeds to show a recent timestamp before scanning |
Containers exit immediately after up -d | Insufficient RAM causing OOM kills during initial load | Increase host RAM to at least 4 GB (8 GB recommended) and rerun docker compose up -d |
| Login fails with correct new password | Password change command targeted wrong container or ran before gvmd was fully started | Confirm gvmd shows "healthy" via docker compose ps, then rerun the --new-password command |
| Reports page becomes very slow or pegs CPU | Large accumulated report history; documented on gvmd 26.19.0 with around 500 stored reports | Archive or delete old reports regularly, or export and purge reports older than your retention window |
| Authenticated scan shows "no local checks performed" | Credential can log in but lacks read permission on package/patch metadata | Verify the scanning account can run the relevant OS commands (e.g. read /etc/os-release, list installed packages) without elevated prompts blocking it |
ospd-openvas shows unhealthy or scans hang at 0% | Scanner process crashed or lost its socket connection | Run docker compose restart ospd-openvas, then re-launch the task |
| Manager UI shows stale or inconsistent data after an update | gvmd's internal data cache needs rebuilding after a version bump | Run docker compose exec -u gvmd gvmd gvmd --rebuild-gvmd-data=all |
| Feed pull hangs or times out | Outbound network restrictions blocking GitHub Container Registry or Greenbone's feed servers | Confirm outbound HTTPS (443) is open to ghcr.io and Greenbone's feed endpoints from the Docker host |
OpenVAS vs Nessus vs Nuclei: How the Scanners Compare
OpenVAS isn't the only open-source-adjacent option, and it isn't a drop-in replacement for every commercial platform. Nessus, from Tenable, remains the best-known commercial scanner; Nessus Essentials stays free for personal and non-commercial use with a cap of 16 IP addresses per scanner according to Tenable's current FAQ, while Nessus Professional lists at $4,790 for a one-year license, with optional advanced support adding further cost. Nuclei, maintained by ProjectDiscovery, takes a different approach entirely: it's a fast, YAML-template-driven scanner built for checking applications, APIs, and cloud configurations against specific known issues rather than running the broad, stateful vulnerability-management workflow that OpenVAS and Nessus both provide.
| Factor | OpenVAS / Greenbone CE | Nessus (Essentials / Professional) | Nuclei |
|---|---|---|---|
| License cost | Free, open source | Free (Essentials, 16 IP cap) or $4,790/year (Professional) | Free, open source |
| Deployment model | Self-hosted Docker stack | Software, agent, or cloud, vendor-managed | CLI tool, self-hosted or CI-integrated |
| Vulnerability data source | Community Feed (NVT, SCAP, CERT advisories) | Tenable plugin feed, continuously updated | Community-maintained YAML templates |
| Authenticated scanning | Yes (SSH, SMB, SNMP credentials) | Yes, broader OS/app coverage | Limited; primarily unauthenticated checks |
| Best fit | Budget-conscious teams needing full network + host scanning | Enterprises needing vendor support and broader plugin coverage | Developers needing fast, scriptable checks against web apps and APIs |
| Vendor support | Community forum only (commercial Greenbone editions exist separately) | Commercial vendor support included | Community support; commercial PDCP platform available |
In practice, many security teams run more than one of these in parallel: OpenVAS or Nessus for scheduled, broad infrastructure scanning, and Nuclei for fast checks during CI/CD pipelines or ad hoc web app testing. None of the three replaces good patch management discipline; they just tell you, with evidence, where that discipline is falling short.
Advanced Tips for Running OpenVAS in Production
Once the basic deployment is stable, a few adjustments make OpenVAS meaningfully more useful for an actual security program rather than a lab demo. First, use scan configuration cloning: duplicate the built-in "Full and fast" config and strip out NVT families that don't apply to your environment (printer-specific checks on a server-only network, for example) to cut scan time without losing coverage that matters. Second, tag targets by business criticality in GSA's target notes field, then build separate tasks and schedules per tier, scanning crown-jewel systems daily and lower-priority internal assets weekly.
Third, feed scan results into a dedicated vulnerability-management layer rather than reading raw OpenVAS reports by hand every cycle; our vulnerability management program guide covers how to build that triage and remediation-tracking workflow on top of scanner output. Fourth, if you're scanning a mix of cloud and on-prem assets, run a separate ospd-openvas scanner instance closer to each network segment rather than forcing all traffic through one central scanner across a VPN, which both slows scans and can trip IDS alerts on the path in between. Finally, export results periodically in XML format and version-control the historical findings; a diff between this month's and last month's report is often more actionable for a small team than the absolute finding count in any single scan.
Complete Working Project: Full Reference Setup
Putting every step together, here is the complete command sequence for a working OpenVAS deployment, from a bare Docker host to a scanner ready for its first authenticated scan:
# 1. Install Docker
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER && newgrp docker
# 2. Download the Greenbone Compose file
export DOWNLOAD_DIR="$HOME/openvas"
mkdir -p "$DOWNLOAD_DIR"
curl -f -O -L https://greenbone.github.io/docs/latest/_static/compose.yaml \
--output-dir "$DOWNLOAD_DIR"
# 3. Pull images and start the stack
docker compose -f "$DOWNLOAD_DIR/compose.yaml" pull
docker compose -f "$DOWNLOAD_DIR/compose.yaml" up -d
# 4. Confirm services are healthy
docker compose -f "$DOWNLOAD_DIR/compose.yaml" ps
# 5. Set a strong admin password
docker compose -f "$DOWNLOAD_DIR/compose.yaml" exec -u gvmd gvmd \
gvmd --user=admin --new-password='Use-A-Long-Random-Passphrase-2026'
# 6. Confirm feed sync status (watch logs, or check GSA > Administration > Feed Status)
docker compose -f "$DOWNLOAD_DIR/compose.yaml" logs -f gvmd
# 7. Weekly maintenance: refresh feeds and application images
docker compose -f "$DOWNLOAD_DIR/compose.yaml" pull \
notus-data vulnerability-tests scap-data dfn-cert-data \
cert-bund-data report-formats data-objects
docker compose -f "$DOWNLOAD_DIR/compose.yaml" pull
docker compose -f "$DOWNLOAD_DIR/compose.yaml" up -d
# 8. If the manager UI shows stale data after an update, rebuild it
docker compose -f "$DOWNLOAD_DIR/compose.yaml" exec -u gvmd gvmd \
gvmd --rebuild-gvmd-data=allFrom here, the remaining work happens in the GSA web interface at https://127.0.0.1:443: create a target, attach credentials, select the "Full and fast" scan configuration, launch the task, and set a weekly schedule once the first report comes back clean of surprises. That's a complete, free, authenticated vulnerability scanning pipeline running on a single Docker host.
Frequently Asked Questions
Is OpenVAS still actively maintained in 2026?
Yes. The OpenVAS Scanner component shipped version 23.50.24 on September 3, 2026, and Greenbone's broader component releases show activity as recent as February 2026, with the Community Containers project receiving regular updates on GitHub.
Is OpenVAS completely free to use?
Yes, Greenbone Community Edition and the Community Feed are free and open source. Greenbone also sells commercial editions with an Enterprise Feed and vendor support for organizations that need faster feed updates and SLA-backed assistance, but the Community Edition used in this tutorial costs nothing to run.
How long does the first feed synchronization take?
Expect twenty minutes to over an hour depending on disk speed and network throughput, since the Community Feed includes tens of thousands of vulnerability test scripts across NVT, SCAP, and CERT advisory data. Always confirm feed status before trusting a scan result.
Can OpenVAS scan Windows servers?
Yes, using authenticated scanning with SMB credentials for an account with sufficient privileges to read installed software and patch information through the registry. Unauthenticated scans against Windows only see what's exposed over the network.
What's the difference between OpenVAS and Greenbone Community Edition?
OpenVAS technically refers to the scanning engine (openvas-scanner) inside the stack. Greenbone Community Edition is the full product name for the entire free, self-hosted package: the manager, web interface, scanner, and feed data bundled together through the Community Containers Compose setup covered in this guide.
Why did my first scan return almost no findings?
This almost always means the feed hadn't finished synchronizing yet. Check Administration > Feed Status in GSA and wait for all feeds to show a current timestamp before re-running the scan.
Can I run OpenVAS scans in CI/CD pipelines?
OpenVAS is built around scheduled, stateful scanning rather than fast per-build checks, so it's better suited to periodic infrastructure scanning than inline CI gates. For CI/CD-integrated checks, a template-driven tool like Nuclei is generally a better architectural fit, run alongside OpenVAS rather than instead of it.
Is it legal to run OpenVAS against any IP address I want?
No. Only scan systems you own or have explicit written authorization to test. Scanning third-party infrastructure without authorization can violate computer-fraud laws in most countries, regardless of intent.
How much does OpenVAS cost compared to Nessus Professional?
Greenbone Community Edition and its Community Feed are free with no IP or scan-count cap. Nessus Professional lists at $4,790 for a one-year license, while its free Essentials tier caps at 16 IP addresses per scanner according to Tenable's current FAQ, making OpenVAS the more practical option once you're scanning more than a handful of hosts.
Can I automate OpenVAS scans without using the web interface?
Yes. The Greenbone Management Protocol (GMP) exposes every function available in GSA, and the official python-gvm library lets you script target creation, credential assignment, scan launches, and report retrieval, which is how most teams integrate OpenVAS into CI/CD pipelines or asset-inventory-driven scanning.
Related Coverage
- DefectDojo Setup: 369 Scanners in 13 Steps [2026]
- How to Set Up Pi-hole: 12 Steps, 45 Minutes [2026]
- How to Set Up Zeek 9: Network Monitor in 13 Steps [2026]
- How to Set Up Wazuh SIEM: 13 Steps, Free XDR [2026]
- How to Set Up Keycloak: Free SSO in 13 Steps [2026]
