What Is Vulnerability Scanning? A Defender's Guide

A vulnerability scanner takes an inventory of what runs on a host, compares each piece against a database of known flaws, and reports the matches. Point Nessus or OpenVAS at a subnet and within minutes you get a list: this server runs OpenSSL 3.0.0, that flaw maps to CVE-2022-3602, the fix is an upgrade to 3.0.7. No exploit fired. The scanner inferred risk from version banners, registry keys, installed package lists, and service responses.

That is the whole job. Vulnerability scanning is the automated discovery of known weaknesses across your assets, scored and prioritized so a defender knows what to fix first. It is the data-collection engine underneath a larger vulnerability management program, and it is the difference between knowing your exposure and guessing at it.

The volume is the reason it has to be automated. The CVE program published more than 40,000 new vulnerabilities in 2024, a record, and the rate has kept climbing. No team checks that many flaws against thousands of hosts by hand. This guide covers what scanning detects, the scan types and when each fits, the workflow from discovery to validated finding, how CVSS and EPSS turn raw findings into a fix order, and the limits you have to design around.

What Vulnerability Scanning Detects

A scanner looks for conditions that are already documented as dangerous. It does not invent new attacks or reason about your business. It matches the state of a system against known-bad patterns. Four categories cover most of what it flags.

• Missing patches. A host runs a software version with a published CVE and no vendor fix applied. This is the bulk of most scan output and overlaps directly with unpatched software tracking.
• Misconfigurations. Default credentials left in place, anonymous FTP enabled, TLS 1.0 still accepted, an S3 bucket set to public, a database listening on a public interface. The software is current; the settings are wrong.
• Exposed services. Ports and protocols reachable that should not be: an RDP port open to the internet, an unauthenticated Redis instance, an SMB share with no access control.
• Weak cryptography and policy. Expired or self-signed certificates, deprecated cipher suites, password policies that permit trivial values.

What a scanner does not do is confirm exploitability. It reports that a host presents the version and conditions associated with a CVE. Whether that flaw is reachable and weaponizable in your specific environment is a separate question, and answering it is the job of penetration testing, not the scanner. Keeping that line clear is what stops a team from drowning in findings that look urgent and are not.

Types of Vulnerability Scans

There is no single scan that sees everything. Each type trades coverage for intrusiveness, credentials, or vantage point. Mature programs run several in combination.

Authenticated vs. Unauthenticated

The sharpest distinction is whether the scanner logs in.

An unauthenticated scan probes a target from the outside with no credentials. It sees what an anonymous attacker on the network sees: open ports, service banners, responses to crafted requests. It is fast and safe to run broadly, but it infers a lot and misses anything that requires being inside the host. It produces more false positives because it is reading external signals, not ground truth.

An authenticated scan logs in with valid credentials and reads the system from the inside: installed package versions, registry settings, patch level, local configuration files. It is far more accurate and finds far more, because it inspects actual state instead of inferring it. The cost is credential management. You are handing scanning accounts to a tool, and those accounts need tight scoping and rotation.

Run both. The unauthenticated scan shows you the attacker's external view. The authenticated scan shows you the truth on the box. The gap between them is often itself a finding.

Agent-Based vs. Network-Based

This is about how the scanner reaches the target.

A network-based scan runs from a scanning appliance or host and reaches targets over the network. One scanner covers many hosts, but it only sees what is online and reachable at scan time, and it can miss laptops that were off or roaming.

An agent-based scan installs a lightweight agent on each endpoint. The agent collects local data continuously and reports back, so coverage does not depend on a device being reachable during a scan window. This suits remote and mobile fleets where network scans leave blind spots. The tradeoff is deployment and maintenance of the agent across every host.

External vs. Internal

External scans run from outside the perimeter against internet-facing assets, mapping what is exposed to the public. They are the scanner's-eye view of your attack surface management inventory. Internal scans run from inside the network and assume the attacker already has a foothold, finding the flaws that enable lateral movement and privilege escalation once a perimeter is breached.

By Asset Class

Scanning specializes by what it targets:

• Network and host scanning of servers, workstations, and infrastructure for OS and service flaws.
• Web application scanning that crawls an app and tests inputs for injection, broken authentication, and the OWASP Top 10. This is dynamic testing of a running app, distinct from infrastructure scanning.
• Database scanning for misconfigurations, weak permissions, and default accounts in database engines.
• Container and cloud scanning of images, registries, and cloud resource configurations, increasingly part of the build pipeline rather than a periodic event.

The Vulnerability Scanning Workflow

A scan is a pipeline, not a single action. Findings that skip the later stages are noise. The sequence below is what separates a usable report from a 5,000-line dump nobody acts on.

1. Discover assets. Identify every system, service, and endpoint in scope. You cannot scan what you have not inventoried, and unknown assets are where breaches start.
2. Enumerate. Determine open ports, running services, and software versions on each target. This is the fingerprint the next stage matches against.
3. Detect. Compare the fingerprint against vulnerability databases and vendor advisories. Each match becomes a candidate finding tied to a CVE.
4. Validate. Correlate results and cut false positives. An unauthenticated scan flagging a patched host by its banner is the classic false positive; authenticated data resolves it.
5. Score and prioritize. Assign severity using CVSS, exploit probability using EPSS, and your own business context. The output is a fix order, not an alphabetized CVE list.
6. Report and hand off. Route validated, prioritized findings to the owners who can remediate, then rescan to confirm the fix landed.

