Scan for Free: How Greenbone/OpenVAS Helps SMBs Meet PCI DSS Requirement 11.3.1

Introduction

Every business that stores, processes, or transmits cardholder data has to comply with the Payment Card Industry Data Security Standard (PCI DSS). For a small retailer running a point-of-sale system, or a mid-sized SaaS company processing card payments through an embedded checkout, that obligation doesn’t disappear just because the security budget is small.

PCI DSS v4.0 Requirement 11.3.1 is explicit: in-scope internal systems must be scanned for vulnerabilities at least once every three months, high-risk and critical vulnerabilities must be resolved, and rescans must confirm the fix worked. Requirement 11.3.1.2 goes further and requires those internal scans to be authenticated — logged in with credentials, not just probed from the outside.

Commercial vulnerability scanners with the licensing, support, and compliance reporting SMBs want often start in the thousands of dollars per year. Many smaller merchants respond by skipping internal scanning altogether, or running a one-off free trial once a year and calling it "good enough." Both choices leave real gaps: unpatched software on the point-of-sale network, exposed management interfaces, weak TLS configurations — the kind of issues that show up repeatedly in payment-card breach post-mortems, where an unpatched, internet-facing or internally reachable service was the entry point long before card data was ever touched.

This article walks through Greenbone Community Edition (the open-source project that grew out of OpenVAS), a free, actively maintained vulnerability scanner, and shows exactly how to use it to satisfy the internal scanning requirements in PCI DSS 11.3.1 and 11.3.1.2 — at zero license cost.

One important boundary up front: Greenbone/OpenVAS is a scanning engine, not a PCI SSC Approved Scanning Vendor (ASV). Requirement 11.3.2 — the quarterly external scan — must be performed by a company on the PCI SSC’s official ASV list. Greenbone does not replace that requirement. What it does replace is the cost of tooling for your internal scans, which you are allowed to run yourself.

This article continues InfoSec4TC’s series on meeting PCI DSS requirements without enterprise budgets — see also our guides on using a free SMB firewall for Requirement 1.2.1, a free password manager for Requirement 8.3.1’s multi-factor authentication, and a free, open-source SIEM for Requirement 10.2 logging. If your organization needs broader support across your PCI DSS compliance services beyond internal scanning, InfoSec4TC’s team can help scope and run the full program.

Prerequisites for Authenticated Internal PCI DSS Scanning

If this is your first formal internal scan, InfoSec4TC’s step-by-step guide to conducting your first internal vulnerability assessment walks through the broader process this scan feeds into.

Before you start, make sure you have:

• A Linux host (these steps assume Ubuntu 22.04 LTS or newer) with at least 8 GB RAM and 4 CPU cores. Greenbone’s feed and scan engine are resource-hungry; 4 GB will work for a lab but will struggle on a real scan of more than a handful of hosts.
• At least 15–20 GB of free disk space for the vulnerability feed (NVTs, SCAP data, CERT advisories).
• Docker Engine and the Docker Compose plugin (installed in Step 1 below).
• Outbound internet access from the host, needed for the initial and ongoing feed synchronization.
• Administrative (sudo) access on the host.
• A documented list of the systems that fall inside your PCI cardholder data environment (CDE) scope — the IP ranges or hostnames you are legally required to scan. Scanning systems outside your defined scope, or missing systems inside it, is a common audit finding, not a technical one.
• Credentials (a local or domain service account) you can dedicate to authenticated scanning, as required by 11.3.1.2 — for example a low-privilege Linux account with SSH access, or a Windows service account with the rights needed for registry/WMI-based checks.
• A documented vulnerability risk-ranking methodology. PCI DSS 11.3.1 asks you to resolve "high-risk and critical" vulnerabilities, and that risk ranking is defined under Requirement 6.3.1 — you need this in place before scan results mean anything for compliance.

Step-by-Step: Setting Up a Free PCI DSS Vulnerability Scanning Tool (Greenbone/OpenVAS)

1. Install Docker Engine and the Compose plugin

sudo apt-get update && sudo apt-get install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

This installs the Docker runtime and the docker compose command. Verify with docker --version and docker compose version — both should return a version number without errors.

2. Create a working directory for the Greenbone Community Containers

