Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

CWE Top 25 Most Dangerous Software Errors
Home > Community >  

CWE Community

Guidelines for New Content Suggestions

When organizations or individuals wish to submit new content for CWE, MITRE suggests using the official CWE Content Submission Form. All new content submissions must adhere to the Terms of Use.

Content Submission Template – TXT

The rest of this page contains supporting guidelines to supplement and clarify content on the submission form.

Table of Contents

High-Level Process

MITRE uses the following process for handling externally submitted content. Note that these stages might not follow this exact order.

ReceiptMITRE receives the suggested content.
ReviewMITRE reviews the suggested content to determine if it is appropriate for CWE.
ConsultationMITRE works with the submitter to come to a shared agreement about how the suggested weakness will be managed. When the submission is complex or is deemed to require public review or discussion, MITRE will consult with the CWE Researcher List.
Inclusion DecisionMITRE determines what content should be included in CWE. MITRE may decide to (1) create a new entry, (2) integrate the submitted information into an existing entry, and/or (3) create additional supporting entries that facilitate use of CWE's major views (Development, Researcher, and Architecture).
Supporting AnalysisMITRE, the submitter, and/or other parties conduct supporting analysis that further describes the issue, e.g. by providing additional elements.
New Entry CreationMITRE assigns official IDs and creates a new entry/entries within its internal (non-public) repository.
Conversion to XMLMITRE converts the submitted content into XML and integrates the content into its internal repository.
New Version PublicationMITRE creates an official version of CWE and publishes it. This includes the new content and, if necessary, new versions of the schema and/or supporting documentation.

Currently, MITRE releases a new version every 3 or 4 months, although there is not a fixed release schedule.

Supporting Documents

Glossary A glossary of commonly used terms within CWE. CWE tries to use a restricted vocabulary to minimize inconsistency.
Vulnerability Theory This document includes some of the core concepts underlying how CWE classifies and represents weaknesses. These concepts directly influence how weaknesses are described by the MITRE CWE Team.
Schema XML Schema Definition (XSD) for CWE content. This includes various enumerations that clarify how CWE represents some key information.

Required Analysis Before Submitting New Content

Ensure that the following analysis has been conducted.

  • Information is Public. The submitted information, if included within CWE, will become public information. Ensure that the information has been approved for public release by the appropriate authority.
  • Conformance to Guidelines. It is your option regarding how closely you want to conform with these guidelines. However, submissions that do not follow these guidelines may take longer to integrate into CWE, or they may be modified heavily. Generally, MITRE may choose to deprioritize non-conformant submissions.
  • Abstraction. Consider whether the submission is at an appropriate level of abstraction that is represented within CWE. Guidelines are not well-defined as of this time, but be familiar with Classes, Bases, and Variants (from the schema or glossary, and from reviewing existing CWE content). Generally, MITRE prefers submissions at the Base level; however, you might only be aware of a weakness at a lower Variant level.
  • Scope. Ensure that the submission is within the scope of CWE. When uncertain, you can consult with MITRE about this.

Submission Format

You are not expected to provide content in the XML format as provided by MITRE. It is more important to focus on the contents of the submission, and the contents might change significantly in several iterations. In the early stages, it is easier to exchange information in easily-readable text. Finally, it can take some time to learn CWE's XML format, and this may be too labor-intensive.

MITRE strongly prefers using a format that:

  • explicitly labels the elements being provided
  • can be copied and pasted

Simple ASCII text or formats such as RTF or Microsoft Word are acceptable. Spreadsheets are discouraged, since some elements may be very long (such as extended descriptions) or have a complicated format that is not easily viewable from a spreadsheet application (such as demonstrative examples with code snippets).

Elements to Include

Following is a list of elements or attributes that meet our minimum expectations for content submissions.

Additional Elements

Other fields or information you may provide will be welcome, including but not necessarily limited to:

  • Likelihood of Exploit
  • Related Attack Patterns
  • Alternate Terms

Guidelines for Individual Elements

Below are additional details about each of the minimally expected elements to include in a submission.


Ideally, the name focuses on the weakness/mistake - not the attack. Minimize use of ambiguous words to keep the name short. Where feasible, use terminology as defined in the CWE glossary and/or vulnerability theory documents. The name should include: (1) the intended behavior of the code, (2) the mistake (i.e. weakness), (3) the affected resource (if relevant), and (4) the affected technology (if relevant).

Use of CWE-specific vocabulary is preferred but not required.


