2020 CWE Top 25 Most Dangerous Software WeaknessesNOTICE: This is a previous version of the Top 25. For the most recent version go here. Introduction The 2020 Common Weakness Enumeration (CWE™) Top 25 Most Dangerous Software Weaknesses (CWE Top 25) is a demonstrative list of the most common and impactful issues experienced over the previous two calendar years. These weaknesses are dangerous because they are often easy to find, exploit, and can allow adversaries to completely take over a system, steal data, or prevent an application from working. The CWE Top 25 is a valuable community resource that can help developers, testers, and users — as well as project managers, security researchers, and educators — provide insight into the most severe and current security weaknesses. To create the 2020 list, the CWE Team leveraged Common Vulnerabilities and Exposures (CVE®) data found within the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD), as well as the Common Vulnerability Scoring System (CVSS) scores associated with each CVE. A formula was applied to the data to score each weakness based on prevalence and severity. The CWE Top 25 Below is a brief listing of the weaknesses in the 2020 CWE Top 25, including the overall score of each.
Analysis and Comment The major difference between the 2019 and 2020 CWE Top 25 lists is the increased transition to more specific weaknesses as opposed to abstract class-level weaknesses. While these class-level weaknesses still exist in the list, they have moved down in the ranking. This movement is expected to continue in future years as the community improves its mapping to more specific weaknesses. Looking at the list, class-level weaknesses CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer), CWE-20 (Improper Input Validation), and CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) each move down a couple of spots; while more specific weaknesses like CWE-79 (Improper Neutralization of Input During Web Page Generation), CWE-787 (Out-of-bounds Write) and CWE-125 (Out-of-bounds Read) moved up to take their place. This change, and subsequent future movement, will greatly benefit users that are attempting to understand the actual issues that threaten today’s systems. The biggest movement up the list involves four weaknesses that are related to Authentication and Authorization:
All four of these weaknesses represent some of the most difficult areas to analyze a system on. A theory about this movement is that the community has improved its education, tooling, and analysis capabilities related to some of the more implementation specific weaknesses identified in previous editions of the CWE Top 25 and have reduced the occurrence of those, thus lowering their ranking, and in turn raising the ranking of these more difficult weaknesses. Four of the biggest movers down are:
Another big movement is again the result of mapping to a more specific weakness. In 2019, CWE-772 (Missing Release of Resource after Effective Lifetime) was #21. However, this didn’t tell the entire story as which type of resource not being released is important. For 2020, a more specific mapping was used to show the exact type of resource. Due to this change, CWE-401 (Missing Release of Memory after Effective Lifetime) went from not being on the list to being #32, and CWE-772 representing all non-memory resources dropped to #75. This change creates a more accurate CWE Top 25 and identifies the actual issue more precisely. Also of note is the addition of CWE-77 (Improper Neutralization of Special Elements used in a Command) to the On the Cusp list at #31. “Command Injection” is a term that is used inconsistently in vulnerability descriptions, often at the expense of the more accurate “OS Command Injection,” or used to describe the resulting consequence and not the root weakness. This is an area of research for the CWE Team and one that will hopefully be improved in future releases of the CWE Top 25. Methodology The 2020 CWE Top 25 was developed by obtaining published vulnerability data from the NVD. The NVD obtains vulnerability data from CVE and then supplements it with additional analysis and information including a mapping to one or more weaknesses, and a CVSS score, which is a numerical score representing the potential severity of a vulnerability based upon a standardized set of characteristics about the vulnerability. NVD provides this information in a digestible format that helps drive the data-driven approach in creating the 2020 CWE Top 25. This approach provides an objective look at what vulnerabilities are currently seen in the real world, creates a foundation of analytical rigor built on publicly reported vulnerabilities instead of subjective surveys and opinions, and makes the process easily repeatable. The 2020 CWE Top 25 leverages NVD data from the years 2018 and 2019, which consists of approximately 27,000 CVEs that are associated with a weakness. A scoring formula is used to calculate a ranked order of weaknesses which combines the frequency that a CWE is the root cause of a vulnerability with the projected severity of its exploitation. In both cases, the frequency and severity are normalized relative to the minimum and maximum values seen. To determine a CWE’s frequency, the scoring formula calculates the number of times a CWE is mapped to a CVE within the NVD. Only those CVEs that have an associated weakness are used in this calculation, since using the entire set of CVEs within the NVD would result in very low frequency rates and very little difference amongst the different weakness types. Freq = {count(CWE_X’ ∈ NVD) for each CWE_X’ in NVD} Fr(CWE_X) = (count(CWE_X ∈ NVD) - min(Freq)) / (max(Freq) - min(Freq)) The other component in the scoring formula is a weakness’ severity, which is represented by the average CVSS score of all CVEs that map to the particular CWE. The equation below is used to calculate this value. Sv(CWE_X) = (average_CVSS_for_CWE_X - min(CVSS)) / (max(CVSS) - min(CVSS)) The level of danger presented by a particular CWE is then determined by multiplying the severity score by the frequency score. Score(CWE_X) = Fr(CWE_X) * Sv(CWE_X) * 100 There are a few properties of the methodology that merit further explanation.
The CWE Top 25 with Scoring Metrics The following table shows the 2020 CWE Top 25 with relevant scoring information, including the number of entries related to a particular CWE within the NVD data set, and the average CVSS score for each weakness.
Weaknesses On the Cusp Continuing on the theme from last year, the CWE team feels it is important to share these fifteen additional weaknesses that scored just outside of the final Top 25. Per the scoring formula, these weaknesses were potentially not severe enough, or not prevalent enough, to be included in the 2020 CWE Top 25. Individuals that perform mitigation and risk decision-making using the 2020 CWE Top 25 may want to consider including these additional weaknesses in their analyses:
Limitations of the Methodology There are several limitations to the data-driven approach used in creating the CWE Top 25. Data BiasFirst, the approach only uses data that was publicly reported and captured in the NVD, and numerous vulnerabilities exist that do not have CVE IDs. Vulnerabilities that are not included in the NVD are therefore excluded from this approach. For example, CVE/NVD typically does not cover vulnerabilities found and fixed before any system has been publicly released, in online services, or in bespoke software that is internal to a single organization. Weaknesses that lead to these types of vulnerabilities may be under-represented in the 2020 CWE Top 25. Second, even for vulnerabilities that receive a CVE, often there is not enough information to make an accurate (or precise) identification of the appropriate CWE being exploited. Many CVE entries are published by vendors who only describe the impact of the vulnerability without providing details of the vulnerability itself. For example, over 3,200 CVEs from 2018 and 2019 did not have sufficient information to determine the underlying weakness. In other cases, the CVE description covers how the vulnerability is attacked – but this does not always indicate what the associated weakness is. For example, if a long input to a program causes a crash, the cause of the crash could be due to a buffer overflow, a reachable assertion, excessive memory allocation, an unhandled exception, etc. These all correspond to different, individual CWEs. In other CVE entries, only generic terms are used such as “malicious input,” which gives no indication of the associated weakness. For some entries, there may be useful information available in the references, but it is difficult to analyze. For example, a researcher might use a fuzzing program that generates a useful test case that causes a crash, but the developer simply fixes the crash without classifying and reporting what the underlying mistake was. Third, there is inherent bias in the CVE/NVD dataset due to the set of vendors that report vulnerabilities and the languages that are used by those vendors. If one of the largest contributors to CVE/NVD primarily uses C as its programming language, the weaknesses that often exist in C programs are more likely to appear. Fuzzing programs can be very effective against memory-based programs, so they may find many more vulnerabilities. The scoring metric outlined above attempts to mitigate this bias by looking at more than just the most frequently reported CWEs; it also takes into consideration average CVSS score. Another bias in the CVE/NVD dataset is that most vulnerability researchers and/or detection tools are very proficient at finding certain weaknesses but not others. Those types of weakness that researchers and tools struggle to find will end up being under-represented within the 2020 CWE-Top 25. Finally, gaps or perceived mischaracterizations of the CWE hierarchy itself lead to incorrect mappings. The ongoing remapping work helps the CWE Team learn about these content gaps and issues, which will be addressed in subsequent CWE releases. Metric BiasAn important bias to understand related to the metric is that it indirectly prioritizes implementation flaws over design flaws, due to their prevalence within individual software packages. For example, a web application may have many different cross-site scripting (XSS) vulnerabilities due to large attack surface, yet only one instance of use of an insecure cryptographic algorithm. Remapping Task To prepare the CVE/NVD data for analysis, the CWE Team reviewed the CWE mappings of selected CVE/NVD entries and, where appropriate, “re-mapped” the entries so that they reference more appropriate CWE IDs. This re-mapping work was performed on over ten thousand CVE entries in consideration for the 2020 Top 25 List. The remapped data has been shared with NIST so that they can update their CVE entries within NVD. The primary activities were:
Archive Past versions of the CWE Top 25 are available in the Archive. |
