312 Base-Score-9.8 Findings Nobody Can Reach, and Nine That Matter
HealthCo's quarterly scan reports 2,140 findings across 1,150 servers in an estate of roughly 3,000 assets. Of these, 312 are CVSS 9.8 findings in a widely used open-source library. All 312 sit on internal-only application servers behind a WAF, with no internet egress; engineers confirm the vulnerable function is not reachable in how the library is used. Nine findings are CVSS 6.5 on internet-facing appliances: an information-disclosure issue and SNMP agents still using default community strings. One finding is CVSS 7.2 on a domain controller sitting in the DMZ. Two critical findings affect 40 OT imaging devices that cannot be patched and are supported by the vendor only through network isolation. Patching runs monthly in a six-hour window, and the change advisory board requires a rollback plan for every change; last month an emergency patch broke payroll for two days. The CISO has to brief the board next week and does not want to open with the number 2,140.
1. Prioritise the four finding groups and explain why base score alone produces the wrong order.
Read the worked answer
Base score answers "how bad is this vulnerability in the abstract?" It knows nothing about exposure, reachability, compensating controls, or what sits behind the asset. Prioritise on those.
1. The DMZ domain controller (CVSS 7.2). A domain controller in a DMZ is an architectural defect regardless of the CVE: a DMZ is the lowest-trust zone you own, and DC compromise means domain compromise. It is also an easy lateral path from any compromised appliance. Lowest score, highest consequence.
2. Default SNMP community strings on internet-facing appliances (CVSS 6.5). CVSS does not model "default credential." This needs no exploit development - it is a walk-up - and it hands an attacker an inventory of the estate, which accelerates everything else. Patch or reconfigure this week, not this quarter.
3. The 40 OT imaging devices. Unpatchable, but compromise stops clinical operations. The correct control is architectural: dedicated clinical VLAN, ACLs to only the required imaging and PACS hosts, no inbound internet, vendor access only through a monitored jump host. Urgent, but it is a design fix, not a patch.
4. The 312 findings at 9.8. Unreachable vulnerable code, no egress, WAF in front, internal only. These are currently low-likelihood. They are not "never": the library will get used differently after some future release, and the egress assumption can quietly change. Schedule library upgrades into the normal cycle and remove the enabling conditions.
The exam trap is ranking by score; the second trap is ranking by count.
2. Design an exception and compensating-control process for the OT imaging devices that will survive an audit.
Read the worked answer
An exception that survives audit has four properties: a named business owner, evidenced controls, a defined review point, and a stated risk in business terms.
Documentation: a formal risk acceptance signed by the clinical operations owner, not by IT, describing the impact in clinical terms (imaging unavailable, delayed diagnosis) and the residual risk. Attach the vendor's statement that patching is not supported and the reason.
Compensating controls, each with evidence:
- Network segmentation: the devices live on a dedicated VLAN with ACLs permitting only required peers; export the rule base and a topology diagram.
- No internet reachability, verified by a test from the device segment.
- Vendor remote support routed through a jump host with MFA and session recording; provide a sample session record.
- Passive monitoring only - active scanning of imaging equipment can cause outages, so use mirrored traffic and IDS signatures keyed to the specific CVEs.
- Asset inventory entry with owner, location, and the exception's expiry date.
Review: a review date tied to the vendor's support contract, a quarterly re-attestation, and automatic escalation to the risk committee if the vendor changes its position or the devices are replaced.
The audit test is not "is it patched" but "is the decision documented, are the controls operating, and does someone own the consequence." A spreadsheet saying "accepted risk" with no controls fails. Note also that the process needs to be repeatable, since OT will keep producing these.
3. What should the board see instead of "2,140 vulnerabilities"?
Read the worked answer
The board needs decision-relevant risk, not inventory. Give them five or six metrics with a trend and an owner.
- Externally exposed criticals against SLA: of the internet-facing findings, how many were remediated within the agreed window, and how many remain open past it. This is the number that maps to real breach likelihood.
- Exceptions expiring in the next quarter: count and business owner. This forces decisions rather than allowing silent accumulation.
- Time to remediate by exposure class, not by CVSS band - internet-facing, DMZ, internal, OT. A single mean is meaningless; the tail matters.
- Reachability coverage: what percentage of high-severity findings have actually been assessed for exploitability, so the board knows how much of the count is noise versus unexamined risk.
- Structural defects trending to zero: domain controllers in the DMZ, default credentials on internet-facing devices, unpatchable assets without segmentation. These are the fix-the-cause metrics.
- One comparable figure: the number of findings that could lead to a reportable data breach or clinical outage if exploited today.
Also be honest about the emergency-patch failure: report that an emergency change broke payroll, and that the process was adjusted rather than quietly abandoned. Boards handle bad news badly only when it arrives late. Avoid a slide whose only content is a count - it invites the question "is 2,140 a lot?" and there is no good answer.