Most security teams use MITRE ATT&CK for one thing: building detection rules. The framework is phenomenally good at that. But the same knowledge base that describes what attackers do after gaining access also describes how they gain access in the first place, and that's where it intersects directly with your vulnerability management program.
When you map CVEs to ATT&CK techniques, you stop asking "is this CVE severe?" and start asking "does this CVE enable an attack technique that our threat actors use, on an asset we can't detect?" That's a fundamentally more useful question, and it produces a fundamentally more defensible prioritization decision.
How ATT&CK Tactics Map to CVE Attack Surface
The ATT&CK framework organizes techniques under 14 tactics representing phases of the adversary lifecycle. For vulnerability management, five tactics are most directly relevant:
- Initial Access (TA0001): Techniques for gaining a foothold. Most vulnerability-driven CVEs live here. T1190 (Exploit Public-Facing Application), T1133 (External Remote Services), T1078 (Valid Accounts) all map to specific CVE classes.
- Execution (TA0002): Running attacker-controlled code. RCE CVEs map here. T1059 (Command and Scripting Interpreter) is the most common execution technique.
- Privilege Escalation (TA0004): Local privilege escalation CVEs (Linux kernel vulns, Windows token impersonation) map to T1068 (Exploitation for Privilege Escalation).
- Defense Evasion (TA0005): CVEs that disable or bypass security controls. Less common but extremely high value to patch because they directly undermine detection capability.
- Lateral Movement (TA0008): CVEs in internal-facing services that allow spreading from one compromised host to others. SMB, RDP, and internal API vulnerabilities live here.
The key insight is that Initial Access CVEs deserve asymmetric urgency. They're the entry point. Every downstream tactic (Execution, Persistence, Privilege Escalation, Lateral Movement) becomes possible only after Initial Access succeeds. Patch the entry point and you eliminate entire attack chains.
T1190: Exploit Public-Facing Application: Deep Dive
T1190 is the ATT&CK technique that directly maps to the CVEs most commonly exploited in the wild. It covers the exploitation of software weaknesses in internet-facing applications to gain unauthorized access. According to MITRE's own data, T1190 is one of the most frequently observed Initial Access techniques across all threat actor groups tracked in the enterprise matrix.
What falls under T1190 in practice:
- Web application vulnerabilities (SQLi, SSRF, deserialization, template injection)
- VPN and remote access appliance CVEs (Ivanti, Pulse Secure, Fortinet, Cisco ASA)
- Exchange and email server exploits (ProxyLogon, ProxyShell, CVE-2024-21413)
- Firewall and network device management interface exploits
- API gateway and service mesh vulnerabilities exposed to the internet
Identifying T1190-Relevant CVEs in Your Environment
Not every CVE in your scanner output is a T1190 candidate. The filter criteria:
- Attack vector = Network in CVSS (eliminates local/physical access requirements)
- No authentication required (privileges required = None in CVSS)
- Asset is internet-facing (requires accurate asset inventory with exposure tagging)
- Vulnerability class = RCE, auth bypass, or arbitrary file read/write
In NVD's CPE data, you can query for CVEs affecting specific products that your internet-facing assets run. Cross-reference with CVSS vector string AV:N/AC:L/PR:N (Network, Low complexity, No privileges) to find the worst candidates.
Building a Vulnerability-to-Technique Mapping
The MITRE ATT&CK knowledge base is available as a STIX 2.1 JSON feed at https://raw.githubusercontent.com/mitre/cti/master/enterprise-attack/enterprise-attack.json. This feed includes explicit CVE references in technique objects, not comprehensively, but enough to bootstrap a mapping.
Here's the approach for building your own mapping pipeline:
Step 1: Pull ATT&CK STIX bundle
GET https://raw.githubusercontent.com/mitre/cti/master/
enterprise-attack/enterprise-attack.json
Step 2: Extract CVE references from technique external_references
Filter objects where type == "attack-pattern"
Extract external_references where source_name == "cve"
Step 3: Cross-reference your scanned CVE inventory
Match your scanner output CVE IDs against the ATT&CK CVE reference list
Flag matched CVEs with associated technique ID(s)
Step 4: Enrich unmatched CVEs by keyword
For CVEs not in ATT&CK directly, classify by:
- CWE ID → technique family mapping (see table below)
- Product category (VPN, Exchange, Web Server → T1190)
- CVSS attack vector + privileges requiredCWE to ATT&CK Technique Mapping Reference
| CWE | Description | Primary ATT&CK Technique | Tactic |
|---|---|---|---|
| CWE-78 | OS Command Injection | T1059 Command Interpreter | Execution |
| CWE-89 | SQL Injection | T1190 Public-Facing Application | Initial Access |
| CWE-119 | Buffer Overflow | T1068 Exploitation for Priv. Esc. | Privilege Escalation |
| CWE-287 | Improper Authentication | T1078 Valid Accounts / T1190 | Initial Access |
| CWE-502 | Insecure Deserialization | T1059 / T1190 | Initial Access / Execution |
| CWE-918 | SSRF | T1090 Proxy / T1190 | Initial Access |
| CWE-22 | Path Traversal | T1083 File and Directory Discovery | Discovery |
Scoring CVEs by ATT&CK Coverage
Once you've mapped CVEs to ATT&CK techniques, you can score them by the quality of your detection coverage for that technique. This is the key insight that makes ATT&CK-based prioritization powerful: a CVE enabling a technique you can't detect is worth more urgency than a CVE enabling a well-detected technique.
The scoring formula:
ATT&CK Priority Score = Base Severity × Technique Weight × (1 - Detection Coverage)
Where:
Base Severity = EPSS × 100 + (CVSS / 10 × 20) [0-120 scale]
Technique Weight = {
TA0001 Initial Access: 1.5 (entry point multiplier)
TA0002 Execution: 1.3
TA0004 Privilege Escalation: 1.2
TA0008 Lateral Movement: 1.4
All others: 1.0
}
Detection Coverage = your SIEM coverage for that technique [0.0 - 1.0]
Example: T1190 with 40% detection coverage → (1 - 0.4) = 0.6 multiplierA CVE with EPSS 0.6, CVSS 8.5, mapped to T1190 (Initial Access), and your org has only 40% detection coverage for T1190:
Base Severity = (0.6 × 100) + (8.5 / 10 × 20) = 60 + 17 = 77
Technique Weight = 1.5 (Initial Access)
Detection Coverage modifier = 1 - 0.4 = 0.6
ATT&CK Priority Score = 77 × 1.5 × 0.6 = 69.3
Compare: same CVE, T1083 (Discovery), 90% coverage:
77 × 1.0 × (1 - 0.9) = 7.7 ← dramatically lower priorityPractical Implementation: Getting Started in 5 Steps
- Export your current CVE inventory with CVSS vector strings (specifically AV, PR fields) and CWE IDs. Most scanners export this in CSV or XML.
- Download the ATT&CK STIX bundle and extract technique-to-CVE mappings using a JSON parser. The MITRE CTI GitHub repository has the full dataset. Alternatively, use the ATT&CK Workbench API.
- Build your detection coverage baseline. Query your SIEM for active detection rules by ATT&CK technique ID. Tools like ATT&CK Navigator let you visualize and export coverage as JSON.
- Run the scoring formula across your CVE inventory. Even a spreadsheet-based implementation produces useful results in the first pass.
- Validate your top-20 results against CISA KEV and EPSS. If your ATT&CK score surfaces CVEs that are also in KEV, your mapping is working correctly. If it surfaces CVEs with EPSS < 0.01, revisit your detection coverage data.
Real-World Application: Hardening Against Specific Threat Groups
ATT&CK's threat group profiles (Groups section, e.g., G0007 for APT28, G0016 for APT41) document the specific techniques each group uses. This enables targeted prioritization: if you're a healthcare organization primarily concerned about Lazarus Group (G0032), you can extract their technique profile and filter your CVE inventory specifically for vulnerabilities that enable Lazarus-used techniques.
# Pseudo-code: filter CVEs relevant to a specific threat group
threat_group = "G0032" # Lazarus Group
lazarus_techniques = get_techniques_for_group(attack_stix, threat_group)
# Returns: [T1190, T1133, T1059.003, T1486, T1489, ...]
prioritized_cves = [
cve for cve in your_cve_inventory
if any(t in lazarus_techniques for t in cve.attack_techniques)
and cve.asset_is_internet_facing
]This approach is used by threat-informed defense programs at large enterprises. It's also how government agencies translate specific threat intelligence ("APT X is targeting your sector") into concrete patch priority decisions, rather than panic-patching everything. They patch the specific vulnerability classes that the named group exploits.