2019 CWE Top 25 Most Dangerous Software ErrorsNOTICE: This is a previous version of the Top 25. For the most recent version go here. Introduction The Common Weakness Enumeration (CWE™) Top 25 Most Dangerous Software Errors (CWE Top 25) is a demonstrative list of the most widespread and critical weaknesses that can lead to serious vulnerabilities in software. These weaknesses are often easy to find and exploit. They are dangerous because they will frequently allow adversaries to completely take over execution of software, steal data, or prevent the software from working. The CWE Top 25 is a community resource that can be used by software developers, software testers, software customers, software project managers, security researchers, and educators to provide insight into some of the most prevalent security threats in the software industry. To create the list, the CWE Team used a data-driven approach that leverages published Common Vulnerabilities and Exposures (CVE®) data and related CWE mappings 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 of the CVEs. A scoring formula was then applied to determine the level of prevalence and danger each weakness presents. This data-driven approach can be used as a repeatable, scripted process to generate a CWE Top 25 list on a regular basis with minimal effort. The CWE Top 25 Below is a brief listing of the weaknesses in the 2019 CWE Top 25, including the overall score of each.
Methodology The 2019 CWE Top 25 was developed by obtaining published CVE vulnerability data found within the NVD. The NVD obtains vulnerability data from CVE and then supplements this data with additional analysis and data to provide more information about vulnerabilities. In addition to providing the underlying weakness for each vulnerability, the NVD provides 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 CWE Top 25. This approach provides an objective look at what vulnerabilities are currently seen in the real world, creates a foundation built on publicly reported vulnerabilities instead of relying on surveys and opinions, and makes the process repeatable in future years. The 2019 CWE Top 25 leverages NVD data from the years 2017 and 2018, which consisted of approximately twenty-five thousand CVEs. The CWE team developed a scoring formula to calculate a rank order of weaknesses. The scoring formula 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 NVD. Only those CVEs that have an associated weakness are used in this calculation, since using the entire set of CVEs within 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 scoring method that merit further explanation.
The CWE Top 25 with Scoring Metrics The following table shows the 2019 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 As in years past, the CWE team feels it is important to share additional CWEs that scored just outside of the top 25. Per the 2019 scoring formula against the NVD dataset, these weaknesses were potentially not severe enough, or not prevalent enough, to be included in the 2019 list. Developers that complete mitigation and risk decision-making on the 2019 CWE Top 25 may want to look for these other weaknesses potentially present in their software. For these reasons, users of the 2019 CWE Top 25 should seriously consider including these additional weaknesses in their analyses:
Limitations of the Methodology There are several limitations to the data-driven approach chosen by the CWE Team. Data BiasFirst, the approach only uses data that was publicly reported and captured in NVD, and numerous vulnerabilities exist that do not have CVE IDs. Vulnerabilities that are not included in NVD are therefore excluded from this approach. For example, CVE/NVD typically does not cover vulnerabilities found and fixed before any software 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 2019 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 that is exploited. Many CVE entries are published by software vendors who only describe the impact of the vulnerability without providing details of the vulnerability itself. In other cases, the CVE description covers how the entry is attacked – but this does not always indicate what the associated vulnerability 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. 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. The CWE Team identified at least 2,600 CVEs that had insufficient details to perform a precise CWE mapping. 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 do not find other types of weaknesses. Those types of weakness that researchers and tools struggle to find will end up being under-represented within the 2019 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, “remap” the entries so that they reference more appropriate CWE IDs. For remapping, the CWE team used a broader range of CWE IDs than NVD analysts previously had available, and the team was stricter about explicitly labeling insufficient information. This remapping work was performed on thousands of CVE entries. It produced a richer list of CWE IDs for NVD analysts to choose from, as reflected in the updated CWE-1003 view. The remapped data has been shared with NIST so that they can update their CVE entries within NVD. The remapping was performed iteratively, and the team eventually developed a more repeatable process that can be performed in future versions of the Top 25. The primary activities were:
What Changed The major difference between the 2011 and 2019 CWE Top 25 lists is in the approach that was used. The 2011 CWE/SANS Top 25 was constructed using surveys and personal interviews with developers, top security analysts, researchers, and vendors. These responses were normalized based on the prevalence and ranked by the CWSS methodology. The 2019 CWE Top 25, on the other hand, was formed based on real-world vulnerabilities found in the NVD. As a result of this change in approach, a few changes to the list of weaknesses that make up the CWE Top 25 was expected. The biggest of these changes is the inclusion of some class level CWEs that represent broad types of errors: CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer), CWE-20 (Improper Input Validation), CWE-200 (Information Exposure) and CWE-287 (Improper Authentication). These entries are often used by vendors and researchers to describe the root cause of a vulnerability being reported and are therefore prevalent in our data-driven analysis of NVD. Looking closer, however, these high-level weaknesses are often the parent of more detailed weaknesses that appeared in previous Top 25 lists. For example, CWE-119 is the parent of CWE-120. While the latter was #3 in the 2011 list, it is not found on the 2019 list despite the former being the new #1. Similarly, CWE-287 is #13 in 2019 but does not at appear in 2011. Looking closer however shows that CWE-287 is the parent of CWE-306 (#5 on the 2011 list), CWE-862 (#6 on the 2011 list), and CWE-863 (#15 on the 2011 list), none of which are found on the 2019 list. Another interesting change is that some weaknesses in the 2019 list are reported at a different place within a potential chain of weaknesses. For example, CWE-787 (Out-of-bounds Write) did not appear in the 2011 list but is #12 in 2019. CWE-787 is often part of a chain that starts with CWE-120, which was #3 in 2011. A few other 2019 CWE Top 25 List entries also deserve some attention.
Lastly, CWE-20 and CWE-200 (#3 and #4, respectively), are class level weaknesses and well-known secure coding problem areas. The CWE team believes there are potentially instances when these entries are used for mapping vulnerabilities to CWE when more specific, lower-level weakness types might be more appropriate. This is an area that the CWE Team is further investigating and hopes to improve in future versions of the CWE Top 25. Archive Past versions of the CWE Top 25 are available in the Archive. |