27 — Vulnerability Management

Level: Intermediate · Time: ~20 min · Prerequisites: Lesson 26 — Threat Hunting

Why this matters

Every organisation that has ever run a scanner has a long list of findings and no idea what to do first. That gap is the entire subject of this lesson. A vulnerability is not a risk; it is a fact about software. It becomes a risk only when something reachable, valuable and actually in use is exposed to somebody who wants it — and deciding that is a human judgement that no scanner makes for you. Get this wrong in one direction and you patch by spreadsheet, drown in findings and eventually stop reading them. Get it wrong in the other and you spend two weeks on a "critical" that nobody can reach while an exploited flaw waits in the queue behind it.

This lesson is about turning a scanner report into a schedule of work with owners, dates and evidence — and about the metrics that make that schedule credible to people who are not security specialists.

The mental model: vulnerability, exploit, threat

Term	What it is	Example of the shape (not a specific finding)
Vulnerability	a weakness in software, configuration or design that could be misused	an unpatched service version that mishandles a crafted request
Exploit	the technique or code that turns the weakness into an effect	a public proof-of-concept that makes the service run a command
Threat	someone with the motive and capability to do it	an actor scanning for that exact service across the internet
Risk	the combination, applied to your asset, with your controls	what you actually decide about and pay for

Three of those four are outside your control. Only the vulnerability and the reachability of the asset are yours, which is why remediation — not scoring — is where the work happens.

And here is the sentence to remember: "we have 1,400 vulnerabilities" is a statement about your scanner, not about your risk. It says which checks the scanner supports, how deeply it was allowed to look, and how many assets were in scope. A number that large is usually the same twenty underlying conditions repeated across seventy machines: one missing patch baseline, one misconfigured service, one obsolete platform. Aggregate by cause, not by finding.

Inventory first, scanning second

You cannot manage vulnerabilities on machines you do not know exist. The worst findings in a typical organisation are almost never on the well-known production estate; they are on the forgotten test server, the shadow IT virtual machine somebody built for a project, the old branch router, the marketing department's file-share box and the cloud account that a former employee created. Scanner output is only as complete as your asset inventory, so the practical work starts with discovery, not with a scanner.

Discovery technique	What it gives you	What it costs
Network sweep and port scan of your own address space	hosts that answer, without needing credentials	finds hosts that are switched on; misses firewalled hosts and anything that is offline today
DHCP leases, DNS records, switch MAC tables	hosts that exist even when they are powered off right now	free, but requires the logs to exist
Endpoint agents (inventory or EDR) and configuration management	software inventory, patch level, owner, and the ability to query all of it	deployment effort, and coverage gaps you must measure
Cloud APIs and billing records	accounts, subscriptions and resources nobody told you about	free, and usually where the surprises are
The people	the project VM, the demo server, the intern's database	a meeting, and a policy that makes hidden assets a disciplinary matter

Scan mode	How it authenticates	Consequence
Unauthenticated (network-based)	it does not; it infers versions from banners and behaviour	works on anything, but infers — so it produces false positives and misses anything not visible on the network
Authenticated (credentialled)	logs in over SSH, SMB or a management API and reads the local package database	far fewer false positives and far more real findings: it sees the actual installed version of the actual library
Agent-based	a local agent reports inventory and patch state continuously	best coverage — including roaming laptops and hosts behind firewalls — and the best data for prioritisation

The rule that follows from the third row: scanning without credentials is a reconnaissance exercise, and scanning with credentials is vulnerability management. If a finding cannot be tied to a named asset with an owner, it cannot be fixed, so prioritise getting credentials and coverage before getting more frequency.

Cadence. Continuous or near-continuous for internet-facing and business-critical assets; monthly for the standard fleet; and immediately after significant change — a new deployment, a major upgrade, a migration, a reconfiguration. Scanning is designed to be non-destructive on a healthy service, but it can still restart a fragile legacy application or fill a log partition, so schedule it in an agreed window, tell the owners, and get written authorisation for anything you do not own. Lesson 30 covers the tooling in detail.

Scoring and prioritisation: the part that earns its keep

CVSS is the common severity score. It is built from a base metric group, with optional temporal and environmental adjustments, and it produces a number from 0.0 to 10.0.

Group	Metrics	What the base group asks
Exploitability	Attack Vector (network, adjacent, local, physical); Attack Complexity (low, high); Privileges Required; User Interaction	how easy is it to reach and trigger, from how far away, with what foothold and how much help from a victim
Impact	Confidentiality, Integrity, Availability, and Scope	what is affected if it works, and whether the blast radius escapes the vulnerable component
Temporal (optional)	exploit code maturity, remediation level, report confidence	how real and how available the exploit is today, and whether a fix exists
Environmental (optional)	modified base metrics plus security requirements for confidentiality, integrity and availability	what this finding means in your environment

Severity bands: 0.0 is none, 0.1–3.9 low, 4.0–6.9 medium, 7.0–8.9 high, 9.0–10.0 critical. Newer versions of the standard (CVSS v4.0) use a different metric set — do not put v3 and v4 scores in the same table, and say which version a score came from.

