Vulnerability management and CVSS scoring
Vulnerability management is the repeating process of finding weaknesses in systems, ranking them, fixing or mitigating them, and confirming the fix. CVSS (Common Vulnerability Scoring System) is the standard way to express how severe a vulnerability is, on a scale of 0.0 to 10.0. The decision rule for the exam: CVSS measures severity of the flaw itself, not risk to your organisation, so the first fix goes to the vulnerability that is both severe and exploitable on a system that matters, not simply to the highest number.
Four terms that exam questions blur
| Term | What it is | Example use |
|---|---|---|
| CVE | A public identifier for one specific known vulnerability | “CVE-” followed by year and number |
| CWE | A category of weakness, the type of mistake behind many CVEs | Buffer overflow, SQL injection |
| CVSS | A severity score for a vulnerability, from metrics describing how it can be exploited and its impact | 0.0 to 10.0 and a vector string |
| EPSS | A daily probability from FIRST that a published CVE will be exploited in the wild in the next 30 days | A value between 0 and 1 |
A CVE names the flaw, CVSS scores its severity and EPSS estimates how likely exploitation is. CISA also maintains a catalogue of vulnerabilities known to be exploited in the wild (KEV), which turns “could be exploited” into “is being exploited”.
How CVSS is built
CVSS is maintained by FIRST. The current version is CVSS v4.0, published in 2023; v3.1 is still common in vulnerability databases and in exam material, so know both.
Base metrics describe the vulnerability itself and do not change between organisations. In v3.1 they are attack vector, attack complexity, privileges required, user interaction, scope, and impact on confidentiality, integrity and availability. In v4.0, scope is gone and two things are added: attack requirements (conditions outside the attacker’s control that must exist), and impact is stated separately for the vulnerable system (VC, VI, VA) and for subsequent systems (SC, SI, SA).
Other metric groups adjust the picture. v3.1 has Temporal (exploit code maturity, remediation level, report confidence) and Environmental. v4.0 has Threat (exploit maturity), Environmental (security requirements for your asset and modified base metrics that reflect your own setting, such as compensating controls) and an optional Supplemental group that gives context but does not change the score. A base-only score is called CVSS-B in v4.0, while one with threat and environmental data is CVSS-BTE.
The qualitative severity scale is the same in both versions:
| Rating | Score |
|---|---|
| None | 0.0 |
| Low | 0.1 to 3.9 |
| Medium | 4.0 to 6.9 |
| High | 7.0 to 8.9 |
| Critical | 9.0 to 10.0 |
A v4.0 vector string looks like CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Read it left to right: reachable over the network (AV:N), low complexity, no special conditions, no privileges, no user interaction, high impact on confidentiality, integrity and availability of the vulnerable system, none on others. That is the profile of a Critical, remotely exploitable flaw.
Worked example: three findings, one maintenance window
A scan returns three findings and there is time to fix one this week.
| Finding | CVSS base | Context |
|---|---|---|
| A: remote code execution in a library on an internal test server | 9.8 (Critical) | No internet exposure, no sensitive data, no known exploitation |
| B: authentication bypass in the VPN gateway | 8.1 (High) | Internet-facing, public exploit code, listed as exploited in the wild |
| C: information disclosure on a printer | 4.3 (Medium) | Internal network, no data of value |
The step-by-step logic:
- Start from severity, which makes A the highest score.
- Add exploitability: B has exploit code and active exploitation; A has none.
- Add exposure and asset value: B is reachable from the internet and protects the entire network; A is an isolated test box.
- Result: B first, then A, then C. A temporary mitigation for A, such as restricting access, might be sufficient until the next window.
This is what environmental and threat metrics, EPSS and asset criticality formalise. The SY0-801 outline lists the same stages: identification (scanning and other methods), prioritisation, remediation, verification and reporting.
The management loop and the choices at each step
- Scan. Authenticated (credentialed) scans see patch levels and configuration and produce fewer false positives than unauthenticated ones. Unauthenticated scans show what an outsider sees.
- Prioritise. Combine severity, exploitability, exposure and asset criticality.
- Remediate. Patch when possible. If not, use a compensating control (network segmentation, a virtual patch, disabling the feature), or formally accept the risk with sign-off. Accepting is a decision, not a default.
- Verify. Rescan to confirm the fix. A patch that was installed but not verified is still an open finding.
- Report. Track time to remediate against agreed targets, per severity.
Exam traps and constraint words
- “Highest CVSS” versus “highest priority.” Scenarios that mention internet exposure, active exploitation or a business-critical system want the lower-score-but-riskier finding first.
- False positive versus false negative. A scanner reporting a flaw that does not exist is a false positive; missing a real flaw is a false negative. Credentialed scans mainly cut false positives.
- “Cannot patch” (legacy system, vendor refuses). The answer is a compensating control or segmentation, then documented risk acceptance, not ignoring it.
- “Identifier” versus “score”. CVE identifies, CVSS scores.
- Vulnerability scan versus penetration test. A scan lists potential weaknesses, mostly automatically; a penetration test attempts to exploit them to show real impact.
Which exams test this
| Exam | How the topic appears | Where it is covered on this site |
|---|---|---|
| SY0-801 | Threats, Vulnerabilities, and Attacks domain (24%), objective 2.1: vulnerability scoring with CVSS, prioritisation and CVE. Security Operations domain (27%), objective 4.3: identification (scanning, CSPM, source code review), prioritisation, remediation, verification and reporting, including bug bounties and responsible disclosure | SY0-801 security operations explained and SY0-801 threats, vulnerabilities and attacks explained |
| SC-500 | Manage and monitor security posture domain (20–25%): configure Microsoft Defender Vulnerability Management for Azure VMs and discover unprotected assets and vulnerabilities with Defender External Attack Surface Management; the Secure compute domain adds vulnerability scanning in Defender for Servers. The tools, not CVSS itself | SC-500 security posture explained |
| AZ-400 | Minor topic. Develop a security and compliance plan domain (10–15%): automate vulnerability analysis of open-source components with Dependabot alerts, plus code and container scanning | AZ-400 security and compliance explained |
| SC-900 | Minor topic. Microsoft security solutions domain (35–40%): describe Microsoft Defender Vulnerability Management, at fundamentals depth (outline as of October 21, 2026) | SC-900 Microsoft security solutions explained |
| AAISM | AI Risk Management domain (31%), subtopic 2B AI Threat and Vulnerability Management, with a supporting task on testing and vulnerability management of AI solutions. CVSS is not named | AAISM risk management explained |
Two practice questions
Question 1. A vulnerability scan reports two findings on the same day. Finding 1 has a CVSS score of 9.1 on an isolated lab server with no sensitive data and no known exploit. Finding 2 has a CVSS score of 7.5 on an internet-facing payment gateway, and a public exploit is being used in attacks. Which should be remediated first, and why?
- A. Finding 1, because it has the higher CVSS score
- B. Finding 2, because exposure, asset criticality and active exploitation outweigh the lower base score
- C. Neither, until an incident occurs
- D. Both are equal because both are rated High or Critical
Show answer
Answer: B
CVSS base scores measure the severity of the flaw, not the risk to the organisation. Finding 2 is exposed to the internet, protects a critical function and is being actively exploited, so its risk is higher despite the lower score. Choosing by score alone ignores context. Fixing both at once is not a prioritisation decision, and waiting for an incident contradicts the purpose of vulnerability management.
Question 2. A legacy industrial controller has a Critical vulnerability, but the vendor no longer supplies patches and the device cannot be replaced for a year. What is the best course of action?
- A. Ignore the finding because no patch exists
- B. Exclude the device from future scans
- C. Isolate the device with network segmentation and document the risk acceptance
- D. Rescan the device weekly and take no further action
Show answer
Answer: C
When a patch is unavailable, reduce the risk with compensating controls such as network segmentation and restricted access, and record formal risk acceptance for the remaining exposure. Ignoring the finding leaves the risk unmanaged. Removing it from scan scope hides the problem without reducing it. Rescanning does not change the vulnerability.