Stages four and five are where most programs fail. A scanner that detects well but does not validate and prioritize buries the real risks under volume. The 40,000-plus CVEs published in a single year do not all matter to you; the workflow exists to find the few hundred that do.

How Findings Get Scored: CVSS and EPSS

A raw finding is just "host X has CVE-Y." Two scoring systems turn that into a priority.

CVSS (Common Vulnerability Scoring System) rates severity on a 0 to 10 scale. It is maintained by FIRST, and the current version is CVSS v4.0, published in November 2023, which most mature programs are now adopting over the older v3.1. CVSS answers "how bad is this flaw if exploited," using base metrics like attack vector, complexity, and impact to confidentiality, integrity, and availability. The National Vulnerability Database (NVD), run by NIST, publishes CVSS scores for CVEs and is the data source most scanners draw on.

EPSS (Exploit Prediction Scoring System), also maintained by FIRST, answers a different question: how likely is this flaw to be exploited in the wild in the next 30 days. It is a probability from 0 to 1, generated by a machine-learning model trained on real exploitation data. A vulnerability can carry a high CVSS score and a low EPSS probability, meaning it is dangerous in theory but rarely attacked in practice.

The reason both matter: CVSS severity alone over-prioritizes. A large share of CVEs score "critical" on CVSS, but only a small fraction are ever exploited. EPSS and CISA's Known Exploited Vulnerabilities (KEV) catalog tell you which ones attackers actually use. A modern fix order weights all three: severity, exploit probability, and whether the flaw is on the KEV list, against the value of the affected asset.

Scanning vs. Adjacent Practices

Vulnerability scanning gets conflated with neighbors that do different jobs. The distinctions matter because they decide what you expect from a tool.

Scanning feeds all three. It is the recurring data source; assessment is a periodic interpretation of that data; penetration testing validates the worst findings by hand; and vulnerability management is the program that turns findings into fixes on a cycle. A scanner without a management process around it produces reports nobody closes.

Limits and False Positives

Scanning is necessary and incomplete. Designing around its limits is part of running it well.

• False positives. Unauthenticated scans infer from banners and guess wrong. A patched host that still advertises an old version string gets flagged. Validation with authenticated data is the fix, not turning off the check.
• False negatives. A scanner only finds what its plugins and feeds know about. Zero-days, custom application logic flaws, and business-logic abuse are invisible to it. Absence of findings is not proof of safety.
• Point-in-time gaps. A scan is a snapshot. A host clean on Monday can be vulnerable on Tuesday when a new CVE drops or a config drifts. This is why continuous and agent-based scanning is replacing quarterly scans.
• Disruption risk. Aggressive scans can crash fragile services or saturate links. Tune intensity and schedule around production windows; this is why teams stage scans rather than blasting everything at once.
• Volume without context. A scanner that reports every finding equally is a denial-of-service on your own team. Prioritization is not optional polish; it is what makes the output usable.

The honest framing: scanning tells you about known, documented weaknesses. It does not tell you about unknown ones, and it does not prove that a flaw is reachable. It is the floor of a security program, not the ceiling.

Frequently Asked Questions

What is vulnerability scanning?

Vulnerability scanning is the automated process of probing systems, networks, and applications for known security weaknesses by comparing their configuration and software versions against databases of documented flaws. It produces a scored, prioritized list of issues so defenders can fix the highest-risk ones first. It detects known vulnerabilities; it does not confirm that they are exploitable.

What is the difference between authenticated and unauthenticated scans?

An unauthenticated scan probes a target from outside with no credentials, seeing what an external attacker would see. An authenticated scan logs in with valid credentials and inspects the system from the inside, reading actual patch levels and configuration. Authenticated scans are far more accurate and find more, while unauthenticated scans show the external attacker's view. Best practice is to run both.

How often should you run vulnerability scans?

It depends on the asset and the program. Many compliance frameworks require at least quarterly external scans, but quarterly is a floor, not a goal. Internet-facing and high-value assets warrant weekly or continuous scanning, and agent-based scanning gives a near-continuous view. Because new CVEs are published daily, longer gaps leave you blind to fresh exposure.

Is vulnerability scanning the same as penetration testing?

No. Scanning is automated and identifies known flaws by matching against databases, but it does not exploit anything. Penetration testing is a human-driven effort to actively exploit flaws and prove real-world impact, including chained attacks and business-logic abuse a scanner cannot see. Scanning is broad and frequent; penetration testing is deep and periodic. They are complementary.

What do CVSS and EPSS scores mean?

CVSS (Common Vulnerability Scoring System) rates how severe a flaw is if exploited, on a 0 to 10 scale, and is maintained by FIRST. EPSS (Exploit Prediction Scoring System), also from FIRST, estimates the probability a flaw will be exploited within 30 days, from 0 to 1. CVSS tells you how bad it could be; EPSS tells you how likely it is to actually happen. Using both, alongside the CISA KEV catalog, produces a far better fix order than severity alone.

Can vulnerability scanning find zero-day vulnerabilities?

Generally no. A scanner detects vulnerabilities its plugins and threat feeds already know about, meaning publicly documented CVEs. A true zero-day has no signature for the scanner to match. Absence of scan findings is not proof of safety, which is why scanning is paired with detection, monitoring, and penetration testing rather than trusted on its own.