What CVSS does not tell you, and this is the honest limitation every junior needs:

It measures severity, not your exposure. A network-vector flaw on a service that only listens on the loopback interface carries the same score as one on your public web front end, and the risk is not the same by orders of magnitude.
It says nothing about whether anyone is exploiting it. A 9.8 with no exploit in the wild and no proof of concept is a different decision from a 7.5 that is actively being scanned for.
It does not know whether the asset matters. A critical score on an out-of-support marketing microsite is not a critical business event.
Almost nobody fills in the environmental group, which is precisely the group that reflects your reality. The published score is a default worst case; your score is the one you would defend in a budget meeting.

Two complements fix the exposure problem:

Exploitability scoring — EPSS. The Exploit Prediction Scoring System published by FIRST estimates the probability that a vulnerability will be exploited in the wild within 30 days. It is model output, it changes daily, and it is a complement to severity rather than a replacement: use it to separate the ten thousand findings that will never be touched from the few dozen that will.
A known-exploited list. National authorities maintain curated catalogues of vulnerabilities with confirmed exploitation in the wild — the best known being the United States CISA's Known Exploited Vulnerabilities catalogue, and CERT-FR advisories are the equivalent French-language source of alert bulletins for your region. Anything on such a list jumps the queue immediately, whatever its score.

Then apply the four-question triage, which any administrator can answer without a scoring model:

Question	If yes	If no
Is the asset reachable from the internet?	it is real risk today — act within days	deprioritise, unless the next answer is also yes
Is there a public exploit, or is it on a known-exploited list?	treat as exploited until proven otherwise	still patch, but at normal speed
Is the asset critical to the business?	combine with reachability: this is your urgent list	the risk is contained, schedule it
Is the vulnerable component actually in use?	the finding is real	it is a configuration cleanup, not an emergency

Remediation: owners, targets and the ones you cannot fix

A finding without a named owner is a finding that will still be open next quarter. The workflow is deliberately boring:

Assign an owner — a person, not a team. If nobody accepts a finding, that itself is the finding: escalate it, because unowned assets are where compromises start.
Set a response target by severity, agreed in advance and written down, so no discussion is needed under pressure.
Define what "fixed" means before the work starts, so it cannot be argued about afterwards.
Handle the unfixable with a compensating control or a recorded acceptance.
Verify, then close. A remediation that is not verified is a claim.

Severity	Internet-facing or known-exploited	Internal, standard fleet
Critical	2–7 days	14 days
High	14 days	30 days
Medium	30 days	90 days
Low	next change window	180 days or accept

Written down, the policy looks like this — an internal document, not a tool's configuration file:

# remediation-policy.yaml
targets:
  critical: { internet_facing: 7 days, internal: 14 days, known_exploited: 2 days }
  high:     { internet_facing: 14 days, internal: 30 days }
  medium:   { internet_facing: 30 days, internal: 90 days }
  low:      { internet_facing: 180 days, internal: 180 days }
closure_states: [patched, mitigated, accepted_in_writing]
accepted_requires: [owner, justification, compensating_control, review_date, approver]
verified_by: re-scan of the check that raised the finding

Those numbers are deliberately realistic. A policy promising "24 hours for all criticals" is a policy people learn to ignore; a policy of two to seven days for the ones that matter is one people can hold.

"Fixed" has exactly three acceptable meanings, and every closed finding must state which one it is:

Patched — the vulnerable version is gone, verified by a scan that no longer reports it.
Mitigated — the weakness remains but the path to it is closed: the service is bound to loopback or the management network, the feature is disabled, the vulnerable plug-in is removed, the end-of-life platform is isolated behind a policy that only permits what it needs.
Accepted in writing — with an owner, a justification, a compensating control and a review date, signed by somebody senior enough to own the consequence. Acceptance with a review date is a management decision. Acceptance without one is neglect with a signature.

For the case you cannot fix — an end-of-life appliance, a vendor's business-critical application that will never support the current library version — the tools are: compensating controls (a web application firewall rule for that one endpoint, network isolation, an intrusion detection rule on the specific exploit shape), restricting access (only the jump host, only the integration account), disabling the vulnerable functionality if the vendor allows it, and planning a replacement with a date, because "we accept this until the replacement lands" is only credible if the replacement has a budget line.

Verification and metrics

Re-scan the same check after the fix. Verify with the tool that found it if possible, from the same vantage point. "The admin said they patched it" is not a closed finding; a scan that no longer reports it is.

Metrics are where vulnerability management succeeds or fails politically, because the wrong ones create the wrong behaviour:

Metric	What it does	Verdict
Mean time to remediate, by severity	shows whether the promised targets are real, and where the queue sticks	use it
Percentage of internet-facing assets scanned on schedule	measures coverage of the thing that actually gets attacked	use it
Age of the oldest open critical and high	the backlog that will be exploited if anything is	use it
Number of findings with no owner	your real bottleneck, and it usually is not technical	use it, and watch it fall
"Percentage of vulnerabilities patched"	the denominator is whatever you scanned, so it improves when you scan less, and it treats a mitigated finding as a failure	do not report it
"Total number of vulnerabilities"	measures the scanner's verbosity; falls if you buy fewer checks	do not report it

