What a vulnerability scanner does
A vulnerability scanner is, at heart, a comparison engine. It takes the service-and-version inventory produced in the previous phase — Apache 2.4.49 on port 80, OpenSSH 7.2 on port 22, an aging database listener on 3306 — and matches each of those facts against a huge, continuously updated database of known vulnerability tests. Where a service's version lines up with a published flaw, the scanner records a finding and assigns it a severity. The output is a prioritized list of probable weaknesses: the places an attacker is most likely to find a way in.
The word that matters there is probable. A scanner is fast and exhaustive in a way no human can be — it will test thousands of conditions across hundreds of hosts in the time it takes you to read this paragraph. That is its entire value: it automates breadth. It is not, however, a verdict. A scanner reports that a version appears vulnerable; it rarely proves that the flaw is actually exploitable in this specific environment. Confirming a finding, ruling out a false positive, and deciding what is worth attacking are still your job. The scanner narrows the field; it does not replace judgment.
OpenVAS and the Greenbone stack
OpenVAS — the Open Vulnerability Assessment Scanner — is the leading free, open-source vulnerability scanner, and for many testers it is the default first choice precisely because it costs nothing and ships in most security distributions. What started as a single program has grown into a small ecosystem now maintained as the Greenbone Vulnerability Management (GVM) stack. When people say "OpenVAS" today, they usually mean GVM as a whole.
It helps to know the pieces, because the names show up in logs and documentation:
- The scanner engine — OpenVAS proper. This is the component that actually reaches out to a target, runs each test against it, and collects the results. It does the work; everything else organizes it.
- The feed of Network Vulnerability Tests — the NVTs are the scanner's knowledge. Each NVT is a small script that checks for one specific weakness, and the feed of them is updated constantly as new flaws are published. A scanner is only ever as good as how recently its feed was synced, so updating the feed is the first thing you do.
- The web console — the Greenbone Security Assistant (GSA) is the browser-based interface you actually drive. You define targets, launch scans, and read reports from this dashboard rather than the command line.
The workflow: target, task, report
Running a scan in Greenbone follows the same shape every time. Once you internalize the three nouns — Target, Task, Report — the interface stops feeling cluttered. Here is the concrete path from a fresh console to a finished report:
- 1. Define a Target. A Target is simply what you are scanning: a single IP, a list of addresses, or a range like 10.0.2.0/24. You name it, paste in the scope you have been authorized to test, and save it. The Target also remembers options like which ports to consider and — importantly — any credentials you attach (more on that shortly).
- 2. Create a Task. A Task pairs a Target with a Scan Config — the recipe that decides how aggressive and thorough the scan is. The everyday default is Full and fast, which runs the broad set of NVTs while skipping the slowest, most dangerous checks. Other configs trade speed for depth in either direction.
- 3. Run it. Start the Task and the scanner works through the Target host by host, NVT by NVT. Large ranges take real time; a single host is quick. The console shows live progress as it goes.
- 4. Review the Report. When the Task finishes it produces a Report — the ranked list of findings with their severities, descriptions, and references. This is the artifact you actually read, and reading it well is the next section.
The same Task can be re-run later to see what changed, which is exactly how you confirm that a remediation actually closed a hole. Define once, run repeatedly.
Reading the results
A finished report can list hundreds of findings, and they are not all equal. Greenbone gives you several columns of metadata for exactly this reason — to help you sort signal from noise before you spend time chasing anything. Learn what each one means and the flood becomes navigable.
| Field | What it is | How to read it |
|---|---|---|
| Severity | High / Med / Low / Log | The scanner's headline rating. High findings are likely serious and exploitable; Medium matters but is often conditional; Low is minor or hardening-level. Log is purely informational — a fact the scanner noticed, not a flaw — and is safe to skim past once you have skimmed it. |
| CVSS score | 0.0 – 10.0 | The numeric score behind the severity label, on the industry-standard Common Vulnerability Scoring System. It is what drives the High/Medium/Low bucketing — a 9.8 is a five-alarm fire, a 4.0 is a shrug. Use it to rank within a tier, not just across tiers. |
| CVE references | Identifiers | One or more CVE-YYYY-NNNNN IDs naming the specific public vulnerability behind the finding. Following the CVE links you to the official write-up, affected versions, and often a proof-of-concept — the starting point for confirming whether the flaw really applies here. |
| QoD | 0 – 100% | Quality of Detection — the scanner's own confidence that the finding is real. A high QoD means the scanner directly observed the vulnerable condition; a low QoD means it inferred the flaw from weaker evidence, such as a version banner alone. Treat a low QoD as a flag to validate before you trust it. |
QoD is the field newcomers overlook and veterans read first. A High-severity finding at 99% QoD is something you act on; the same finding at 30% QoD is something you investigate — it may be a false positive born of a misread version string. Severity tells you how much a finding would matter if it is real; QoD tells you how sure the scanner is that it is real. You need both numbers to triage honestly, and ignoring QoD is the fastest way to waste an afternoon chasing a vulnerability that was never there.
Credentialed scanning — the biggest quality lever
Everything above describes a scanner working from the outside, and there is a ceiling to how much an outsider can learn. An unauthenticated scan only sees what the target exposes on the network: the open ports, the banners, the versions a service is willing to announce. From that vantage it can only ever guess at what is actually installed — which is exactly why so many of its findings come back at a low QoD.
A credentialed scan changes the game completely. You hand the scanner valid credentials — SSH for Linux and network gear, SMB for Windows — and it logs in to inspect the host from the inside. Now it reads the actual installed package versions and patch levels directly from the system rather than inferring them from a banner. The result is a scan that finds far more — including local vulnerabilities never visible from the network — and reports it all at far higher confidence. Credentialed scanning is the single biggest lever you have on scan quality, and on any engagement where you can get credentials, you use them.
Two cautions ride along with all of this, and neither is optional:
- Authorized targets only. A vulnerability scan is an active probe of someone else's systems. Run it only against hosts you have explicit written permission to test, and only within the scope you agreed to. Pointing a scanner at anything outside that scope is not testing — it is an attack.
- Scanners are noisy and can do harm. A full scan throws thousands of probes at every host, and fragile services — legacy applications, embedded devices, anything held together with tape — can crash under that load. Mind your scope and your timing: coordinate scan windows, warn the right people, and never assume a production system will shrug off the traffic.
A clean credentialed scan can still hand you a report with hundreds of entries across dozens of hosts — far more than you can chase one by one. Turning that flood into a short list of findings worth your time is its own discipline, and it is where this phase goes next.