Skip to main content
v2026.11,858 entries · CC-BY 4.0
LAC HealthMedical & Research SuppliesReagents, PPE & instruments — chain-of-custody documented.Fast, traceable sourcing built for regulated research environments, from bench consumables to instrumentation.Shop lac.us CodeCASRAIlac.us

CWE: Common Weakness Enumeration Platform Guide

A guide to Common Weakness Enumeration (CWE): software and hardware weakness hierarchies, CWE vs CVE differences, CWE Top 25, and root cause mapping.

Written and maintained by CASRAI Editorial Board

Last updated

Common Weakness Enumeration (CWE) is a standardized, community-developed dictionary and classification taxonomy of security weaknesses found in software, firmware, and hardware architecture, design, and code. Sponsored by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and operated by The MITRE Corporation, CWE serves as a common language for identifying, mitigating, and eliminating the underlying flaws that give rise to exploitable vulnerabilities.

In academic computing environments, scientific software development, and modern cybersecurity operations, CWE provides the structural framework necessary to perform root-cause vulnerability analysis, establish secure coding standards, and automate static application security testing (SAST).

What It Is

Common Weakness Enumeration (CWE) is a formal catalog of weakness types rather than a list of specific flawed software releases. A “weakness” in the context of CWE is defined as a condition, bug, or architectural defect in software, firmware, hardware, or service components that, under certain circumstances, can contribute to the introduction of vulnerabilities or allow an attacker to disrupt system security.

The CWE catalog organizes weaknesses into an abstraction hierarchy comprising four foundational levels:

  • Pillars: Highly abstract weakness groupings representing fundamental security concepts (e.g., CWE-682, Elementary Math Error, or CWE-699, Software Development).
  • Classes: Conceptual weaknesses described independently of specific programming languages, frameworks, or architectures (e.g., CWE-119, Improper Restriction of Operations within the Bounds of a Memory Buffer).
  • Bases: Concrete, actionable weakness descriptions that are specific enough to inform actionable engineering mitigations and code reviews (e.g., CWE-120, Buffer Copy without Checking Size of Input).
  • Variants: Highly specific weaknesses tied to particular languages, implementation environments, or hardware design primitives (e.g., CWE-121, Stack-based Buffer Overflow).

Who Runs It and What It Covers

The CWE program is sponsored by the office of the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA). It is managed and maintained by the Homeland Security Systems Engineering and Development Institute (HSSEDI), a Federally Funded Research and Development Center (FFRDC) operated by The MITRE Corporation. Strategic direction and review are provided by the international CWE Board, which includes representatives from commercial security software vendors, operating system developers, government agencies, and academic research institutions.

While historically concentrated on software vulnerabilities, modern CWE encompasses both software and hardware domains:

  • Software Weaknesses (CWE-1000): The Complete Weakness Hierarchy captures flaws across memory management, cryptographic operations, access control, input handling, and concurrent execution.
  • Hardware Weaknesses (CWE-1194): Encompasses weaknesses in silicon design, microarchitectural execution, System-on-Chip (SoC) interconnects, privilege rings, side channels, and physical interfaces.
  • CWE Top 25 Most Dangerous Software Weaknesses: An annual, empirical ranking calculated by correlating public vulnerability records with frequency of occurrence and average Common Vulnerability Scoring System (CVSS) severity scores.
  • CWE Most Important Hardware Weaknesses (MIHW): A curated annual list prioritizing silicon-level and firmware vulnerabilities in consumer, industrial, and defense hardware.

CWE entries serve as the root-cause taxonomy behind the National Vulnerability Database (NVD) and interface directly with threat actor taxonomies such as the MITRE ATT&CK framework to trace exploit techniques back to source code defects.

How to Search or Use It

Security engineers, research software developers, and system administrators navigate and integrate CWE into development workflows through structured documentation processes:

  1. Navigate Weakness Views: Access the official portal (cwe.mitre.org) and select a specialized View (such as View 1000 for comprehensive research, View 699 for software development, or View 1194 for hardware design).
  2. Search by Weakness Identifier: Search by CWE-ID (e.g., CWE-79 for Cross-site Scripting, CWE-89 for SQL Injection, or CWE-787 for Out-of-bounds Write) or keyword.
  3. Analyze Weakness Details: Review the formal description, alternate terms, applicable platforms (languages, architectures, technologies), and demonstrative code examples.
  4. Review Potential Mitigations: Examine the phase-specific mitigations provided in the entry, covering Architecture and Design, Implementation, Build and Compilation, and Operation phases.
  5. Perform Root Cause Mapping: When reviewing security bugs or vulnerability alerts, map each issue to its corresponding Base or Variant CWE-ID to detect systemic developmental flaws.
  6. Configure Automated Testing Rules: Integrate CWE identifiers into static application security testing (SAST) and dynamic testing (DAST) pipelines to benchmark code quality against established standards.
  7. Download Machine-Readable Schemas: Retrieve the complete CWE list in XML, JSON, or CSV formats for local ingestion, compliance audits, or empirical security research.

Strengths and Limits

