CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > News  
ID

News & Events

Right-click and copy a URL to share an article. Send feedback about this page to cwe@mitre.org.

2019 Update of the "CWE Top 25" Now Underway

August 7, 2019 | Share this article

The CWE Team is currently working towards the generation and publication of a new 2019 release of the "CWE Top 25 Most Dangerous Software Errors."

After this initial announcement, our next step will be to release a draft in the coming weeks for community review and comment. Once those comments are reviewed and incorporated, we will officially publish the new Top 25 for the community.

A New Approach for the Top 25

In previous releases, the Top 25 list was constructed through aggregating survey responses from a wide selection of organizations, and by engaging developers, security analysts, researchers, and vendors. Respondents were asked to nominate weaknesses that they considered to be the most prevalent or important, and then a customized part of the Common Weakness Scoring System (CWSS™) was used to determine a ranking. There were a number of positives in this approach, but it was also labor-intensive and subjective.

For the upcoming Top 25, we are using a more rigorous and statistical process leveraging information about actual reported vulnerabilities to determine the prevalence and dangerousness of the given weakness. The CWE Team will use weakness data pulled directly from the U.S. National Vulnerability Database (NVD) to calculate metrics for CWEs. While this method introduces a bias through analyzing only reported vulnerabilities and could potentially exclude some software and a breadth of other data, the CWE Team believes it will result in a more repeatable and accurate Top 25 list.

Scoring for the New Top 25

There are two components in our scoring process that will be combined to determine the total score for a CWE. The first component is the frequency that a CWE is the root cause of a vulnerability. The second component is a weakness' average Common Vulnerability Scoring System (CVSS) score, which is meant to determine the overall severity of a weakness. We determine the average CVSS score for a CWE by calculating the sum of all of the CVSS scores for Common Vulnerabilities and Exposures (CVE®) Entries that map to a given CWE, and then dividing this sum by the total number of CVE Entries with that CWE. These two components are normalized before being multiplied together.

This process is represented below:


