Running a scanner is easy. Every organization that buys one immediately produces tens of thousands of findings and then discovers the actual problem, which is that nobody can fix tens of thousands of things.
Vulnerability management is the program that turns that pile into a small number of things that get fixed, on a schedule, with proof.
The Loop
Discover what you have. Scan it. Triage the findings. Assign an owner. Fix or formally accept. Verify the fix. Measure how long the whole cycle took. Repeat.
The first step is the one that quietly breaks everything. Scanning only the assets you know about produces confident coverage numbers about an incomplete list. See asset management.
Scanning Properly
The main commercial scanners are Tenable Nessus, Qualys, and Rapid7 InsightVM. OpenVAS, part of Greenbone, is the established open source option and is fine for learning.
Authenticated scanning finds far more than unauthenticated scanning, because it can read installed package versions rather than guessing from banners. Unauthenticated scanning shows you what an outsider sees, which is a different and also useful question.
Run both. Agent based scanning has largely replaced network scanning for laptops, since remote devices are rarely on the network when the scan window opens.
Prioritization: Why CVSS Alone Fails
CVSS gives a severity score from 0 to 10. It is useful and it is widely misused as a work queue, because it describes the vulnerability in the abstract rather than the risk to you.
A CVSS 9.8 on an isolated lab machine with no network path matters less than a CVSS 6.5 on an internet facing server holding customer data. The score does not know that.
Two free data sources fix most of this. The CISA Known Exploited Vulnerabilities catalog lists vulnerabilities that are confirmed to be exploited in the wild. If something is on KEV and you have it, that is the top of your queue regardless of its score.
EPSS, the Exploit Prediction Scoring System, estimates the probability that a vulnerability will be exploited in the next 30 days. Most published vulnerabilities are never exploited, and EPSS is a much better filter for that than severity.
The practical formula is exploitation likelihood, multiplied by exposure, multiplied by asset importance. That produces a list a team can actually work through.
Ownership Is the Hard Part
Security teams almost never patch anything. Server teams, application teams, and desktop teams do. So the program lives or dies on whether findings reach someone who can act and whether that person is measured on it.
Route findings into the systems those teams already use rather than a separate security portal they will not open. Group by fix rather than by finding, because one patch often closes hundreds of findings and a list of hundreds looks unachievable.
Set remediation timelines by risk tier, agreed with the teams who have to meet them, and get leadership to back the timelines. Unagreed deadlines are ignored deadlines.
Exceptions Done Properly
Some things cannot be fixed. A vendor appliance with no update, an application that breaks with the patch, a system due for decommission.
An exception should name the risk, the compensating controls, the owner, and an expiry date. Exceptions without expiry dates become permanent, and a register full of them is a map of your real attack surface.
Review them on schedule. The single most common finding in a mature program audit is a pile of exceptions granted years ago for reasons nobody remembers.
Verification and Metrics
Verify by rescanning. A ticket marked done is a claim, not evidence, and patches fail to apply more often than people expect.
The metrics worth tracking are mean time to remediate by severity tier, the percentage of KEV listed vulnerabilities open right now, the age of the oldest unremediated critical, and scan coverage against the asset inventory.
Total vulnerability count is a bad metric. It moves with scanner updates and asset growth and tells you almost nothing about whether you are safer.
Where It Sits Next to Everything Else
A scan finds possible problems. A penetration test proves what an attacker could chain together. Breach and attack simulation tests whether you would detect it. Autonomous pentesting proves paths continuously.
They answer different questions and none of them replaces the others.
Learn This at HackRange
Week 6 of the mentorship covers this program end to end, including the prioritization argument that every security team has with every engineering team.