Guidelines for New Content Submissions
When organizations or individuals wish to submit new content for CWE, MITRE suggests using the official CWE Content Submission Form.
CWE Content Submission Form – TXT
The rest of this page contains supporting guidelines to supplement and clarify content on the submission form.
Table of Contents
MITRE uses the following process for handling externally submitted content. Note that these stages might not follow this exact order.
|Receipt||MITRE receives the submitted content.
|Review||MITRE reviews the submitted content to determine if it is appropriate for CWE.
|Consultation||MITRE works with the submitter to come to a shared agreement about how the submitted 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 Decision||MITRE 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 Analysis||MITRE, the submitter, and/or other parties conduct supporting analysis that further describes the issue, e.g. by providing additional elements.
|New Entry Creation||MITRE assigns official IDs and creates a new entry/entries within its internal (non-public) repository.
|Conversion to XML||MITRE converts the submitted content into XML and integrates the content into its internal repository.
|New Version Publication||MITRE 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.
||A glossary of commonly used terms within CWE. CWE tries to use a restricted vocabulary to minimize inconsistency.
||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.
||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 not Copyrighted. The submitted information should be original content, or otherwise uses material that does not have copyright protection. Plagiarized content is prohibited; heavily quoted content (with proper citations) is not preferred but is acceptable.
- 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.
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.
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
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.
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
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
|Phase||Indicates 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.|
This element should cover one or more techniques that will eliminate
and/or reduce the frequency or impact of the weakness.
|Phase||This 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,
|Description||A 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.|
|Effectiveness||How effective the mitigation may be in
preventing the weakness.
- High - frequently successful in eliminating the weakness
- 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
- Incidental - generally not effective and will only
provide protection by chance, rather than in a reliable
- 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 Notes||If 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.
This element will cover the typical negative security impact (or
impacts) that occurs if this weakness can be exploited by an attacker.
|Scope||Identifies the security property (or properties)
being violated. Acceptable values include Confidentiality,
Integrity, Availability, Access Control,
Accountability, Authentication, Authorization, Non-Repudiation,
|Impact||Describes the technical impact
that arises if an adversary succeeds in exploiting this
|Likelihood||Identifies 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
|Note||(Optional) Provides additional commentary about a
This element specifies the programming languages (or language
families), operating systems, frameworks, architectures,
technologies, and/or product classes in which this weakness is
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.
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 Text||Describes what the code is
attempting to do, possibly providing the context or setting in
which the code should be viewed.|
|"Bad" Code Snippets||Provide 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
- The snippets should not try to obscure the associated
weakness, as these examples are meant to be easy for the reader to
- Where feasible, the snippets should only have one weakness,
unless the example is intentionally demonstrating a chain or
|Explanatory Text||Where 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 Snippets||Show 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.
Where known, the submission should identify multiple
publicly-reported vulnerabilities in real-world software that
exhibit the weakness.
|CVE Identifier||Should be provided when
|Link||Link to the reference. The link should not
|Summary||A 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
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
- 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.
|URL||URL at which the reference can be
|Title||Title 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.
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
- 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
|Author||MITRE CWE Team|
|Last Modified||January 9, 2020|