mkdir -p ~/greenbone-ce && cd ~/greenbone-ce

This keeps the compose file, environment file, and persistent volumes for your Greenbone stack in one place. Download the current docker-compose.yml and .env file exactly as published on the Greenbone Community Edition "Container Installation" page (linked in Free Resources below) and save them into this directory — the files change between releases, so always pull the current version from the official docs rather than an old copy.

3. Start the stack

docker compose up -d

This pulls and starts all required containers: gvmd (the manager), ospd-openvas (the scan engine), notus-scanner (fast local-security-check matching), pg-gvm (PostgreSQL), redis-server, and gsa (the web UI). Verify with docker compose ps — every service should show as running or healthy within a few minutes.

4. Retrieve the auto-generated administrator password

docker compose logs gvmd | grep -i password

On first startup, gvmd creates an admin account with a randomly generated password and writes it to its own logs. This command surfaces that line so you can record the password securely (a password manager, not a sticky note). Verify by confirming you captured a password string in the output.

5. Wait for the vulnerability feed to synchronize

docker compose logs -f notus-scanner

The container downloads the Network Vulnerability Tests (NVTs), SCAP data, and CERT advisories on first run — this can take anywhere from 20 minutes to a few hours depending on bandwidth. Verify completion in the web UI once you log in: Administration → Feed Status should show the NVT, SCAP, and CERT feeds as "Current" rather than "Out of date" or "Update in progress."

6. Log in and secure the admin account

Open https://localhost:9392 (or the host’s IP) in a browser, accept the self-signed certificate warning, and log in as admin with the password from Step 4. Immediately go to Administration → Users, select admin, and set a strong password of your own choosing. Verify by logging out and back in with the new password.

7. Create authenticated scan credentials (for Requirement 11.3.1.2)

In the web UI: Configuration → Credentials → New Credential. Create one credential for SSH (Linux/Unix hosts, with a username and either password or SSH key) and, if you have Windows systems in scope, one SMB/WMI credential. This is what makes your internal scans "authenticated" rather than purely network-based — PCI DSS 11.3.1.2 specifically requires this for internal scanning. Verify the credential appears in the Credentials list with the correct type.

8. Define a Target scoped to your PCI in-scope network

Go to Configuration → Targets → New Target. Enter only the IP addresses or ranges that fall inside your documented CDE scope, and attach the credential(s) created in Step 7 under "Credentials for authenticated checks." Verify by opening the target and confirming the host list and credentials match what you intended — a target that’s too broad (or too narrow) is a direct audit finding.

9. Create and schedule the scan Task

Go to Scans → Tasks → New Task. Select the Target from Step 8, choose the Full and Fast scan config (a solid general-purpose choice for authenticated internal scans), and set a schedule of at least every three months to satisfy the minimum cadence in 11.3.1. Verify by checking the Task’s "Schedule" field reflects the recurrence you configured.

Scan Config: Full and Fast
Target: PCI-CDE-Internal-Q-Scan
Schedule: Every 3 months (plus ad hoc after significant changes)

10. Run the scan

Click the "Play" icon on the Task, or wait for the schedule to trigger it. Monitor progress on the Tasks page, where the status moves from Requested → Running → Done. Verify completion by confirming the status reads Done and a report with a timestamp has been generated.

11. Review and filter the report by severity

Open Scans → Reports, select the completed report, and use the severity filter (severity>=7.0 for High/Critical on the CVSS scale, adjusted to match your own 6.3.1 risk-ranking policy). Export the filtered report to PDF or CSV via Report → Export. Verify by confirming the exported file opens and lists the vulnerabilities with CVSS scores and affected hosts — this file is your compliance evidence.

# Example severity filter string used in the GSA report filter box
severity>=7.0 and status=Open

12. Remediate and rescan

Patch or mitigate every High/Critical finding, then re-run the same Task against the same Target. PCI DSS 11.3.1 explicitly expects rescans "as needed" until high-risk and critical vulnerabilities are resolved. Verify by comparing the new report to the previous one — the previously flagged High/Critical findings should no longer appear. Retain both reports (and all subsequent quarterly reports) as audit evidence for your QSA or internal assessor.

Common Pitfalls When Using a Free PCI DSS Vulnerability Scanning Tool

