When organizations or individuals wish to submit new content for CWE, the CWE Program suggests using the official CWE Content Web Submission Form to start the process.
All new content submissions must adhere to the Terms of Use.
The web submission form has five required elements:
- Submitter Contact Information
- Submission Details
- Related Weaknesses
- References
- Review & Submit
After clicking “Submit,” you will receive a confirmation message and your suggestion will be added to the CWE team’s working queue. After internal processing, content suggestions will be added to our GitHub repository for the wider community to track and provide input.
External Submissions Review Process
| Stage | Description
| | Submission | External contributor submits initial content to the web server; the submission is provided to the CWE content team. |
| Review | CWE team reviews the web form submission to determine if it is appropriate for CWE. |
| Consultation | CWE team 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, CWE team will consult with the CWE Researcher List. |
| Decision | CWE team determines what content should be included in CWE. After internal deliberations and communications with the submitter, the CWE team may decide that the suggested content does not fit into CWE’s scope due to several reasons (see common problems below). Alternatively, the CWE team 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 | The submitter is requested to provide further required details to the entry before publication by means of emailing a completed .txt file "CWE Detailed Content Submission Form". |
| Receipt and Review | CWE team receives the additional details and reviews them. The CWE team will reach out to the submitter if any clarification is needed. |
| New Entry Creation | CWE team assigns official IDs and creates a new entry/entries within its internal (non-public) repository converting the submitted content into XML. |
| New Version Publication | CWE team 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, the CWE program releases a new version every 3 or 4 months, although there is not a fixed release schedule.
Common Problems with Integrating Content Suggestions Into CWE
The CWE team has identified the following factors from previous content suggestions that may delay or ultimately affect whether your content suggestion is integrated into CWE.
- Submission is not Weakness-focused. Weaknesses are sometimes more easily understood based on their attacks, or when expressed as a lack of a particular protection mechanism. This is not how CWE entries are defined. 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, or 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.
Additional Supporting Information
The following is intended as supplementary guidance information to help clarify the overall submission process to follow the web form.
Table of Contents
Other Information
| Topic | Explanation |
|---|
| 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 CWE Team. |
| Schema |
XML Schema Definition (XSD) for CWE content. This includes various enumerations that clarify how CWE represents some key information. |
Elements to Include
Following is the minimum list of elements that will ultimately need to be determined for a successful new entry in the CWE corpus.
Guidelines for Individual Elements
Below are additional details about each of the minimally expected elements to include in a submission.
Name
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.
Summary
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.
| Element | Description |
|---|
| 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. |
Potential Mitigations
This element should cover one or more techniques that will eliminate and/or reduce the frequency or impact of the weakness.
| Element | Description |
|---|
| Phase | This element indicates the development life cycle
phase during which a particular mitigation may be applied. As of schema 6.6, 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, Porting, Integration, and Manufacturing. |
| 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 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 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 CWE 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.
| Element | Description |
|---|
| Scope | Identifies the security property (or properties) being violated. Acceptable values include Confidentiality, Integrity, Availability, Access Control, Accountability, Authentication, Authorization, Non-Repudiation, and Other. |
| Impact | Describes the technical impact that arises if an adversary succeeds in exploiting this weakness. |
| 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 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 the CWE team has reviewed and accepted the general concepts behind the submitted entry.
| Element | Description |
|---|
| 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 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 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, the CWE team 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.
| Element | Description |
|---|
| CVE Identifier | Should be provided when available |
| Link | Link to the reference. The link should not require registration. |
| 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 description. |
Relationships
Identify the parent CWE(s) under which this weakness should be classified. Ensure that these parents are Weakness types, not categories. The CWE team 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).
References
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.
| Element | Description |
|---|
| URL | URL at which the reference can be found. |
| 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.
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.
Important Considerations
Ensure that the following analysis has been conducted.
- Information Meets the CWE/CAPEC Terms of Use. Any 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, the CWE team 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, the CWE team 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 the CWE team about this.
| Author | CWE Team |
| Email | cwe@mitre.org |
| Version | 2.0 |
| Last Modified | February 14, 2022 |