The summary consists of only one or two sentences that describe the weakness itself, i.e. the mistake that is made. Often, the summary will describe what the developer/designer is attempting to do. Critical parts of the summary include: (1) the intended behavior of the code, (2) the mistake (i.e. weakness), (3) the affected resource (if relevant), and (4) the affected technology (if relevant). Each summary part is only expressed with individual words or brief phrases; the extended description can be more comprehensive in its explanation.

Use of CWE-specific vocabulary is preferred but not required.

The summary (and name) should avoid focusing on: (1) the attack, (2) the absence of a mitigation, or (3) the technical impact. If a summary has a strong reliance on this information, this may be an indicator that the entry is not weakness-focused.

Extended Description

The extended description provides additional explanation for the weakness. Generally, the intended audience is a developer/designer who might not immediately understand how the weakness can be a problem, or who may have an overly simplistic understanding of the problem.

Use of CWE-specific vocabulary is preferred but not required.

The extended description may consist of multiple paragraphs, but typically it is only one or two paragraphs long.

The extended description:

  • Explains why the weakness should be a concern to the developer/designer.
  • Briefly summarizes the technical impact that could result.
  • Gives subtleties or variations that are necessary to have a broader understanding of the issue.

Modes of Introduction

This provides information about how and when a given weakness may be introduced. Multiple introduction points can be provided if they exist.

PhaseIndicates the point (or points) in the development life cycle during which the weakness may be introduced. The Phase can cover one or more of: Policy, Requirements, Architecture and Design, Implementation, Build and Compilation, Testing, Documentation, Bundling, Distribution, Installation, System Configuration, Operation, Patching and Maintenance, and Porting.
Note(Optional) The typical scenario(s) under which the weakness may be introduced during the given phase.

Potential Mitigations

This element should cover one or more techniques that will eliminate and/or reduce the frequency or impact of the weakness.

PhaseThis element indicates the development life cycle phase during which a particular mitigation may be applied. As of schema 6.1, the Phase can cover one or more of: Policy, Requirements, Architecture and Design, Implementation, Build and Compilation, Testing, Documentation, Bundling, Distribution, Installation, System Configuration, Operation, Patching and Maintenance, and Porting.
DescriptionA freeform description of the mitigation. Where feasible, the mitigation should be written as generally as possible to account for variations in different languages, frameworks, technologies, etc. At the same time, however, it should be as specific to the weakness as possible. Vague or generic phrases such as "validate inputs," "use defense in depth," or "use a secure algorithm" are discouraged.
EffectivenessHow effective the mitigation may be in preventing the weakness.
  • High - frequently successful in eliminating the weakness entirely.
  • Moderate - will prevent the weakness in multiple forms, but it does not have complete coverage of the weakness.
  • Limited - may be useful in limited circumstances, or it is only applicable to a subset of potential errors of this weakness type.
  • Incidental - generally not effective and will only provide protection by chance, rather than in a reliable manner.
  • Defense in Depth - may not necessarily prevent the weakness, but it may help to minimize the potential impact of an attacker exploiting the weakness.
Effectiveness NotesIf useful, a freeform text description of the effectiveness of the mitigation.

Note that the CWE schema also includes a Strategy element, but that will be filled in by the MITRE team. It is based on a CWE-developed classification of mitigation strategies. For more information, see MitigationStrategyEnumeration in the XSD.

Common Consequences

This element will cover the typical negative security impact (or impacts) that occurs if this weakness can be exploited by an attacker.

ScopeIdentifies the security property (or properties) being violated. Acceptable values include Confidentiality, Integrity, Availability, Access Control, Accountability, Authentication, Authorization, Non-Repudiation, and Other.
ImpactDescribes the technical impact that arises if an adversary succeeds in exploiting this weakness.
LikelihoodIdentifies how likely the specific consequence is expected to be seen relative to other specified consequences. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact. Acceptable values are High, Medium, Low, and Unknown. Note that these values are not formally defined.
Note(Optional) Provides additional commentary about a consequence.

Applicable Platforms

This element specifies the programming languages (or language families), operating systems, frameworks, architectures, technologies, and/or product classes in which this weakness is usually found.

While this element is well-defined within the CWE schema, it might be unnecessarily limited for external submissions. See the ApplicablePlatformsType and related enumerations for examples.

Demonstrative Examples

The entry should have one or more demonstrative examples. A useful example contains several different elements, as outlined below.

WARNING: Submitters should not necessarily put significant effort into creating these examples until MITRE has reviewed and accepted the general concepts behind the submitted entry.

