What Happened
A mid-market organization tracked 847 vulnerabilities across their environment. Over three months, they reduced this number to 623. The security team celebrated the progress.
However, an attacker exploited CVE-2023-XXXXX in their customer portal. This vulnerability had been identified 47 days earlier but was tagged "medium priority" based on its CVSS score. The team prioritized higher-scored items instead. The breach exposed customer data and triggered mandatory notification under state breach laws.
The issue wasn't missing the vulnerability. It was treating remediation as a counting exercise instead of a race against exploitation.
Timeline
Day 0: Vulnerability scanner identifies CVE in customer-facing web application. CVSS score: 6.8. Ticket created, assigned to backlog.
Day 14: Weekly triage meeting. Team reviews 23 new findings. CVE remains in backlog behind three "critical" items (CVSS 9.0+) affecting internal systems.
Day 28: Exploit code published on GitHub. No alert system in place to flag this change. Remediation ticket unchanged.
Day 42: Security team closes 15 vulnerability tickets. Monthly metrics show an 18% reduction in total vulnerability count. CVE still queued.
Day 47: Unauthorized access detected in customer portal logs. Incident response initiated. Forensics confirms exploitation of the 47-day-old CVE.
Day 49: Breach notification process begins. Legal, PR, and executive teams engaged.
Which Controls Failed or Were Missing
No Remediation SLA Tied to Exploitability: The team used CVSS scores alone to prioritize work. They had no process to escalate vulnerabilities when exploit code became available or when the vulnerability existed in internet-facing systems.
Vulnerability Management Treated as Inventory Control: Monthly reports tracked total counts, not time-to-remediation. Leadership saw declining numbers and assumed improving security. No one measured the gap between detection and fix.
Attack Surface Visibility Gaps: The organization knew about the CVE in their application code. They didn't know which systems were externally accessible, which had active exploits, or which protected sensitive data. Every vulnerability got the same generic risk rating.
No Compensating Controls During Remediation Delay: The vulnerable endpoint had no WAF, no rate limiting, no enhanced monitoring. The 47-day window was completely unprotected.
What the Relevant Standard Requires
PCI DSS v4.0.1, Requirement 6.3.1 states that security vulnerabilities are identified using reputable sources and that systems are protected from exploitation. It requires you to assign risk rankings based on your environment's exposure, not just vendor CVSS scores.
PCI DSS v4.0.1, Requirement 6.3.2 specifically addresses critical and high-risk vulnerabilities in internet-facing systems. You must install patches within one month of release. If you can't patch immediately, you must implement compensating controls. This organization did neither.
NIST CSF v2.0, Detect.CM-8 calls for vulnerability scans to be performed and remediation activities prioritized by risk. "By risk" means your risk, incorporating asset criticality, data sensitivity, and exposure, not just the abstract CVSS number.
ISO/IEC 27001:2022, Control 8.8 requires technical vulnerabilities to be identified and appropriate action taken "in a timely manner." Forty-seven days for an internet-facing customer portal doesn't meet any reasonable definition of timely.
Lessons and Action Items for Your Team
Implement Time-Based SLAs, Not Count-Based Metrics. Set maximum remediation windows based on system exposure:
- Internet-facing systems with known exploits: 7 days
- Internet-facing systems without known exploits: 14 days
- Internal systems with known exploits: 21 days
- Internal systems without known exploits: 30 days
Track mean-time-to-remediation in your monthly reports, not just total vulnerability counts.
Build an Exploit Intelligence Feed into Your Workflow. Subscribe to services that track when exploit code is published (CISA KEV, Exploit-DB, VulnCheck). Automatically escalate any vulnerability to priority 1 when an exploit becomes available. Don't wait for your next triage meeting.
Map Your Attack Surface Before You Prioritize Remediation. You can't assess real risk if you don't know which systems are externally accessible. Run an attack surface management scan quarterly:
- Enumerate all internet-facing IPs and domains
- Identify forgotten dev/staging environments
- Tag assets by data classification
- Cross-reference vulnerabilities against this map
Use this context to override CVSS scores. A CVSS 6.8 in your customer portal is higher priority than a CVSS 9.0 in an isolated internal tool.
Deploy Compensating Controls for Anything You Can't Patch Immediately. If you're going to miss your remediation SLA, you need protection during the gap:
- Web application firewall rules for the specific vulnerability
- Network segmentation to limit exposure
- Enhanced logging and alerting on the vulnerable endpoint
- Rate limiting or IP allowlisting if feasible
Document these compensating controls in your ticketing system. They're evidence of due diligence if you end up in a breach notification or audit.
Rewrite Your Vulnerability Management Policy. Replace "we scan monthly and remediate findings" with specific SLAs, escalation triggers, and compensating control requirements. Make it testable. Your auditor should be able to pull five random CVEs and verify you met your own timelines.
The vulnerability count looked good in this incident. The remediation speed didn't. Your next audit or breach investigation won't care how many vulnerabilities you closed last quarter. They'll care about the one you left open.
