The Real Issue
Security teams often focus on patching high-CVSS vulnerabilities while attackers exploit medium-severity ones that are more impactful. The problem isn't technical capability; it's prioritization. Tools like Anthropic's Mythos can reduce exploit timelines from weeks to hours, but the real failure happens before the first scan runs. Your team prioritizes by severity score, not by what's reachable, privileged, or protecting revenue-critical data.
The Cycle of Misprioritization
This isn't about one incident. It's a cycle that repeats across organizations:
Day 0: Your vulnerability scanner flags 847 findings. 23 are "critical" by CVSS. Your team starts there.
Day 1-3: You begin patching internet-facing services with CVSS 9+ scores. An internal API gateway vulnerability (CVSS 6.8) is pushed to the next sprint.
Day 4: Mythos or a similar AI tool identifies the internal API vulnerability. It's accessible from a compromised developer workstation and has direct database access. CVSS didn't capture that context.
Day 5: Exploit code becomes public. The patching window has closed.
Day 6-30: Lateral movement, data exfiltration, containment. The post-mortem concludes: "We should patch faster."
Wrong lesson. You should prioritize smarter.
Missing Controls
Contextual Risk Assessment: Your scanner knows the CVSS score but not that the vulnerability is on a service account with db_owner privileges, accessible from the developer VLAN, protecting customer PII. CVSS 6.8 doesn't communicate "this is your crown jewel with the door unlocked."
Asset Criticality Mapping: You patched the DMZ first because it's internet-facing. Fair. But you didn't map which internal services have privileged access to Tier 1 data. The vulnerability that mattered wasn't the one with the highest score. It was the one on the path between an easily compromised endpoint and your database.
Identity and Access Correlation: Your vulnerability management tool and your identity provider don't communicate. You can't answer "which vulnerabilities are on systems with standing admin access?" Without that integration, you're patching in the dark.
Attack Path Analysis: You know you have vulnerabilities. You don't know which ones chain together. A CVSS 5.0 on a jump host plus a CVSS 6.0 on a database server equals full compromise if the jump host has cached credentials. Your tools see two medium-severity findings. An attacker sees a highway.
What Standards Require
PCI DSS v4.0.1 Requirement 6.3.1 mandates identifying security vulnerabilities using reputable sources and assigning a risk ranking. "Risk ranking" means understanding business context, asset criticality, and exploitability in your environment.
PCI DSS v4.0.1 Requirement 6.3.2 requires addressing vulnerabilities based on risk ranking. If your ranking is just CVSS, you're compliant on paper and exposed in practice.
ISO/IEC 27001:2022 Control 8.8 requires obtaining timely information about technical vulnerabilities, evaluating exposure, and taking appropriate action. "Appropriate" means contextual. A critical vulnerability on an isolated dev system isn't the same priority as a medium vulnerability on your payment processor.
NIST CSF v2.0 function Identify (ID.RA-01) calls for asset vulnerabilities to be identified and documented. But ID.RA-02 goes further: you must determine the likelihood and impact of cybersecurity risks. CVSS gives you half of that equation. You're missing impact to your specific assets and business processes.
NIST 800-53 Rev 5 Control RA-5 requires updating vulnerability scanning when new vulnerabilities are identified and reported. It doesn't say "patch by CVSS score." It says monitor and remediate based on risk.
The standards don't mandate CVSS-only prioritization. Your process does.
Action Items for Your Team
Map Asset Criticality Before the Next Scan Runs: Tag your assets by data tier, business function, and regulatory scope. Your scanner should know which systems process cardholder data, which store PII, which control OT environments. If you can't answer "what's our most critical asset?" you can't prioritize vulnerabilities on it.
Integrate Identity Context into Vulnerability Triage: Pull service account permissions, standing access, and privilege levels into your vulnerability management workflow. A CVSS 6.0 on a system with domain admin access is more urgent than a CVSS 9.0 on an isolated web server. Configure your tools to flag vulnerabilities on high-privilege accounts automatically.
Build Attack Path Visibility: Map network segmentation, trust boundaries, and credential exposure. Use tools that correlate vulnerabilities across the kill chain. Ask: "If an attacker compromises this workstation, what can they reach?" Then prioritize vulnerabilities on those reachable targets.
Redefine Your SLA: Stop promising "all critical vulnerabilities patched in 30 days." Start promising "all vulnerabilities on Tier 1 assets with exploitable attack paths remediated in 7 days." The second SLA is harder to measure. It's also the one that prevents breaches.
Test Your Prioritization with Tabletop Exercises: Give your team a scenario: "An attacker has a foothold on a developer laptop. Which five vulnerabilities in your current backlog would you patch first?" If the answer is "the five with the highest CVSS scores," you're not ready for AI-accelerated attacks.
Measure What Matters: Track mean time to remediate vulnerabilities on critical assets, not mean time to patch all criticals. Track the percentage of Tier 1 assets with exploitable attack paths, not total vulnerability count. Your metrics should reflect risk, not activity.
CVSS is a starting point. It's not a strategy. Mythos and tools like it compress the timeline between disclosure and exploitation. Your advantage isn't speed. It's knowing which vulnerabilities matter before the attacker does. Build that context into your process now, or keep learning it from post-mortems later.