• Scanning unauthenticated only. An unauthenticated scan sees far fewer issues than an authenticated one and does not satisfy 11.3.1.2. Always configure and verify credentials before relying on results.
• Treating OpenVAS as an ASV substitute. Requirement 11.3.2’s external quarterly scan must come from a company on the PCI SSC’s Approved Scanning Vendor list. Greenbone covers your internal obligation only.
• Scoping the Target too broadly or too loosely. Scanning your entire flat network gives a false sense of coverage if your CDE is actually segmented, and missing a segment means missing a requirement. Confirm scope against your network diagram and segmentation testing results, not assumptions.
• Skipping the risk-ranking step. Without a documented methodology under 6.3.1, "High" and "Critical" are just CVSS labels, not a compliance decision. Define and document how your organization ranks vulnerabilities before you need to defend a scan result to an assessor.
• Letting the feed go stale. A scanner with outdated NVTs will miss recently disclosed vulnerabilities. Check Feed Status regularly, not just on install day.
• Running full scans against production during business hours. Authenticated scans with intrusive checks can affect fragile legacy systems (common in SMB point-of-sale environments). Schedule scans for maintenance windows and consider a less intrusive scan config for sensitive hosts.
• Under-provisioning the host. Greenbone’s PostgreSQL database and scan engine are memory-intensive; running it on a 2 GB VM will produce timeouts and incomplete reports, not a clean "no vulnerabilities found."

Troubleshooting Greenbone/OpenVAS Internal Scans

Symptom: https://localhost:9392 is unreachable.

Check container health with docker compose ps. If gsa isn’t running, inspect it with docker compose logs gsa. Confirm port 9392 isn’t already bound by another service with sudo ss -tulpn | grep 9392.

Symptom: Feed Status stays "Out of date" indefinitely.

The containers need outbound access to Greenbone’s feed servers. Check docker compose logs notus-scanner and docker compose logs ospd-openvas for connection timeouts, and confirm outbound HTTPS isn’t blocked by a corporate proxy or firewall.

Symptom: Scan Task stuck at "Requested" and never moves to "Running."

Confirm the scanner is registered correctly: docker compose exec gvmd gvmd --get-scanners. If the OpenVAS scanner entry is missing or shows an error, restart the stack with docker compose restart and re-check.

Symptom: Report shows "Authentication failure" on every host.

Verify the credential type matches the target OS (SSH for Linux, SMB/WMI for Windows), confirm the account hasn’t been locked out by repeated failed attempts, and confirm the scanner host can reach the target on the relevant port (22 for SSH, 445/135 for SMB/WMI) — check with nc -zv <target-ip> 22.

Symptom: Scans take far longer than expected or time out.

Reduce scan concurrency in Configuration → Scan Configs → Full and Fast → Edit → Preferences (lower max_hosts and max_checks), and confirm the host isn’t swapping — check with free -h and docker stats during a run.

Symptom: Containers crash or restart repeatedly.

Usually a memory problem. Check docker stats for containers hitting their limits, and increase host RAM or add swap space as a short-term mitigation.

Conclusion

PCI DSS Requirement 11.3.1 doesn’t require an expensive scanner — it requires a documented, repeatable process: internal scans at least every three months, authenticated per 11.3.1.2, with High/Critical findings resolved and rescanned until clean. Greenbone Community Edition (OpenVAS) delivers the scanning engine for that process at no license cost, leaving your budget for the things open source can’t give you: the risk-ranking policy under 6.3.1, remediation time, and — critically — the Approved Scanning Vendor you still need for the external scans under 11.3.2.

Next step: stand up the stack in a non-production environment this week, run one authenticated scan against a small, clearly scoped test segment, and use that first report to validate your risk-ranking policy before you schedule your first production quarterly scan.

Free Resources

• Greenbone Community Edition Documentation — official install, container setup, and configuration guide.
• Greenbone GitHub Organization — source code for gvmd, the OpenVAS scanner, and related components.
• Greenbone Community Forum — active user forum for installation help and troubleshooting.
• PCI Security Standards Council Document Library — official PCI DSS v4.0.1 standard and supporting guidance documents.
• PCI SSC List of Approved Scanning Vendors — required reading before selecting a vendor for your external 11.3.2 scans.