CVE vs CWE vs CAPEC vs MITRE ATT&CK: What They Are and Why Your Content Needs Them

Security taxonomies get used interchangeably in conversation, and they should not be. Someone says "we found a CVE in the login flow" when they mean a CWE. A vendor page maps a product to "MITRE" without specifying ATT&CK, CAPEC, or ATLAS. A threat report cites a CVSS score as if it were a priority ranking.

The distinctions are not pedantic. Each of these frameworks answers a different question, and using the wrong one makes your analysis imprecise and your content less credible to the practitioners you are trying to reach. It also, as I will get to, quietly damages how AI search engines understand and cite your company.

I have spent years in cybersecurity and identity, and the pattern I keep seeing is that security companies produce content full of vague threat language when the vocabulary for precision already exists, is free, and is exactly what their buyers use. This article explains what each taxonomy does, how they chain together, why they belong in your product content, and where all of this is heading as AI reshapes both the threats and the way buyers find you.

The Four Core Taxonomies

Start with the four that do most of the work. The cleanest way to hold them is that they answer four sequential questions.

CWE: What Kind of Flaw Is This?

Common Weakness Enumeration catalogs types of software and hardware weaknesses. A CWE is a category, not a specific bug in a specific product.

CWE-89 is SQL Injection. CWE-79 is Cross-Site Scripting. CWE-287 is Improper Authentication. CWE-798 is Use of Hard-coded Credentials. There are over a thousand entries, organized hierarchically from broad classes down to specific variants.

CWE is the vocabulary of the builder. When a developer asks "what class of mistake did we make, and what other code might have the same problem," CWE is the answer. MITRE also publishes the CWE Top 25 Most Dangerous Software Weaknesses, which is the closest thing the industry has to a prioritized list of what actually goes wrong most often and most severely.

CVE: Which Specific Product Has It?

Common Vulnerabilities and Exposures identifies a specific instance of a weakness in a specific product and version. Each CVE gets a unique identifier in the format CVE-YEAR-NUMBER.

CVE-2018-13379 is the Fortinet FortiOS path traversal flaw that attackers used to gain entry to the ground infrastructure in the Viasat satellite attack. CVE-2025-32711 is EchoLeak. CVE-2026-25253 is a one-click remote code execution flaw in an AI agent product.

A CVE typically maps to one or more CWEs. The Fortinet flaw is a specific instance of a path traversal weakness class. That mapping is the first link in the chain: CWE tells you the category, CVE tells you where it actually lives.

CVE is the vocabulary of the defender doing patch management. It answers "does this specific thing in my environment need fixing right now."

CAPEC: How Does an Attacker Exploit It?

Common Attack Pattern Enumeration and Classification describes attack patterns from the attacker's perspective. Where CWE says "this code has a SQL injection weakness," CAPEC says "here is how an attacker constructs and delivers a SQL injection attack."

CAPEC-66 is SQL Injection as an attack pattern, pairing with CWE-89 as the underlying flaw. CAPEC entries describe prerequisites, attack steps, required skill level, and mitigations.

CAPEC is the vocabulary of the threat modeler. It sits between the weakness and the campaign, describing the technique used to turn a flaw into access. It is the least-used of the four in marketing content, which is part of why using it correctly signals genuine depth.

MITRE ATT&CK: What Does the Adversary Actually Do?

ATT&CK is a knowledge base of real-world adversary behavior across an entire intrusion, organized as tactics and techniques.

Tactics are the adversary's goals: Initial Access, Execution, Persistence, Privilege Escalation, Credential Access, Lateral Movement, Exfiltration, Impact. Techniques are the specific methods: T1566 is Phishing, T1078 is Valid Accounts, T1055 is Process Injection. Sub-techniques break these down further.

The distinction from the other three is important. CWE, CVE, and CAPEC are all about a flaw and its exploitation. ATT&CK is about behavior across a campaign, and much of what adversaries do involves no vulnerability at all. Logging in with stolen valid credentials exploits no CVE. It is still T1078.

ATT&CK is the vocabulary of the detection engineer and incident responder. It answers "what is the adversary doing in my environment, and do I have coverage for it."

ATT&CK evolves actively. The April 2026 v19 release split the Defense Evasion tactic in Enterprise ATT&CK into two new tactics, Stealth and Defense Impairment, added sub-techniques to ICS ATT&CK, and began introducing Detection Strategies in Mobile ATT&CK. If your content references ATT&CK mappings, version drift is real and worth tracking.

The Chain, With a Worked Example

The frameworks are most useful when you see them as links in one chain rather than four separate reference books.

Take the Viasat satellite attack of February 2022, which remains the clearest case study in the field.

CWE-22, Improper Limitation of a Pathname to a Restricted Directory, is the weakness class. Path traversal.

CVE-2018-13379 is the specific instance of that weakness in Fortinet FortiOS SSL VPN, with a patch available since 2019.

