CVE vs CWE vs CAPEC: How Flaws, Weaknesses and Attacks Connect

Teams that treat CVE, CWE and CAPEC as three interchangeable labels end up patching the same class of bug every quarter, writing threat models that never reach a test case, and reporting vulnerability numbers that say nothing about why the software keeps failing. The three MITRE-run catalogues answer different questions at different levels of detail: CVE names one disclosed flaw in one product, CWE names the type of mistake that made the flaw possible, and CAPEC names the way an adversary goes about exploiting that type of mistake. This guide starts from CAPEC, because it is the least used and the one that connects design to testing, then shows how the three chain together in threat modelling, secure design and triage. It is written for application security leads, threat modellers, vulnerability managers and architects. It assumes you know the basics of CVE records and CWE entries; the CVE, CWE and CPE Guide covers record formats and product naming, and the MITRE CAPEC Guide covers the anatomy of a CAPEC entry.

Key takeaways

• The short answer is instance, cause and method. A CVE is one vulnerability in a specific product version, a CWE is the weakness type behind it, and a CAPEC pattern is the adversary technique that exploits that weakness type.
• CAPEC belongs at design time. Attack patterns let a threat model move from "an attacker could tamper with requests" to named, testable abuse cases with prerequisites and mitigations, before any CVE exists.
• CWE is the bridge for fixing causes. Mapping your own findings and incoming CVEs to Base or Variant CWEs shows which mistakes recur, so you can remove a class of defect instead of chasing instances.
• CVE drives triage, not design. CVE identifiers, scores and exploitation status decide what to patch this week; they say little about what to build differently next quarter.
• Mapping quality decides the value. Vague mappings, such as tagging everything CWE-20, or Category and View IDs used as root causes, break the chain and make trend data meaningless.

Three catalogues, three questions

The confusion is understandable: all three are free, MITRE-operated, use numeric IDs with a short prefix and cross-reference one another. The difference is the unit of analysis.

• CVE (Common Vulnerabilities and Exposures): an identifier for one publicly disclosed vulnerability, assigned by a CVE Numbering Authority (CNA) and bound to affected products and versions. The question it answers is "which flaw, in which product, do we have to deal with?"
• CWE (Common Weakness Enumeration): a community-developed list of software and hardware weakness types. MITRE defines a weakness as a condition in a software, firmware, hardware or service component that, under certain circumstances, could contribute to the introduction of vulnerabilities. The question it answers is "what kind of mistake was made?"
• CAPEC (Common Attack Pattern Enumeration and Classification): a public catalogue of attack patterns, first released in 2007 under the US Department of Homeland Security software assurance work. MITRE describes attack patterns as design patterns applied in a destructive rather than constructive context, each based on analysis of real exploits and carrying mitigation guidance. The question it answers is "how would an adversary go about exploiting this kind of mistake?"

Put another way: a vulnerability is a weakness that exists in shipped code and is reachable; an attack pattern is the reusable method for reaching it. One CWE can sit behind thousands of CVEs, and one CAPEC pattern can apply to several CWEs.

Side-by-side comparison

The CAPEC figures come from the official CAPEC STIX dataset: 559 non-deprecated patterns, of which 61 are Meta, 181 Standard and 317 Detailed. Counts shift with each release, so treat them as orders of magnitude.

CAPEC first: attack patterns as the design-time lens

Most organisations use CVE daily, meet CWE through scanner output, and never open CAPEC. That is the wrong way round for anything still being designed, because at design time there are no CVEs yet and CWE describes mistakes rather than threats. CAPEC is the catalogue phrased from the adversary's side, which is how threat models are built.

What a pattern gives a threat modeller

• Prerequisites: the conditions that must hold for the attack to work. CAPEC-66 SQL Injection lists SQL queries used by the application and user-controllable input that is not properly validated as part of those queries. If your design removes a prerequisite, the pattern drops out of scope with a recorded reason.
• Related weaknesses: the CWEs the pattern exploits. CAPEC-66 points to CWE-89 and CWE-1286; CAPEC-664 Server Side Request Forgery points to CWE-918 and CWE-20. This is the link from threat to coding rule.
• Consequences: the security properties at stake. CAPEC-664 lists confidentiality (read data), integrity (modify data) and availability (resource consumption), which feeds risk rating directly.
• Mitigations: design and implementation counters. For CAPEC-664 the dataset lists URL validation, allowlisting every DNS name or IP address the application must reach, restricting URL schemes to HTTP or HTTPS, checking responses before returning them, and requiring authentication for local services.
• Hierarchy: Meta patterns are abstract (CAPEC-248 Command Injection, CAPEC-115 Authentication Bypass), Standard patterns are concrete techniques (CAPEC-66), and Detailed patterns are specific variants (CAPEC-7 Blind SQL Injection, a child of CAPEC-66).

