Insights · Security guide

Vulnerability scanning and vulnerability management explained

A vulnerability scan checks your systems against databases of known weaknesses and produces a list of findings. Scanning alone does not make you safer, though: value comes from a repeatable cycle in which you know your assets, scan them, rank the findings, fix what matters and prove that it is fixed.

Updated: 6 November 2026

Scanning versus managing

A scanner is a tool. Vulnerability management is the process around it. NIST describes enterprise patching as finding, ranking, obtaining, deploying and confirming fixes, and the same logic applies to vulnerabilities in general: detection is only the first step.

A scan is also not a penetration test. A scan is largely automated and broad, and it reports known issues. A penetration test adds human judgement and tries to chain weaknesses the way an attacker would. The German BSI describes its own penetration tests as an estimate of how likely a deliberate attack is to succeed, and recommends repeating such tests at regular intervals.

The main types of scanning

Different parts of your environment need different scanners. Most companies end up combining several.

• Network and host scanning: probes servers, workstations, network devices and open ports for missing patches and misconfigurations.
• Web application scanning: tests running web apps and APIs for flaws such as injection or broken access control. The OWASP Web Security Testing Guide is a widely used reference for what to cover.
• Cloud and container scanning: checks container images, code repositories, infrastructure-as-code files and Kubernetes clusters, ideally inside the build pipeline.
• Agent-based scanning: a small agent on each device reports its software state, which suits laptops, remote staff and systems that are rarely reachable from the network.

Authenticated versus unauthenticated scans

An unauthenticated scan sees your systems the way an outsider does: open ports, exposed services and visible versions. It is the right view for your internet-facing perimeter.

An authenticated scan logs in with a read-only account and inspects installed software, patch levels and settings from the inside. It finds far more, with fewer guesses and false positives, which is why it is the standard approach for internal systems. PCI DSS v4.0.1 goes as far as requiring authenticated internal scans for in-scope systems, according to an assessor's summary of requirement 11.3.1.2. Plan for secure handling of the scan credentials.

Tools you will come across

Tool choice matters less than coverage and follow-through. The following are neutral examples, not recommendations.

Greenbone Community Edition is open source; its OpenVAS Scanner runs vulnerability tests against target systems, and a commercial Greenbone Enterprise line exists alongside it. Tenable offers Nessus, described as a vulnerability assessment tool covering systems, devices, applications and web apps. Qualys markets VMDR with scanners, cloud agents and container sensors. Rapid7 positions InsightVM, which now sits inside its Exposure Command packages. For containers and infrastructure code, Trivy is an open-source scanner under the Apache-2.0 licence that covers images, file systems, Git repositories, Kubernetes and misconfigurations. For web apps, OWASP ZAP is a free and open-source option. Product names and bundles change, so check the vendor's current offer.

Prioritising findings: CVSS, EPSS and KEV

Every scan produces more findings than you can fix at once. Three public sources help you rank them.

CVSS rates technical severity. FIRST states that CVSS is currently at version 4.0, first released in November 2023. Scores should be labelled by the metric groups used: CVSS-B for base only, CVSS-BT when threat data is added, and CVSS-BE or CVSS-BTE when your own environment is considered. FIRST also notes that factors such as regulation or reputation are outside CVSS, so a high score is not automatically a high business risk.

EPSS, maintained by a FIRST special interest group, estimates the probability that a published CVE will be exploited in the wild within the next 30 days, and is updated daily. The CISA Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities with reliable evidence of active exploitation and a clear fix. US federal civilian agencies must act on it, while CISA strongly recommends that private organisations use it for prioritisation too.

• First: anything on the KEV list that exists in your environment, especially if exposed to the internet.
• Next: high EPSS probability or a public exploit, on systems that matter to the business.
• Then: high CVSS severity, adjusted for how important and how reachable the asset is.
• Last: low-severity issues on isolated systems, handled in normal maintenance.

The vulnerability management cycle

A workable programme repeats six steps.

• Inventory: know your hosts, cloud accounts, applications and software. You cannot scan what you do not know exists.
• Scan: choose scan types and credentials per asset group, and agree maintenance windows.
• Prioritise: combine severity, exploitation evidence and asset importance.
• Fix: patch, reconfigure or apply a compensating control, with a named owner and a deadline.
• Verify: rescan to confirm the finding is gone.
• Report: track open findings, time to fix and exceptions for management and auditors.

How often to scan, and in-house versus managed

Only one frequency rule is widely cited: under PCI DSS, external scans of in-scope systems must be run quarterly by a PCI-approved scanning vendor, with rescans until the result passes. PCI DSS v4.0.1 was published in June 2024 and is the version the PCI Council supports. Outside that, set frequency by risk and change rate, and rescan after significant changes.

Running scans in-house gives you control and fast feedback, but you need staff to operate scanners, tune results and chase owners. A managed vulnerability assessment suits smaller teams, or companies that need independent reports for customers or auditors. Whichever route you take, ask a provider these questions:

• Which asset types are covered, and will scans be authenticated?
• How are findings prioritised, and do they use exploitation data such as KEV or EPSS?
• How are false positives removed before you see the report?
• Is a rescan to verify fixes included, and how is remediation advice given?
• Where is scan data stored, and who can access it?
• How are production systems protected from scan impact?
• Do you receive raw data and an export, or only a PDF?