With version 2.10 of CWE released, we would like to turn our attention to filling gaps in the CWE list and improving the content that is already there. The focus for this year remains on software, so the gaps we are interested in should align with this focus. We have had a number of offers for help in the past, and this is something that could really move CWE forward.
If you know of an area within CWE that is underspecified, or missing altogether, we would love to hear from you. Unfortunately, the reality is that we will be limited in what we can review, edit, and push up to the official list. We ask that submissions meet a certain level of detail, which will help us verify and confirm details in a much shorter period of time. Our expectation is that only a handful of suggested CWEs would be submitted and that we will have the ability to add these to the list and produce a new version in a meaningful amount of time.
If you would like to help, please let us know. Our notional plan is to accept submissions until Feb 28, then spend the month of March (and likely April) creating the new version to include as many of the submissions as we can.
The following is the list of fields that meet our minimum expectations. An explanation of each field is provided at the end of this email.
* Potential Mitigations
* Common Consequences
* Applicable Platforms
* Demonstrative Examples
* Observed Examples
Other fields or information you may provide will be welcome, including but not necessarily limited to:
* Likelihood of Exploit
* Related Attack Patterns
* Alternate Terms
* Time of Introduction
We don't have a submission form at this time, so sending these details in an email to [hidden email] will be our starting position.
We are excited about this opportunity to continue the advancement of CWE, and we look forward to any support that is provided by the community.
Steve and Drew
Name - Ideally, this focuses on the weakness/mistake (not the attack). Minimizes use of ambiguous words to keep the name short.
Description - A summary of 1 or 2 sentences describing the weakness; an additional paragraph may be used to give further detail and cover why the weakness is important. Use of CWE-specific vocabulary is preferred, but not required.
Potential Mitigations - Description of the technique(s) to eliminate and/or reduce the frequency or impact of the weakness.
Common Consequences - The typical negative security impact that occurs if this weakness can be exploited by an attacker.
Applicable Platforms - The set of programming languages, language families, frameworks, architectures, technologies, and/or product classes in which this weakness is usually found.
Demonstrative Examples - One or more brief code snippets that contain the weakness (and, preferably, no other weaknesses), with introductory text summarizing what the programmer is trying to accomplish, with an example of "good code" that avoids the weakness.
Observed Examples - One or more vulnerabilities in public software that contain the weakness, preferably with a CVE identifier when applicable.
Relationships - Parent CWE(s) under which this weakness should be classified. These parents should be Weakness types, not categories. If no clear parent/child relationship is apparent, then identify similar CWEs, and/or include suggestions for how to close the gap.
References - One or more blog posts, white papers, or presentations that describe the weakness, with URLs. Note that references cannot be overtly "commercial" or marketing-oriented in tone.
To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
|Free forum by Nabble||Edit this page|