Choosing the right level

Use Meta patterns when brainstorming against a data flow diagram in an early workshop, Standard patterns when writing abuse cases and security requirements for a feature, and Detailed patterns when a test team needs an unambiguous scope item. Mixing levels in one register produces duplicates: CAPEC-248 and CAPEC-66 are not two separate threats to the same query path.

CAPEC and ATT&CK are not competitors

MITRE positions CAPEC on application security and the exploitation of weaknesses in software, including social engineering and supply chain patterns, and ATT&CK on adversary behaviour across the intrusion lifecycle (persistence, lateral movement, exfiltration) drawn from threat intelligence. The two cross-reference where appropriate: CAPEC-112 Brute Force maps to ATT&CK T1110 Brute Force. A practical split is CAPEC inside the application boundary and ATT&CK once the adversary is through it. See the Threat Modelling Guide for method choice.

How the three chain together

The catalogues are most useful as one graph rather than three lists. Each edge has a direction and an owner.

Reading the chain forwards (design): a data flow that accepts a URL from a user raises CAPEC-664, which names CWE-918 and CWE-20, which become a coding rule, a static analysis rule and a test case. Reading it backwards (operations): a CVE with problem type CWE-89 in a supplier product tells you the attack class is CAPEC-66 and lets you ask whether your own code has the same weakness in other places.

Mapping examples from exploited vulnerabilities

The CWE entries below are taken from the CISA Known Exploited Vulnerabilities catalogue (version 2026.10.21); the CAPEC links come from the CAPEC dataset's related weaknesses.

Two patterns stand out in the same KEV snapshot of 1,754 entries: CWE-20 Improper Input Validation is the most frequent mapping (119 entries), and 175 entries carry no CWE at all. CWE-20 is a broad Class-level weakness, so its frequency tells you more about mapping habits than about root causes.

Using each one well: design, triage and threat modelling

Secure design and requirements

• Abuse cases from CAPEC: for each trust boundary in the data flow diagram, list the Standard patterns whose prerequisites hold. Record excluded patterns with the reason, such as "no user-supplied URLs, CAPEC-664 not applicable".
• Requirements from CWE: turn each in-scope pattern's related weaknesses into verifiable requirements. OWASP ASVS 5.0 requirements are a ready source of wording that maps naturally to CWE-89, CWE-918 and similar Base weaknesses.
• Language and framework choices: whole CWE families disappear with a design decision, such as memory-safe languages for out-of-bounds write (CWE-787) and use after free (CWE-416), or ORM query builders for CWE-89. This is where the CWE Top 25 earns its place in architecture reviews.

Triage and remediation

• CVE for the queue: prioritise by exposure, exploitation (KEV), CVSS and asset value. See the CVSS v4 Guide and the CISA KEV Catalogue Guide.
• CWE for the pattern: tag every internal finding (SAST, DAST, pen test, bug bounty) with a Base or Variant CWE. When three findings in a quarter share CWE-862 Missing Authorization, the fix is an authorisation framework, not three patches.
• CAPEC for verification: when retesting a fix, test the attack pattern, including its Detailed children, rather than the single reported payload. A fix for one injection point that leaves CAPEC-7 Blind SQL Injection working is not a fix.

Threat modelling

STRIDE or a similar method finds threat categories; CAPEC turns them into named patterns; CWE links them to code; ATT&CK links them to detection. A threat model whose rows carry a CAPEC ID and the related CWE IDs can be checked: the test plan should contain those patterns and the SAST policy should contain rules for those weaknesses. See the Threat Model Template.

Decision criteria: which catalogue to reach for

Small organisations: use CVE with KEV for operations and the CWE Top 25 as the coding standard; pick ten to fifteen Standard CAPEC patterns relevant to your stack as the threat modelling checklist. Large organisations and software vendors: make CWE mapping mandatory on every finding and advisory, maintain a curated CAPEC library per technology stack, and link both to SAST rules and test cases so coverage can be measured.

Worked scenario: one weakness, three views

