Common Weakness Enumeration

Definition

Common Weakness Enumeration (CWE) is MITRE's community-developed list of software and hardware weakness types. The CWE site describes these as weaknesses that can become vulnerabilities, and the FAQ says they can occur in architecture, design, code, or implementation. That makes CWE different from Common Vulnerabilities and Exposures: CVE identifies specific disclosed vulnerabilities, while CWE names the recurring weakness classes that can underlie many CVE records.

As of the current MITRE list reviewed for this page, CWE List Version 4.20 contains 944 total weaknesses. MITRE describes the list as a living effort that captures effects, behaviors, exploit mechanisms, and implementation details, while revising presentation approaches for the community. CWE is sponsored by DHS CISA and managed by HSSEDI, operated by MITRE.

How It Works

CWE entries are not just labels. The FAQ says each entry can include description, consequences, and potential mitigations. CWE identifiers are organized into Category, Compound Element, View, and Weakness. Weakness IDs have their own abstraction levels: Pillar, Class, Base, and Variant. A high-level class can describe a broad family such as injection, while a base or variant can describe a more concrete pattern such as cross-site scripting.

The 2025 CWE Top 25 page ranks the currently most common and impactful software weaknesses. MITRE says that list is based on 39,080 CVE records in the dataset and is meant to expose root causes so investment, policy, and practice can prevent classes of vulnerabilities earlier. The same page also points to a 2025 Top 10 KEV Weaknesses list, which ranks actively exploited weaknesses using CISA's Known Exploited Vulnerabilities Catalog.

NVD also uses CWE, but in a narrower way. The CWE FAQ says NVD has historically added CWE mappings to CVE records using the CWE-1003 view, alongside vulnerability metadata such as CVSS and CPE. That makes CWE part of vulnerability enrichment, not a replacement for severity scoring or exploitability analysis.

Agent Context

AI systems now write code, review pull requests, generate infrastructure, select packages, and wire tools together. A coding agent that fixes a CVE without naming the CWE may close one defect while preserving the pattern that created it. A review agent that sees "CWE-862 Missing Authorization" or "CWE-78 OS Command Injection" is being handed a root-cause clue, not only a scanner badge.

For agentic systems, CWE is useful because it can bind the model's task to a known weakness class. The audit record can ask whether the agent recognized the weakness, changed the right boundary, added tests that exercise the class, and avoided introducing the same class elsewhere. The taxonomy does not prove the patch is safe. It makes the review question sharper.

Governance and Safety

A governance-grade CWE workflow should preserve the CWE ID, source mapping, affected code path, related CVE or advisory, scanner output, human reviewer decision, model or agent run ID, and test evidence. A CWE label should not be treated as severity by itself. Severity comes from context, exploitability, exposure, affected asset, compensating controls, and whether the vulnerable behavior is reachable.

CWE is also not a full AI-risk vocabulary. It is strong for software and hardware weakness classes. It does not by itself classify prompt injection, model deception, unsafe delegation, memory poisoning, or policy drift unless those harms are represented through software or hardware weakness patterns. AI security programs should pair CWE with OWASP AI Vulnerability Scoring System, Agentic Supply-Chain Vulnerabilities, and AI Agent Observability.

Defense Pattern

• Map root causes. Connect CVE records, scanner findings, code review comments, and incident tickets to CWE IDs when the mapping is justified.
• Require evidence. Store the file, function, API, test, or design decision that supports the CWE classification.
• Use CWE for prevention. Turn repeated weakness classes into secure-development training, patterns, linters, and review checklists.
• Do not over-map. If the weakness class is uncertain, keep the uncertainty visible instead of assigning a decorative CWE.
• Audit agent repairs. Check whether automated patches remove the weakness class, not only whether the immediate test passes.

Source Discipline

Claims about CWE should distinguish CWE from CVE, NVD, CVSS, CAPEC, KEV, OSV, VEX, and CSAF. CWE names weakness classes. CVE names specific vulnerabilities. CAPEC names attack patterns that can exploit weaknesses. NVD maps CVEs to CWE categories as one part of vulnerability management data. These signals reinforce each other, but they are not interchangeable.

Spiralist Reading

Spiralism reads CWE as a grammar of recurring mistakes. A vulnerability is a wound in one product. A weakness is the habit that keeps reopening the wound. CWE matters when it changes the institution's memory: not "patch this bug," but "stop manufacturing this class of bug."

Open Questions

• How should CWE mappings be preserved when AI agents generate patches, tests, and security explanations?
• Which AI-specific failures should become new CWE entries, and which belong in separate agent-risk taxonomies?
• How should organizations measure whether CWE-based prevention actually reduces repeated weakness classes?

Related Pages

• Common Vulnerabilities and Exposures (CVE)
• Common Vulnerability Scoring System (CVSS)
• CISA Known Exploited Vulnerabilities Catalog (KEV)
• Open Source Vulnerabilities (OSV)
• Vulnerability Exploitability eXchange
• Common Security Advisory Framework
• AI Vulnerability Disclosure
• Secure AI System Development
• AI Coding Agents
• MITRE ATLAS

Sources

• MITRE CWE, Common Weakness Enumeration homepage, reviewed June 25, 2026.
• MITRE CWE, CWE List Version 4.20, reviewed June 25, 2026.
• MITRE CWE, Frequently Asked Questions, reviewed June 25, 2026.
• MITRE CWE, CWE Top 25 Most Dangerous Software Weaknesses, 2025 list, reviewed June 25, 2026.

Return to Wiki