CVSS vs EPSS: severity vs likelihood

Key: D

1. AFiling an exception and waiting for the vendor is too passive for a vulnerability that may already be exploited.
2. BMass quarantines and blocking all ingress before confirming exposure are disruptive and come in the wrong order.
3. CImaging every endpoint is incident response, not vulnerability triage, and patching before assessing exposure skips prioritization.
4. DCorrect: confirm exploitation signals in threat feeds and EPSS, check which assets are actually exposed, then assess available fixes or mitigations.

Key: B

1. AA known-exploited flaw on a high-value asset carries more real risk than a higher score on an isolated test box, so equal priority is wrong.
2. BCorrect: listing in CISA's Known Exploited Vulnerabilities (KEV) catalog proves real-world exploitation, and on a high-value asset that outweighs a higher CVSS score.
3. CThe 9.1 sits on an isolated test system, so its exposure and business impact are low despite the score.
4. DDeferring a known-exploited vulnerability on a high-value asset leaves the most likely attack path open.

Key: D

1. AThe table shows nothing about authentication requirements, and CVE-B was actively exploited, so it was clearly exploitable.
2. BCVE-A's higher score is exactly why it was patched first, and that score-only logic is what caused the breach.
3. CCVE-B is a documented CVE listed as actively exploited, so it was not an undocumented zero-day.
4. DCorrect: patching by score alone ignored that CVE-B was internet-facing and actively exploited, making it the real risk.

Key: C

1. ABase scores combine exploitability and impact metrics, so they measure more than exploitability.
2. BBase scores are meant to stay stable for a vulnerability; Threat (v4.0) or Temporal (v3.1) metrics are the ones that change over time.
3. CCorrect: base scores describe the vulnerability in general, not your asset value, exposure, compensating controls or threat activity, which is why Environmental and Threat metrics exist.
4. DCVSS is widely used and documented, so complexity is not its main limitation.

Key: D

1. AThe dev host is described as low value, so this reverses the actual asset priority.
2. BTreating both the same ignores exposure and asset value, which should set the order.
3. CRanking by CVSS alone ignores that the 9.8 sits on a low-value internal host.
4. DCorrect: an internet-facing production database has higher exposure and value, so its 6.5 flaw is the bigger real risk.

Key: C

1. AVULN-01 has the highest CVSS, but its EPSS barely moved (0.05 to 0.06), so its exploitation likelihood did not change.
2. BVULN-03's EPSS stayed at 0.15, so nothing escalated.
3. CCorrect: VULN-02's EPSS jumped from 0.02 to 0.89, meaning exploitation in the next 30 days is now very likely, which justifies emergency reprioritization.
4. DVULN-04's EPSS rose only slightly (0.10 to 0.12), and its high CVSS reflects severity without any change in exploitability.

Key: D

1. AEqual urgency for every finding wastes effort on low-risk items and delays the dangerous ones.
2. BCVSS alone measures severity and says nothing about whether exploits exist or how exposed the asset is.
3. CPublic exploit data is a key signal of real-world risk, so ignoring it misses active threats.
4. DCorrect: combining CVSS with exploit maturity, exposure, asset value and SLA requirements produces a risk-based remediation order.