A product team is building a feature that fetches a preview of any URL a user pastes. In the design review the threat modeller notes that the server makes outbound requests on user input, so the prerequisites for CAPEC-664 Server Side Request Forgery hold. The pattern's related weaknesses, CWE-918 and CWE-20, become two requirements: outbound requests go through an allowlisting egress proxy, and only HTTP or HTTPS schemes are permitted. The cloud team adds a third, drawn from ATT&CK T1552.005 Cloud Instance Metadata API: the workload uses token-required metadata access and a narrowly scoped role. The test plan includes CAPEC-664 with redirect and alternate encoding variants.

Six months later a third-party image library used by the feature receives a CVE whose problem type is CWE-918. Because the team already models the pattern, triage is fast: the egress proxy limits reachable destinations, so the CVE is patched in the normal cycle rather than as an emergency, and the root cause note records that the control worked. The Capital One breach shows the opposite path, where a request forgery weakness reached the metadata service and an over-permissioned role read storage buckets for months.

Failure modes in practice

• Mapping to the impact, not the cause: MITRE's root cause mapping guidance warns against copying impact or prerequisite language from a CVE description, such as "unauthenticated attacker" or "execute malicious code", into the CWE choice.
• Stopping at a Class: the same guidance asks for Base or Variant CWEs whenever possible and Class only when nothing more specific fits. Categories must never be used, and each CWE carries a usage label (Allowed, Allowed with careful review, Discouraged, Prohibited).
• Using a View as a weakness: CWE-1003, the simplified mapping view used by sources such as the NVD, is itself marked Prohibited for mapping; its member weaknesses are what you map to.
• Catalogue without tests: a threat model full of CAPEC IDs that never appear in a test plan or SAST policy is documentation, not assurance.
• Treating a missing CWE as "unknown risk": about one in ten KEV entries has no CWE. Absent mapping is a data gap to fill internally, not evidence that the cause is exotic.

Where identity fits

Several of the highest-impact chains end in a machine credential. Request forgery (CAPEC-664, CWE-918) is dangerous in the cloud because it can reach metadata endpoints that issue workload role credentials, and authentication bypass patterns under CAPEC-115 target the service accounts and tokens that applications trust. When a threat model row ends in "obtains credentials", record which non-human identity is at stake and how far its permissions reach. See the Cloud Instance Metadata Services Compared Guide.

Detection and measurement

• CWE mapping coverage: percentage of internal findings and published advisories with a Base or Variant CWE. Target above 90 percent.
• Recurrence rate by CWE: number of new findings per quarter in your top five CWEs. A falling line is the clearest evidence that design changes are working.
• Threat model to test traceability: share of in-scope CAPEC patterns in threat models that have at least one test case or scanner rule.
• Class-level mapping share: proportion of mappings to broad entries such as CWE-20 or CWE-284. Rising share means analysts are not drilling down.
• Time to triage for CVEs whose CWE is already modelled: compare with CVEs in unmodelled weakness classes to show the value of design work.

Framework mapping

Practitioner checklist

• Require a Base or Variant CWE on every internal finding, bug bounty report and published advisory, and review Class-level mappings.
• Build a CAPEC library of Standard patterns for each technology stack you run, with prerequisites to check at design time.
• Add CAPEC and related CWE IDs as columns in the threat model template, and trace each row to a test or scanner rule.
• Use CWE terms to compare and tune SAST and DAST coverage against your top recurring weaknesses.
• Prioritise CVEs with exposure and KEV status, then read their CWE to ask whether the same weakness exists in your own code.
• Retest fixes against the attack pattern and its Detailed children, not only the reported payload.
• Report a quarterly CWE recurrence trend to engineering leadership alongside CVE patch metrics.
• Train developers on the five CWEs that recur most in your own data, using the matching CAPEC patterns as examples.

Standards and references

• MITRE: About CAPEC
• MITRE CAPEC: CAPEC-664 Server Side Request Forgery
• MITRE: ATT&CK and CAPEC comparison
• MITRE: New to CWE
• MITRE: CWE Root Cause Mapping Guidance
• MITRE: 2025 CWE Top 25 Most Dangerous Software Weaknesses
• CISA: Known Exploited Vulnerabilities Catalog
• NIST: SP 800-218 Secure Software Development Framework

Related NHI Mgmt Group resources: CVE, CWE and CPE Guide · MITRE CAPEC Guide · CWE Top 25 Guide · Threat Modelling Guide · CVE Programme and NVD Backlog Guide