Prioritize and mitigate vulnerabilities
CVSS scoring in depth, context and exploitability, validation, compensating controls, and handling inhibitors to remediation.
- Reading time
- 28 min read
- Flashcards
- 18 cards
- Practice questions
- 8 questions · 2 PBQs
Nobody patches everything. A mid-size organisation's scanner produces tens of thousands of findings, and the remediation capacity is a handful of maintenance windows a month. Prioritisation is not a nicety — it is the entire discipline.
The central idea, and the one the exam returns to: severity is a property of the vulnerability; priority is a property of your environment. CVSS gives you the first. You supply the second.
CVSS, and what it does not know
CVSS base score
A 0–10 rating of a vulnerability's intrinsic severity, calculated from characteristics that never change: how it is reached, how hard it is to exploit, what privileges it needs, and what it costs you if it works.
The base metrics, and what each is really asking:
| Metric | The question |
|---|---|
| Attack Vector | Network, adjacent, local, or physical? Network is worst. |
| Attack Complexity | Does exploitation need conditions outside the attacker's control? |
| Privileges Required | None, low, or high? None is worst. |
| User Interaction | Does a victim have to click something? |
| Scope | Can it affect components beyond the vulnerable one? |
| Confidentiality / Integrity / Availability | What is lost if it succeeds? |
The consequential fact about the base score: it is calculated with no knowledge of your organisation. It does not know whether the host is internet-facing, whether it holds regulated data, or whether a compensating control already blocks the attack path. A 9.8 on an isolated lab machine and a 9.8 on your payment gateway are the same number and completely different problems.
Check yourself
Two findings arrive: CVSS 9.8 on an internal-only development server, and CVSS 7.5 on an internet-facing application processing card payments. Which should be remediated first?
The context that turns severity into priority
- Exposure — internet-facing, internal-only, or air-gapped. Reachability is the strongest single modifier.
- Asset criticality — what breaks, and who notices, if this system fails or leaks.
- Data sensitivity — regulated data changes both the impact and the legal consequences.
- Compensating controls — a WAF rule, segmentation, or disabled feature that blocks the path already.
- Exploit availability — is there working public exploit code?
- Active exploitation — is it being used right now, in the wild?
CISA KEV
The Known Exploited Vulnerabilities catalogue: a list of vulnerabilities confirmed to be actively exploited. A KEV entry is the strongest available argument for immediate action, because the theoretical question has already been answered by someone attacking somebody.
EPSS
Exploit Prediction Scoring System — a probability that a vulnerability will be exploited in the next 30 days. It complements CVSS rather than replacing it: CVSS says how bad it would be, EPSS says how likely it is to happen.
Validate before you prioritise
Prioritising a false positive wastes a maintenance window and burns credibility with the team that has to do the work. Before something enters the queue:
- True positive — reported and real. Remediate.
- False positive — reported and not real. Document why, and tune the scan so it stops recurring.
- False negative — real and unreported. Found by another method, and it means the programme has a gap worth investigating in its own right.
- True negative — correctly not reported. The silent majority.
Responding: the four options
Reduce the risk
- Mitigate — patch, reconfigure, or add a compensating control
- Avoid — remove the system or stop the activity entirely
Move or keep the risk
- Transfer — insurance, or contractually shifting it to a third party
- Accept — a documented decision to live with it, with an owner and a review date
The tellAcceptance is a formal decision made by someone with the authority to make it, recorded and revisited. 'We never got round to it' is not acceptance — it is an unmanaged risk wearing acceptance's clothes.
Compensating controls deserve emphasis because they are the answer whenever patching is impossible. A legacy system that cannot be updated gets network isolation, strict ACLs, and enhanced monitoring. That does not remove the vulnerability, and the record should say so — it reduces the likelihood of exploitation while the underlying issue remains.
Inhibitors to remediation
These come up repeatedly, and they are the reason vulnerability management is as much a negotiation as a technical exercise:
- MOUs and SLAs — an agreement may forbid changes during business hours, or a vendor contract may make patching their responsibility and their timetable
- Organisational governance — change advisory boards and approval cycles that add weeks
- Business process interruption — the patch requires downtime the business will not grant
- Degrading functionality — the fix breaks something the business depends on
- Legacy systems — no longer supported, and no patch is coming
- Proprietary systems — the vendor controls the code, and you may not touch it
Check yourself
A critical vulnerability affects a proprietary manufacturing system. The vendor no longer supports it, no patch exists, and the system cannot be replaced this year. What is the appropriate response?