W = All CWEs
CVE_w = All CVEs with a weakness w
Freq = {count(CVE_w') for each w' in W}
Freq_w = Number of CVE Entries with a weakness w
CVSS = All CVSS Scores
CVSS_w = All CVSS Scores for w
F_w = (Freq_w - min(Freq)) / (max(Freq) - min(Freq))
C_w = (average(CVSS_w) - min(CVSS)) / (max(CVSS) - min(CVSS))

Final score = F_w * C_w


The CWE Team is still reviewing this formula, and it may change before the new Top 25 List is published.

Mapping to CVE Entries

One of the challenges that we are faced with is addressing the many CVE Entries currently mapped to CWE Categories. Categories are not technically weaknesses and therefore any existing mapping to them is considered incorrect. As such, we have coordinated with NVD and are in the process of finalizing a "mapping analysis" on these CVE Entries to map them to more accurate CWEs at lower levels of abstraction.

Relatedly, on June 20, 2019 we published our most recent minor version release, CWE Version 3.3, in which we include a new CWE View: "CWE View 1003: Weaknesses for Simplified Mapping of Published Vulnerabilities." Going forward, newly reported vulnerabilities will be mapped to the entries in View 1003 where possible. If over time vulnerability data indicates that certain weaknesses not currently part of View 1003 are occurring more frequently in the wild, View 1003 will evolve as needed to accommodate these new trends.

CWE Top 25 Draft Coming Soon

This is a large undertaking, but we hope that it will result in a repeatable and more accurate Top 25 list, as well as drive discussions about better ways to approach CVE<->CWE mapping in the future.

As stated above, our next step will be to release a draft in the coming weeks for community review and comment and once those comments are reviewed and incorporated, we will officially publish the new Top 25 for the community.

Please send any initial feedback to us on the CWE Research email discussion list, @cwecapec on Twitter, CWE page on LinkedIn, or directly to cwe@mitre.org.

CWE Launches "@cwecapec" Twitter Feed

August 7, 2019 | Share this article

Please follow our new Twitter account at https://twitter.com/cwecapec to get the latest CWE news and announcements.

CWE Version 3.3 Now Available

June 20, 2019 | Share this article

CWE Version 3.3 has been posted on the CWE List page. A detailed report is available that lists specific changes between Version 3.2 and Version 3.3.

Main Changes:

CWE 3.3 has 1 new view, 1 updated view with 2 new entries, and 2 deprecated entries. In all, 238 entries had major changes to relationship, references, names, fields, and descriptions.

The main changes include: (1) adding 1 new view, CWE-1178: Weaknesses Addressed by the SEI CERT Perl Coding Standard, which identifies weaknesses in Perl that may be fully or partially prevented by following the SEI CERT Perl Coding Standard; (2) adding 8 new categories related to CWE-1178; (2) updating the CWE-1003: Weaknesses for Simplified Mapping of Published Vulnerabilities view, which may be used to categorize potential weaknesses within sources that handle public, third-party vulnerability information, such as the U.S. National Vulnerability Database (NVD); and adding 2 new weaknesses related to CWE-1003, CWE-1187: Use of Uninitialized Resource, which occurs when a resource has not been properly initialized and the software may behave unexpectedly, and CWE-1188: Insecure Default Initialization of Resource, which occurs when the software initializes or sets a resource with a default that is intended to be changed by the administrator, but the default is not secure.

There were no schema changes.

Summary:

There are now 808 weaknesses and a total of 1188 entries on the CWE List.

Changes for the new version include the following:

  • New Entries Added:
11
  • Entries Deprecated:
2
  • Entries with Major Changes:
238
  • Entries with only Minor Changes:
0
  • Entries Unchanged:
937

See the complete list of changes at https://cwe.mitre.org/data/reports/diff_reports/v3.2_v3.3.html.

Future updates will be noted here and on the CWE Research email discussion list. Please send any comments or concerns to cwe@mitre.org.

CWE Is Main Topic of Article on Military Embedded Systems

June 20, 2019 | Share this article

CWE is the main topic of a March 2019 article entitled "Common Weakness Enumeration (CWE) defines cybersecurity vulnerability landscape for mission-critical applications" on Military Embedded Systems. In the article, the author describes the purpose and possible uses of CWE and CWE-Compatible products, its connection to Common Vulnerabilities and Exposures (CVE®), and discusses examples from the CWE List.

The author states: "The Common Weakness Enumeration (CWE, at http://cwe.mitre.org) has emerged as a de facto reference resource to every security-conscious developer of mission-critical embedded systems." "[CWE] has made an important contribution to the overall process of developing more secure and robust software-intensive systems. It provides a common vocabulary that helps internal communications within software development organizations, as well as allowing users to understand and compare the capabilities of tools designed for scanning and analyzing the source code for mission-critical software. Designers will find that including CWE-compatible features into static-analysis and formal method toolsets enables users to readily understand the kinds of security and robustness issues that can be eliminated."

CWE Version 3.2 Now Available

January 03, 2019 | Share this article

CWE Version 3.2 has been posted on the CWE List page. A detailed report is available that lists specific changes between Version 3.1 and Version 3.2.

Main Changes

CWE 3.2 has 137 new entries and 1 deprecated entry. In all, 534 entries had important changes, primarily due to relationship changes, references, names, and descriptions.

The main changes include: (1) adding 89 new entries related to quality issues that only indirectly make it easier to introduce a vulnerability and/or make the vulnerability more difficult to detect or mitigate (see the CWE-1040: Quality Weaknesses with Indirect Security Impacts view); (2) adding 1 new weakness, CWE-1173: Improper Use of Validation Framework, detailing the improper use of an available input validation framework; (3) adding 1 new view, CWE-1128: CISQ Quality Measures (2016), to map to the Consortium for IT Software Quality (CISQ) Automated Quality Characteristic Measures released in 2016; and (4) updating the views and categories associated with the Software Engineering Institute (SEI) Computer Emergency Response Team (CERT) Coding Standards.

The CWE Schema was updated to v6.1.

Summary:

There are now 806 weaknesses and a total of 1177 entries on the CWE List.

Changes for the new version include the following:

  • New Entries Added:
137
  • Entries Deprecated:
1
  • Entries with Important Changes:
230
  • Entries with Major Changes:
304
  • Entries with only Minor Changes:
2
  • Entries Unchanged:
733

See the complete list of changes at https://cwe.mitre.org/data/reports/diff_reports/v3.1_v3.2.html.

Future updates will be noted here and on the CWE Researcher email discussion list. Please send any comments or concerns to cwe@mitre.org.

5 Products from 3 Organizations Now Registered as Officially "CWE-Compatible"

June 14, 2018 | Share this article

CWE Compatible

Five additional cyber security products from three organizations have achieved the final stage of the formal CWE Compatibility Program and are now officially "CWE-Compatible." The products are now eligible to use the CWE-Compatible Product/Service logo, and a completed and reviewed "CWE Compatibility Requirements Evaluation" questionnaire is posted for the product as part of the organization's listing on the CWE-Compatible Products and Services page on the CWE website. A total of 53 products to-date have been recognized as officially compatible.

The following 5 products are now registered as officially "CWE-Compatible":

Use of the official CWE-Compatible logo will allow system administrators and other security professionals to look for the logo when adopting SwA products and services for their enterprises and the compatibility process questionnaire will help end-users compare how different products and services satisfy the CWE compatibility requirements, and therefore which specific implementations are best for their networks and systems.

For additional information about CWE compatibility and to review all products and services listed, visit CWE Compatibility Program and CWE-Compatible Products and Services.

CWE Version 3.1 Now Available

March 29, 2018 | Share this article

CWE Version 3.1 has been posted on the CWE List page. A detailed report is available that lists specific changes between Version 3.0 and Version 3.1.

Main Changes

CWE 3.1 has 17 new entries and 4 deprecated entries. In all, 145 entries had important changes, primarily due to relationship changes, references, names, and descriptions.

The main changes include: (1) adding a new view for the 2017 OWASP Top Ten; (2) adding new entries related to processor optimization and Meltdown/Spectre (CWE-1037: Processor Optimization Removal or Modification of Security-critical Code, CWE-1038: Insecure Automated Optimizations), adversarial inputs in machine learning (CWE-1039: Automated Recognition Mechanism with Inadequate Detection or Handling of Adversarial Input Perturbations); and comparison (CWE-1023: Incomplete Comparison with Missing Factors, CWE-1024: Comparison of Incompatible Types, CWE-1025: Comparison Using Wrong Factors); (3) including various modifications as suggested by community members; and (4) better consistency in frequently-used references.

The CWE Schema was updated to v6.0.1.

Summary:

There are now 716 weaknesses and a total of 1040 entries on the CWE List.

Changes for the new version include the following:

  • New Entries Added:
17
  • Entries Deprecated:
4
  • Entries with Important Changes:
94
  • Entries with Major Changes:
145
  • Entries with Minor Changes:
96
  • Entries Unchanged:
800

See the complete list of changes at https://cwe.mitre.org/data/reports/diff_reports/v3.0_v3.1.html.

Future updates will be noted here and on the CWE Research email discussion list. Please send any comments or concerns to cwe@mitre.org.

How “Meltdown” and “Spectre” Can Be Defined by CWE and CAPEC

January 31, 2018 | Share this article

There has been a lot of press (rightly so) regarding the “Meltdown”- and “Spectre”-style attacks. The CWE and CAPEC teams have been reviewing the available information and trying to determine if new weaknesses or attack patterns should be added. Below are our current thoughts. We welcome additional discussion.

Common Weakness Enumeration (CWE™)

Both Meltdown and Spectre are technically attacks. They take advantage of a processor executing instructions out of order, in a way that causes some instructions to be executed even though the logic of the original code would not execute these instructions. This condition leads to a case where data in memory is cached before a permission check is performed. The end result is the ability to perform side-channel style attacks against the cache to learn the exact value of data.

The root cause of both of these attacks is the out of order execution. The processor uses this feature to increase the speed at which a program can be executed. This is very similar to compiler optimizations where a compiler makes changes to the source code to improve performance. In both instances, the computer is no longer executing exactly what the developer told it to execute, but rather is executing a variation that the processor/compiler thinks is “better.”

Unfortunately, these optimizations can sometimes lead to an exploitable weakness. There already exists a base-level CWE for the compiler version of this:

CWE-733: Compiler Optimization Removal or Modification of Security-critical Code

A new base-level CWE should be added to cover the case where the processor changes the order of security-critical code.

In addition, a new class-level CWE should also be considered around the topic of “Insecure Optimizations.” This class-level CWE would be a member of the Behavioral Problems category in the Development Concepts view, and a child of Interaction Error in the Researcher view. Both the existing compiler optimization (CWE-733) weakness and the new processor execution order weakness would be children of this new class.

CWE CATEGORY: Behavioral Problems

CWE-435: Improper Interaction Between Multiple Entities

Finally, there should be a CanFollow relationship between the existing class CWE-696: Incorrect Behavior Order and this new class “Insecure Optimizations”. We see this relationship in Meltdown/Spectre with the optimizations resulting in a change in the order of execution.

One last note, many discussions of Meltdown and Spectre focus on the side channel attack that arises from timing discrepancies. In this case, the timing discrepancy is not a weakness as it is legitimate behavior (since caching improves efficiency) and is not introduced by choices made by the application developer. Therefore, this is not a focus from the CWE classification perspective; the ability to see this (legitimate) timing discrepancy arises from the insecure optimization.

Common Attack Pattern Enumeration and Classification (CAPEC™)

Shifting to the attack pattern side of things, both the compiler and processor weaknesses are not currently well represented in CAPEC.

The compiler weakness (CWE-733) is not directly attacked, but rather results in a different weakness (e.g., buffer overflow) being present in the software, and that weakness is the one that is used in an attack. CWE thinks of this as a chain. The processor weakness can be thought of in the same way. Even though an adversary can manipulate when/how a processor decides to execute out of order, it is the resulting exposure of data that contributes to the vulnerability. See CWE-668: Exposure of Resource to Wrong Sphere.

For both the Meltdown and Spectre attacks, CAPEC already has a relevant standard-level attack pattern that can be leveraged:

CAPEC-141: Cache Poisoning

This attack pattern has a detailed-level child that covers the DNS version of cache poisoning. Meltdown and Spectre expose a different type of cache poisoning where the adversary doesn't insert malicious data into the cache, but rather cause the cache to contain data that shouldn’t be allowed. CAPEC-141 needs to be cleaned up a bit, but the overall idea behind it is valid. A new detailed-level pattern should be added to cover the Flush+Reload attack pattern (and potentially others) that are leveraged by the Meltdown and Spectre attacks.

What do you think?

Please let us know your thoughts on the above by sending an email message to the CWE Research community discussion list, or directly to cwe@mitre.org.

We look forward to hearing from you!

More information is available — Please select a different filter.
Page Last Updated: August 07, 2019