CWE

What Is CWE?

Common Weakness Enumeration (CWE) is a community-developed catalog maintained by MITRE Corporation that classifies and describes the types of software and hardware weaknesses that can lead to security vulnerabilities. While CVE identifies specific known vulnerabilities in specific products, CWE describes categories of weaknesses — the underlying coding patterns, architectural flaws, and design errors that make vulnerabilities possible in the first place.

Each CWE entry is assigned a numeric identifier (such as CWE-89 for SQL Injection or CWE-79 for Cross-Site Scripting) and includes a detailed description of the weakness, examples of vulnerable code in multiple languages, potential mitigations, observed instances in real software, and relationships to other CWE entries. The catalog currently contains over 900 entries organized in a hierarchical structure that ranges from broad categories (like CWE-707: Improper Neutralization) to highly specific weakness types (like CWE-89: Improper Neutralization of Special Elements used in an SQL Command).

CWE serves as the taxonomy that the rest of the security ecosystem builds upon. SAST tools map their findings to CWE identifiers. CVE entries reference the CWE weakness type that enabled the vulnerability. The OWASP Top 10 maps each risk category to its constituent CWE entries. Compliance frameworks reference CWE when specifying which weakness types must be addressed. This interconnected system creates a precise, machine-readable language for discussing software security that works across tools, organizations, and standards.

How It Works

The CWE hierarchy organizes weaknesses into a tree structure. At the top are abstract categories called Pillars, which branch into more specific Classes, Bases, and Variants. This structure lets security teams work at whatever level of granularity is appropriate for their context.

For example, the injection weakness family looks like this:

CWE-707: Improper Neutralization (Pillar)
  └── CWE-74: Injection (Class)
        ├── CWE-89: SQL Injection (Base)
        │     ├── CWE-564: SQL Injection: Hibernate
        │     └── CWE-943: Improper Neutralization in Data Query Logic
        ├── CWE-78: OS Command Injection (Base)
        ├── CWE-79: Cross-Site Scripting (Base)
        │     ├── CWE-80: Basic XSS
        │     ├── CWE-83: XSS in Attribute Values
        │     └── CWE-87: XSS in IMG Tags
        └── CWE-94: Code Injection (Base)

SAST tools use CWE identifiers to classify their findings. Here is an example of a Semgrep rule that maps to a specific CWE:

# Semgrep rule targeting CWE-78: OS Command Injection
rules:
  - id: os-command-injection
    patterns:
      - pattern: os.system($USER_INPUT)
      - pattern-not: os.system("...")
    message: >
      User input passed to os.system() may allow command injection.
      Use subprocess.run() with a list argument instead.
    severity: ERROR
    metadata:
      cwe:
        - "CWE-78: Improper Neutralization of Special Elements used in an OS Command"
      owasp:
        - "A03:2021 - Injection"

When this rule triggers, the finding includes the CWE reference, enabling teams to look up detailed remediation guidance:

# Vulnerable: CWE-78 — user input in OS command
import os

def ping_host(host):
    os.system(f"ping -c 4 {host}")  # Command injection via host parameter

# Fixed: use subprocess with argument list (no shell interpretation)
import subprocess
import re

def ping_host(host):
    if not re.match(r'^[\w.\-]+$', host):
        raise ValueError("Invalid hostname")
    subprocess.run(["ping", "-c", "4", host], check=True)

CWE entries also include real-world examples showing how each weakness has manifested in actual software. CWE-89 (SQL Injection), for instance, links to dozens of CVEs where the weakness was the root cause, demonstrating the tangible consequences of each weakness type.

Organizations use CWE to define their security testing requirements. A policy might state:

Security Policy: All applications must be tested for the CWE Top 25
Most Dangerous Software Weaknesses before release.

Required coverage:
- CWE-787: Out-of-bounds Write
- CWE-79: Cross-Site Scripting
- CWE-89: SQL Injection
- CWE-416: Use After Free
- CWE-78: OS Command Injection
- CWE-20: Improper Input Validation
- CWE-125: Out-of-bounds Read
- CWE-22: Path Traversal
- CWE-352: CSRF
- CWE-434: Unrestricted File Upload
  ... (and 15 more)

Why It Matters

CWE provides the foundation for systematic vulnerability prevention. While CVE tells you “this specific product has this specific vulnerability,” CWE tells you “this type of coding mistake leads to this type of vulnerability in any product.” This distinction is crucial because it shifts the conversation from reactive patching to proactive prevention. A team that understands CWE-89 (SQL Injection) as a weakness pattern can prevent it across their entire codebase, not just in the one place where a scanner happened to find it.

The CWE Top 25 Most Dangerous Software Weaknesses — published annually by MITRE based on the prevalence and severity of weaknesses observed in real CVE data — provides an empirical, data-driven prioritization for security training and testing. The list is computed from actual vulnerability data, not expert opinion, making it an objective measure of which weakness types cause the most real-world harm.

CWE also enables meaningful comparison of security tools. When evaluating SAST tools, organizations can compare which CWE entries each tool detects, identify coverage gaps, and make informed purchasing decisions. Without CWE as a common taxonomy, comparing tools would require mapping between proprietary rule names — a tedious and error-prone process.

For compliance, CWE provides the specificity that auditors need. Rather than stating “we test for injection vulnerabilities,” an organization can state “our SAST tooling covers CWE-89, CWE-78, CWE-79, CWE-94, and CWE-917, and our test suite includes cases for each.” This precision satisfies auditors and demonstrates a rigorous approach to security testing.

Best Practices

• Map your SAST tool coverage to the CWE Top 25. Identify which CWE entries your tools detect and which ones they miss. Fill gaps with additional tools, custom rules, or manual review procedures.
• Use CWE identifiers in your vulnerability tracking system. Tagging findings with CWE IDs enables trend analysis (are you seeing more CWE-79 findings over time or fewer?), root cause analysis, and targeted developer training.
• Train developers on the CWE entries most relevant to your technology stack. A web development team needs deep understanding of CWE-79, CWE-89, CWE-352, and CWE-22. A systems programming team needs CWE-787, CWE-125, and CWE-416.
• Reference CWE in code review checklists. Reviewers checking for specific CWE patterns are more effective than reviewers looking for vaguely defined “security issues.”
• Revisit the CWE Top 25 annually. The list changes as new vulnerability data is analyzed. Adjust your training and tooling priorities to reflect the latest rankings.

Common Mistakes

• Confusing CWE with CVE. CWE describes weakness types (categories of errors). CVE describes specific instances of vulnerabilities in specific products. A single CWE entry (like CWE-89) maps to thousands of individual CVEs.
• Treating CWE coverage as binary. “Our tool detects CWE-79” can mean anything from “it catches basic reflected XSS in one language” to “it detects all three XSS variants across 12 languages with data flow analysis.” Evaluate detection depth, not just coverage breadth.
• Ignoring CWE entries below the Top 25. The Top 25 represents the most dangerous weaknesses by data volume, but your specific application may be most vulnerable to CWE entries outside that list. Use threat modeling to identify which weaknesses are most relevant to your architecture and technology choices.
• Using CWE numbers without reading the full entries. Each CWE entry contains detailed descriptions, code examples, and mitigation strategies that are far more valuable than the one-line title. Developers who read the full CWE-89 entry will understand SQL injection far better than those who just see the label.