What happened: The scanner used version-based signature matching without hotfix awareness. Every system at that version is flagged, even though all of them have had the vulnerability patched via a hotfix that the scanner cannot detect. These are false positives — the vulnerability does not exist on these systems as a practical matter.
The cost: The team spends time investigating and documenting 840 false positives (60% of 1,400) before reaching the genuine findings. In a three-analyst team, this false positive volume can consume multiple days of investigation capacity before any real vulnerability receives attention.
The fix: Tune the scanner to exclude systems confirmed to have the hotfix, update the scanner signature once the vendor releases a hotfix-aware detection method, and establish a validation step before scheduling any Critical remediation — confirm the vulnerability exists before treating the finding as actionable. Do not close these findings as false positives without documenting the investigation and the hotfix confirmation.
The exam-tested distinction: Any real finding, even one at Low severity, is not a false positive. A false positive means the vulnerability does not exist. A Low-severity real finding means the vulnerability exists but is not urgent.
What happened: The scan produced a false negative for a critical vulnerability because the signature database did not include the new vulnerability at scan time. The organization's review of the scan report created false confidence: they believed their environment was clean when seven servers were actually exposed, three of them directly reachable from the internet.
Why this is more dangerous than a false positive: A false positive creates unnecessary work. This false negative means the organization is not patching, not monitoring for exploitation, and not scanning those servers for indicators of compromise — while attackers with publicly available exploit code are actively probing for exactly this vulnerability.
The defense: Before relying on a scan report after a major public disclosure, update signatures and re-scan. Do not treat an existing scan report as covering newly disclosed vulnerabilities. When a high-severity vulnerability with public exploit code is disclosed, treat it as a potential false negative in any scan that predates the disclosure until a post-disclosure scan with updated signatures is complete.
What happened: Two scanners reported different scores for the same CVE because they are using different CVSS versions. CVSS 2.0 and CVSS 3.x use different methodologies and can produce substantially different scores for the same vulnerability. The security team relied on the lower (legacy) score without noting the version difference and deferred a Critical-severity finding for 28 days.
The consequence in context: A medical imaging system with a network-exploitable Critical vulnerability in a healthcare environment — where patient data and clinical operations are at stake — should be a 24–72 hour remediation target, not a 28-day one. The organizational context (healthcare, patient safety systems) further elevates the priority beyond what the CVSS score alone captures.
The lesson: When reviewing vulnerability findings, always note the CVSS version alongside the score. When two sources report different scores for the same CVE, use the higher (more current) version score as the basis for prioritization. For critical infrastructure organizations, the CVSS score is a floor for prioritization, not a ceiling — organizational context can only raise priority, not lower it.
Applying exposure factor analysis: Finding A (HR portal): a breach would expose employee PII to internal attackers; if the service goes down, employees cannot access HR functions. Estimated exposure factor: 15% (affects a small, internal-only function; no revenue impact). Finding B (checkout service): a breach exposes customer payment data and interrupts revenue generation; if exploited, the service could be disabled or compromised in ways that shut down all transactions. Estimated exposure factor: 80–100% (critical revenue path; external customer data; complete service loss possible).
The decision: With equal CVSS scores, the exposure factor drives prioritization. Finding B has a dramatically higher business impact per exploitation event. Even though the technical severity is identical, the business consequence of exploitation is not. Finding B should be patched first.
The formula in action: If the checkout service has an asset value of $2,000,000 (annual revenue throughput), an 80% exposure factor produces an SLE of $1,600,000 per incident. The HR portal at $100,000 asset value and 15% exposure factor produces an SLE of $15,000. Same CVSS score; 100× difference in business risk.
The dilemma: Standard policy (72-hour test cycle) minimizes the operational risk of deploying an untested patch that might break dependent applications. Following standard policy on a CVSS 9.8 vulnerability with confirmed active exploitation on 12 internet-facing servers means accepting a 72-hour window of known, actively-exploited exposure. This is the core patching dilemma: operational risk vs. vulnerability exposure window.
Risk tolerance adjustment: The combination of CVSS 9.8 score + active exploitation in the wild + internet-facing affected systems justifies compressing the standard test cycle. The calculated risk: deploy a less-thoroughly-tested patch and accept a small chance of application compatibility issues. The alternative risk: remain vulnerable for 72 hours to an actively exploited Critical vulnerability on internet-facing systems. For most organizations with reasonable risk tolerance, the former risk is dramatically lower.
The decision: Compress to a 4–8 hour accelerated test cycle in staging. Deploy to production by end of business Tuesday — within 12–15 hours of the exploit confirmation. Risk tolerance for a CVSS 9.8 with active exploitation on internet-facing systems is lower than for a CVSS 4.0 on an isolated internal system — the same organization, applied to different vulnerability contexts, has different appropriate risk tolerance levels.