Deploying CWE within institutional repositories and computing centers presents distinct capabilities and boundary conditions:

  • Root-Cause Elimination: By focusing on classes of weaknesses rather than single bug instances, CWE allows developers to prevent entire families of vulnerabilities before deployment.
  • Universal Reference Standard: Eliminates terminology ambiguity across commercial scanner vendors, open-source repositories, and compliance regulators.
  • Language and Hardware Agnostic: Provides comprehensive coverage across compiled code (C, C++, Rust), managed environments (Java, Python, C#), web architectures, and hardware HDL/RTL designs.
  • Not a Vulnerability Registry: CWE describes weakness types, not specific vulnerable software products; a system cannot be “patched against CWE-89,” but rather against specific software packages exhibiting that weakness.
  • Contextual Nuance: Mapping a complex vulnerability to a single CWE can be challenging when multi-stage exploits chain multiple weaknesses together (addressed via CWE Named Chains and Composites).

Alternatives and Related Security Standards

CWE functions within a broader ecosystem of cybersecurity standards and catalogs, each serving a complementary operational purpose:

Standard / Platform Primary Purpose Governing Body Relationship to CWE
CVE (Common Vulnerabilities and Exposures) Enumerates specific instances of vulnerabilities in deployed products and releases. CISA / MITRE Sister program: CVE names the product instance (e.g., CVE-2021-44228); CWE defines the underlying weakness type (e.g., CWE-20 / CWE-917).
CVSS (Common Vulnerability Scoring System) Quantifies the technical severity and exploitability of a specific vulnerability. FIRST (Forum of Incident Response and Security Teams) Scores CVEs; average CVSS scores are combined with CVE frequency to rank the CWE Top 25.
NVD (National Vulnerability Database) U.S. government repository of standards-based vulnerability management data. NIST (National Institute of Standards and Technology) Downstream consumer of CVE that annotates each vulnerability with associated CWE-IDs and CVSS vectors.
CAPEC (Common Attack Pattern Enumeration) Catalogs common methods and mechanisms attackers use to exploit weaknesses. CISA / MITRE Documents attack mechanisms; CAPEC patterns link directly to the CWE weaknesses they exploit.
OWASP Top 10 Curated awareness list of critical security risks focused primarily on web applications. OWASP Foundation Higher-level, broad application risk categories mapped directly to underlying constituent CWE-IDs.

Frequently Asked Questions

What does CWE stand for and what does it do?

CWE stands for Common Weakness Enumeration. It provides an authoritative, free, and publicly accessible dictionary of software and hardware flaws across architecture, design, and implementation. It enables developers, researchers, and security practitioners to identify root causes, establish secure coding baselines, and eliminate vulnerabilities during development.

What is the difference between CWE, CVE, and CVSS?

The three standards address distinct aspects of cybersecurity defects: CWE defines the type of weakness (e.g., buffer overflow or SQL injection); CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world instance of a flaw in a designated product version; and CVSS (Common Vulnerability Scoring System) provides a standardized numerical score (0.0 to 10.0) reflecting the severity and exploitability of that specific CVE.

What is a CWE vs CVE?

A CWE is a weakness category (the blueprint flaw), while a CVE is an individual, documented vulnerability in a specific piece of software or hardware. For example, CWE-79 is the universal category for “Improper Neutralization of Input During Web Page Generation (Cross-site Scripting),” whereas a specific CVE identifier represents an instance where that cross-site scripting flaw occurred in a particular release of an application.

Where is CWE located?

CWE is not a physical testing laboratory or facility. It is a digital knowledge base and standard hosted online at cwe.mitre.org. The program is sponsored by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) in Washington, D.C., and managed by The MITRE Corporation from its research centers in McLean, Virginia, and Bedford, Massachusetts.

How does CWE support institutional cybersecurity and compliance?

Academic institutions and research facilities use CWE to ensure custom research software, laboratory instrument interfaces, and institutional web applications comply with federal security mandates. Incorporating CWE into code review practices supports broader institutional compliance frameworks, such as CMMC compliance for research institutions, and informs defensive workflows documented in threat intelligence and advanced persistent threat defenses.

Sources

  • MITRE Corporation. (2026). Common Weakness Enumeration (CWE) Official Portal. cwe.mitre.org (Accessed 2026-11-08).
  • MITRE Corporation. (2026). CWE Frequently Asked Questions (FAQ). cwe.mitre.org/about/faq.html (Accessed 2026-11-08).
  • MITRE Corporation. (2026). CWE-1000: Research Concepts View. cwe.mitre.org/data/definitions/1000.html (Accessed 2026-11-08).
  • National Institute of Standards and Technology. (2026). Common Weakness Enumeration – CSRC Glossary. csrc.nist.gov/glossary/term/common_weakness_enumeration (Accessed 2026-11-08).

Follow CASRAI

Research-administration guidance, standards updates and independent tool reviews.

Ask CASRAI · free to try

Ask about CWE: Common Weakness Enumeration Platform Guide

Ask your first 2 questions free below. Subscribers get 150 a day for $29 a month.

An AI assistant specialized in research administration. It cites the sources behind every answer, labels web answers and says when it can't answer.

Answers draw on CASRAI's guides and dictionary plus the federal and funder documents we index: Federal Register, Grants.gov, Regulations.gov and UKRI.

Works on this site and inside Claude, Cursor and the AI tools you already use.

Everything CASRAI publishes — this page, the dictionary, the guides and the news — stays free to read, with no account and no card.

Referenced across the research world

University of Cambridge logoColumbia University logoCrossref logoUniversity of Edinburgh logoHarvard University logoUniversity of Oxford logoPrinceton University logoStanford School of Medicine logoUniversity College London logoORCID logoUniversity of Cambridge logoColumbia University logoCrossref logoUniversity of Edinburgh logoHarvard University logoUniversity of Oxford logoPrinceton University logoStanford School of Medicine logoUniversity College London logoORCID logo
  • University of Cambridge logo
  • Columbia University logo
  • Crossref logo
  • University of Edinburgh logo
  • Harvard University logo
  • University of Oxford logo
  • Princeton University logo
  • Stanford School of Medicine logo
  • University College London logo
  • ORCID logo

View CASRAI adoption →