CAPEC-126, Path Traversal, describes how an attacker constructs the request to exploit it.

ATT&CK describes the campaign: Initial Access through the exploited public-facing application, then lateral movement into the trusted management network, then Impact through destructive wiper malware pushed to tens of thousands of modems.

Four frameworks, four questions, one incident. The weakness class, the specific vulnerable product, the exploitation technique, and the adversary's behavior across the intrusion. No single framework tells the whole story, which is exactly why using them precisely matters.

The Supporting Cast

Four more that come up constantly and get confused with the core taxonomies.

CVSS (Common Vulnerability Scoring System) assigns a 0 to 10 severity score to a CVE. It measures technical severity, not risk to you. A CVSS 9.8 in software you do not run is irrelevant; a CVSS 6.5 in your internet-facing authentication service may be your top priority. Treating CVSS as a priority queue is one of the most common mistakes in vulnerability management.

CISA KEV (Known Exploited Vulnerabilities catalog) lists CVEs confirmed to be exploited in the wild. For prioritization, KEV is far more actionable than CVSS alone, because it answers "is anyone actually using this" rather than "how bad would it be in theory." If a CVE is in KEV and it is in your environment, that is your queue.

D3FEND is MITRE's defensive counterpart to ATT&CK, cataloging defensive techniques and mapping them to the offensive techniques they counter. Less mature and less widely adopted than ATT&CK, but useful for articulating coverage.

ATLAS (Adversarial Threat Landscape for AI Systems) is ATT&CK for AI and machine learning systems. As of version 5.4.0 in February 2026, it contains 16 tactics, 84 techniques, 56 sub-techniques, 32 mitigations, and 42 case studies, freely available and published in STIX 2.1 for machine-readable integration. Prompt injection is AML.T0051. Memory poisoning is AML.T0080. I will come back to ATLAS, because it is where the most interesting movement is happening.

MITRE maintains CWE, CAPEC, ATT&CK, D3FEND, and ATLAS, and runs the CVE program under CISA sponsorship. That common stewardship is why they interlink as cleanly as they do.

Why Security Companies Should Build Content Around These

Now the part most security marketing teams miss. These taxonomies are not just engineering references. They are the single best vocabulary available for security product content, for three reasons.

They are the language your buyers already use. A security engineer evaluating your product does not ask "does it stop advanced threats." They ask whether you cover T1078, whether you detect the CWE classes in their code, whether you flag KEV-listed CVEs in their environment. Content written in vague threat language reads as marketing. Content written in the taxonomy reads as a product that was built by people who understand the problem. In a market where technical buyers are deeply skeptical of vendor claims, precision is the credibility signal.

They make claims verifiable. "Detects lateral movement" is unfalsifiable. "Detects T1021 Remote Services, including sub-techniques for SMB and RDP" is a claim a buyer can test. This is uncomfortable for marketing teams used to broad claims, and it is exactly why it works. Specific, checkable claims build trust that broad claims cannot.

They structure your content around how buyers actually search. Practitioners search for specific identifiers constantly. Someone hit by a new vulnerability searches the CVE number. Someone building detection coverage searches the technique ID. Someone doing a code review searches the CWE. These are high-intent queries with clear commercial value, and they are underserved because most vendors write around them rather than about them.

The practical implication for security product content: map your capabilities to specific technique IDs and weakness classes, publish that mapping, keep it current with framework versions, and write content that answers the specific-identifier questions your buyers ask. This is unglamorous work that outperforms another thought leadership piece about the evolving threat landscape.

The SEO, GEO, and AEO Angle Nobody Talks About

Here is where this connects to something I have written about extensively: how AI search engines decide what to cite. Security taxonomies turn out to be one of the strongest content assets a security company has for AI visibility, and almost nobody is using them that way deliberately.

The reason comes down to how these frameworks are structured. CVE-2018-13379, CWE-89, T1566, AML.T0051. These are globally unique, unambiguous entity identifiers. There is exactly one thing each string refers to, everywhere in the world, forever. That is a rare property in content, and it is precisely what retrieval systems are good at anchoring on.

For traditional SEO, this means these identifiers are high-intent, low-competition queries. When a new CVE drops, there is a window where practitioners are searching that identifier and very little authoritative content exists. Security companies that publish fast, accurate analysis on specific identifiers capture that traffic. The pattern holds for technique IDs and weakness classes on a longer, more evergreen timeline.

For AEO and GEO, the effect is stronger and less understood. AI engines ground answers by retrieving relevant sources and citing a small number of them, often just two to seven domains per response. Getting into that set requires content that is specific, factual, and unambiguously about the thing being asked. Taxonomy identifiers are as unambiguous as content gets. When someone asks an AI engine about a specific CVE or technique, content organized around that exact identifier is far easier for the retrieval step to match and cite than a general article that mentions it in passing.