[!TIP] If you report one number to management, report the age of the oldest unowned finding alongside the count of internet-facing criticals. It is honest, it is short, and it points at the only thing that cannot be fixed by a patch Tuesday.

Where findings come from, and a realistic first month

A large share of real-world reports arrive from outside, and knowing how to receive them matters as much as knowing how to scan.

Coordinated disclosure is the norm: a researcher reports privately, the vendor acknowledges and fixes, and the researcher publishes afterwards. Many organisations of every size publish a security contact page and a simple policy — "we will acknowledge within five working days, we will keep you updated, we will credit you if you wish" — which costs nothing and prevents the alternative, which is a researcher posting publicly because they could not find anyone to tell.
Bug bounty programmes are useful even for small organisations, and they do not require a payout table. A clear channel, a named contact and a promise to triage beats a public complaint, and the first report usually pays for the policy on its own.
If you find a vulnerability incidentally, the etiquette is firm: report it privately to a security contact or to the national CERT; give reasonable time before any publication, and agree an extension if the vendor asks and is genuinely working on it; do not publish before the fix; and do not access more data than needed to prove the point — three records, not the whole table, and never download, modify or keep what you saw. Access beyond your authorisation is an offence in most jurisdictions, including France, whatever your intentions, so the practical rule is: as soon as you realise you have gone further than you were allowed, stop and report.

Thirty days from nothing

Days	Work	Output
1–7	Discover and inventory: network sweep, DHCP and DNS records, agent and cloud API queries, then name an owner for every asset found	an asset list with owners and criticality, and a short list of assets nobody will claim
8–14	Scan the internet-facing range from outside, and the internal fleet with credentials; agree an authorised window first	a first honest baseline, and a list of what is exposed but should not be
15–21	Triage with the four questions; write the response targets down and get them approved; fix the internet-facing criticals	a prioritised queue, agreed SLAs, and the easy exposures closed
22–30	Re-scan to verify, publish a one-page metric (oldest unowned finding, internet-facing criticals, mean time to remediate), and calendar the monthly cadence with the next change window	a repeatable process, and a number you can defend

Attack it / Defend it

The attack	How it works	The control that stops it
Exploiting an unpatched internet-facing service	a known flaw with a public exploit is used for initial access	inventory, authenticated scanning, and short targets for internet-facing criticals
Exploiting a known-exploited vulnerability	an attacker uses a flaw that is already being exploited in the wild elsewhere	known-exploited catalogues as a priority override above raw score
Shadow IT and forgotten servers	an asset nobody tracks stays unpatched and unmonitored	discovery through DHCP, DNS and cloud APIs; ownership as a policy requirement
Living on an end-of-life platform	the vendor will never ship a fix, so the queue never clears	isolation, compensating controls and a funded replacement date, accepted in writing
Exploiting a misconfiguration rather than a bug	defaults, exposed admin interfaces and anonymous access need no CVE at all	compliance and hardening baselines, configuration drift monitoring
Targeting the vulnerable component in a library	the vulnerability is in a dependency, not the application	software composition analysis, SBOM, and agent-based inventory
Exploiting what the scanner could not see	custom code, business-logic flaws and authorisation bugs are invisible to a version check	application testing by a human (Lesson 30) and code review
Claiming a false positive to close a ticket	banner-based scanning reports a back-ported fix as vulnerable, so the finding gets dismissed — including the real ones	environmental scoring, verification by re-scan, and a review of dismissals
Attacking the scanner itself	it holds credentials for everything, so it is a high-value target	run it from a management network with least-privilege read-only accounts and protect its database
Reading the public report as a map	publishing your whole finding list, or a "security" page naming versions, hands over reconnaissance	keep findings internal, and keep public information minimal (Lesson 29)

Key takeaways

A vulnerability is a fact about software; risk is a fact about your business. Only the second one is worth a budget conversation.
Inventory before scanning. Findings on assets you cannot name and do not own are noise — and the worst findings always hide in the assets nobody remembers.
Authenticated scanning is the difference between reconnaissance and management. Unauthenticated results are guesses with good presentation.
CVSS gives you severity, a known-exploited list gives you urgency, and the four questions give you a decision. Use all three, in that order.
Report mean time to remediate and unowned findings, never the total count or the percentage patched. One measures your process; the others measure your scanner.

Check yourself

A scanner reports "1,412 vulnerabilities" across 70 servers. What is the first thing you do before opening the report, and why?
Explain in two sentences why an authenticated scan produces fewer false positives than an unauthenticated one.
A finding scores 9.8 and sits on a service reachable only from the management VLAN. A different finding scores 6.5 on your public login page. Which do you fix first, and what makes the decision defensible?
An end-of-life appliance cannot be patched. Write down the three acceptable ways to close that finding.
Why is "percentage of vulnerabilities patched" a metric that improves when you do less security work?