Introductory TextDescribes what the code is attempting to do, possibly providing the context or setting in which the code should be viewed.
"Bad" Code SnippetsProvide one or more code snippets (or algorithm descriptions) that contain the weakness. The primary audience is assumed to be a programmer who is knowledgeable about the language being used.
  • The code should have the correct syntax.
  • The snippets should only focus on the least amount of code for the reader to understand what the code is attempting to do; so, for example, statements that load common libraries can be omitted.
  • The snippets should not try to obscure the associated weakness, as these examples are meant to be easy for the reader to understand.
  • Where feasible, the snippets should only have one weakness, unless the example is intentionally demonstrating a chain or composite.
Explanatory TextWhere reasonable, explanatory text should indicate where the mistake occurs, including what assumptions the programmer may have made along the way. This can include some examples for how the attack could be launched.
"Good" Code SnippetsShow or explain how the "bad" code snippet could be modified to eliminate the weakness.

Note that these details do not closely follow the internal format as used by CWE. If the submitted content is accepted, MITRE will perform the appropriate conversions into XML. For more information, see the DemonstrativeExamplesType in the schema definition.

Observed Examples

Where known, the submission should identify multiple publicly-reported vulnerabilities in real-world software that exhibit the weakness.

CVE IdentifierShould be provided when available
LinkLink to the reference. The link should not require registration.
SummaryA short sentence or phrase summarizing the weakness. The summary does not necessarily have to name the affected product or service, rather, cover the mistake that leads to the weakness, and possibly the technical impact. Preferably, the summary should not give the actual vendor or product name, nor should it be a verbatim copy of the associated CVE description.


Identify the parent CWE(s) under which this weakness should be classified. Ensure that these parents are Weakness types, not categories. MITRE will perform additional analysis to ensure that the appropriate relationships exist.

If no clear parent/child relationship can be identified, then identify similar CWEs, and/or include suggestions for how to close the gap.

When suggesting relationships, try to consider where they fall under the hierarchy-oriented Development View (CWE-699), the Research View (CWE-1000), and/or the Hardware Design View (CWE–1194 -- Coming soon in Version 4.0).


References can include one or more academic papers, white papers, blog posts, slide presentations, or videos that describe the weakness, with URLs.

  • In general, the reference should be freely available on the web, without requiring registration.
  • Where feasible, the original announcement of the weakness should be included as a reference.
  • References should not be overtly "commercial" or marketing-oriented in tone.
  • Where feasible, URLs that are unlikely to change should be preferred.

URLURL at which the reference can be found.
TitleTitle of the paper, book, etc.
Author(s)Author(s) of the reference.

Examples of Mature CWE Entries

The following CWE entries are mature and well-reviewed. As such, they provide good examples to consult as you compose your own submissions.

CWE-89SQL Injection
CWE-79Cross-Site Scripting

Common Problems Affecting Integration Into CWE

After your submission has been sent, the following factors may cause delays in integrating your data into CWE.

  • Submission is not Weakness-focused. Sometimes, weaknesses are more easily understood based on their attacks, or when expressed as a lack of a particular protection mechanism. It may require additional effort to conduct the root-cause analysis to identify the underlying weakness.
  • Submission requires additional reorganization within CWE. While weaknesses related to numeric calculation, buffer overflows, injection, etc. have been researched extensively and have a stable organizational scheme within CWE, other portions of CWE are less mature. Submissions related to these parts of CWE might require broader reorganization of associated relationships across multiple views, possibly forcing the creation or deprecation of multiple entries, not just the original submission.
  • Submission requires additional research to include. This is especially the case with newly-discovered weaknesses. In some cases, if original research is needed, it may be too resource-intensive to conduct the original research to address the submission quickly. This is especially the case when highly specialized knowledge is required to understand the issue.
  • Not all requested information is provided.
  • Descriptions are not clearly written.
  • Submission elements are missing or do not follow guidelines.

Change Management

Content suggestions from the community that adhere to the Terms of Use are encouraged and welcomed. Once your suggestion form has been submitted, the CWE team will review it and determine whether to ingest it into the corpus. If selected, the CWE team will work with you to make sure it fits both your needs and aligns with the rest of CWE in terms of language, structure, etc. If the CWE team is considering a significant change to a submitter’s entry after its publication, the team will attempt to contact the original submitter to discuss those change requests / modifications before they are released. Modifications that would alter the underlying meaning of the CWE would result in deprecation (and the subsequent creation of a new CWE) enabling the long-term viability of the original CWE.

AuthorMITRE CWE Team
Last ModifiedApril 28, 2020
More information is available — Please select a different filter.
Page Last Updated: April 28, 2020