There is a deeper structural point. I have argued that GEO is a product discipline rather than a marketing tactic, and that the durable advantage lives in how your product describes itself in machine-legible ways. Taxonomy mapping is one of the purest examples of that thesis. When you publish a structured mapping of your product's coverage to specific ATT&CK techniques and CWE classes, you are creating exactly the kind of factual, structured, entity-anchored content that AI systems can parse, trust, and cite. You are describing your product in a vocabulary that machines can resolve against an authoritative external reference.

Compare two pages describing the same capability. One says the product provides advanced protection against modern credential-based attacks. The other says it detects T1078 Valid Accounts and T1110 Brute Force, maps to CWE-287 Improper Authentication and CWE-798 Hard-coded Credentials, and flags KEV-listed CVEs in these categories. The second page is dramatically more citable, because every claim is anchored to a resolvable identifier. The AI can verify what you mean. The first page is marketing prose that gets filtered out.

A few practical moves that follow:

Build a structured coverage page mapping your product to specific technique and weakness IDs, and keep it versioned as frameworks update. Publish timely, accurate analysis when significant CVEs land in your category, since speed matters in that window. Use identifiers explicitly in headings and near the top of relevant pages rather than burying them. And make sure your documentation, which as I have written is the most underrated GEO asset most technical companies own, states coverage in taxonomy terms rather than marketing terms.

What the Age of AI Changes

Three shifts are reshaping these frameworks right now, and they cut in different directions.

AI systems have become the thing being attacked, and the taxonomies are racing to keep up. ATLAS is the clearest response. Its first 2026 update shifted focus from model-centric attacks toward execution-layer exposure, expanding coverage of agentic AI threats: autonomous workflow chaining, delegated authority persistence, and orchestration-layer risk. This mirrors what I have argued about agent identity, that authentication is necessary but insufficient, and that governing what agents do is the harder unsolved problem. ATLAS is building the vocabulary for that problem.

The vulnerability stream reflects it too. CVE-2026-25253 is a one-click remote code execution against an AI agent, where a crafted link chained multiple agent configuration settings into full host compromise. That is a new class of attack path, and it is now flowing through the same CVE pipeline as everything else. Memory poisoning being formally classified as AML.T0080, with evidence of active deployment across multiple industries, marks the shift from theoretical to operational.

AI is also changing how these frameworks are consumed. These knowledge bases are increasingly machine-read rather than human-read. ATLAS publishes in STIX 2.1. ATT&CK ships machine-readable JSON changelogs. Security tooling ingests them programmatically. As AI systems become the intermediary between practitioners and information, content anchored to machine-resolvable identifiers gets a compounding advantage, which reinforces the GEO argument above.

And the infrastructure underneath is more fragile than most people assume. In April 2025, MITRE warned that the DHS contract funding the CVE and CWE programs was set to expire, with the CVE program facing an abrupt shutdown. CISA exercised a contract option the night before expiry, granting an eleven-month extension into 2026. The programs remain operational, but their continuity depends on short federal budget cycles and shifting priorities. ATT&CK, by contrast, has continued active development through the same period.

That fragility deserves attention from anyone whose product or content depends on these identifiers. The entire industry's shared vocabulary for vulnerabilities rests on funding arrangements that nearly lapsed with a day's margin. Watching how the CVE program's governance evolves, including growing interest in alternative and distributed vulnerability databases, is worth doing if you build on this infrastructure.

The Takeaway

The four core taxonomies answer four different questions, and the chain runs in one direction: CWE tells you the class of weakness, CVE tells you the specific vulnerable product, CAPEC tells you how it gets exploited, and ATT&CK tells you what the adversary does with the resulting access. CVSS scores severity, KEV tells you what is actually being exploited, D3FEND catalogs defenses, and ATLAS extends the model to AI systems.

Using them precisely makes your security analysis better. Using them in your product content makes your claims verifiable in a market that has learned to discount vendor language. And using them as structured, entity-anchored content makes your company legible to the AI engines that increasingly decide which vendors appear on a buyer's shortlist.

That last point is the one I would emphasize to any security company reading this. You already have the most citable vocabulary in your industry sitting in your engineering team's heads. The frameworks are free, universally recognized, unambiguous, and exactly what your buyers search for. Most of your competitors are writing around them instead of with them. That gap is an opportunity, and it is open right now.

Related reading:

• How You Actually Secure Systems: OWASP and NIST Together - the frameworks that organize security programs
• How to Prevent a Data Breach - the fundamentals behind most CVE exploitation
• Browser Security 2025 - client-side weakness classes in practice
• MCP, RAG, and ACP: A Comparative Analysis - the AI infrastructure ATLAS now covers
• The Future of AI - where agentic AI risk is heading
• GEO Compass - vendor-neutral resource on AI search visibility
• How Security Buyers Actually Buy - the committee your taxonomy-anchored claims have to convince
• Why Cold Outreach to CISOs Fails - why precision beats persuasion with this audience