2010 Top 25 Q & AHow is this different from the OWASP Top Ten? The short answer is that the OWASP Top Ten covers more general concepts and is focused on web applications. The CWE Top 25 covers a broader range of issues than what arise from the web-centric view of the OWASP Top Ten, such as buffer overflows. Also, one goal of the CWE Top 25 is to be at a level that is directly actionable to programmers, so it contains more detailed issues than the categories being used in the Top Ten. There is some overlap, however, since web applications are so prevalent, and some issues in the Top Ten have general applications to all classes of software. How are the weaknesses prioritized on the list? The 2010 list was built using a survey of 28 organizations, who ranked potential weaknesses based on their prevalence and importance, which provides some quantitative support to the final rankings. What happened to input validation? It was number one last year, and now it's gone. It's not gone, it's just moved to the Monster Mitigations section. A number of general-purpose CWE entries were removed from the Top 25 because they overlapped other items. This also made room for other, more specific weaknesses to be listed. Why did you remove the threat model from the 2010 list? While this was a useful exercise in 2009, the Top 25 has too much of a general audience to select a single threat model. This year, the use of focus profiles is intended to help prioritize items using other means. Why don't you use hard statistics to back up your claims? The appropriate statistics simply aren't publicly available at a low enough level of detail, but in 2009 and 2010, much progress is being made. The publicly available statistics are either too high-level or not comprehensive enough. And none of them are comprehensive across all software types and environments. For example, in the CVE vulnerability trends report for 2006, 25% of all reported CVE's either had insufficient information, or they could not be characterized using CVE's 37 flaw type categories. That same report only covers publicly-reported vulnerabilities, so the types of issues may be distinct from what security consultants find (and they're often prohibited from disclosing their findings). Finally, some of the Top 25 captures the primary weaknesses (root causes) of vulnerabilities - such as CWE-20, CWE-116, and CWE-73. However, these root causes are rarely reported or tracked. Why is so much stuff related to web applications? Even products that aren't web-based often have web applications within them - for example, a web-based management interface, an HTML converter or renderer, etc. SQL injection (CWE-89) is not unique to web applications. Only CWE-79 (XSS) and CWE-352 (CSRF) are unique to web applications. Other entries apply to other classes of software, although they might be extremely common in web applications, such as SQL injection. In other words, the apparent bias toward web applications isn't as bad as it might seem. To convince yourself of this, look at the observed and demonstrative examples in the individual pages on the CWE web site. Why did you include mitigations in the Top 25 document instead of just pointing to them on the CWE site? Since developers are one of the primary audiences, it was believed that much of their focus would be on mitigations, and many developers might want to print out the Top 25 for consultation during programming. So, it's a matter of convenience for them. In addition, the mitigations in the CWE entries may change over time. In future Top 25 lists, we will be certain that the mitigations will be consistent with their CWE entries at the time of release. Why did you include design problems? I thought this was for programmers. One intended audience is developers, not just programmers. Also, in some software shops, programmers do some amount of local design in addition to implementation. What's the difference between a "weakness" and a vulnerability? That's actually a deep philosophical question with a long, convoluted-sounding answer. The short answer is that a weakness is simply a general type of developer error, independent of the context that the error occurs in. Sometimes, it might not have any security relevance at all. However, when the weakness appears in deployed software, and it's in a place in code that may be accessible to attackers, then it could turn into a vulnerability if the conditions are right. It might include the presence of other weaknesses, for example. Further complicating the issue are the diverse perspectives and inconsistent terminology that is used within software security, which is still a relatively new field (especially compared to, say, bridge engineering). People with different perspectives may use the same terminology, or concentrate on different aspects of a problem. For example, depending on the person speaking, the phrase "buffer overflow" could mean the type of programmer error, the type of attack, or the type of consequence. CWE (and the Top 25) have to be usable to many people with these different perspectives, so there is bound to be confusion until the industry matures. Why does this list have so many of the usual suspects? What about the new weaknesses that are just starting to become a concern? Consider the "On the Cusp" page as well as the focus profile for established secure developers. How is this different from the Seven Pernicious Kingdoms taxonomy? Seven Pernicious Kingdoms (7PK) does not prioritize the bugs that it contains, which results in bugs with varying severities and prevalence. Both Seven Pernicious Kingdoms and the Top 25 have developers as a target audience, but 7PK focuses on bugs that are introduced during implementation. The Top 25 covers problems that may arise in implementation as well as design, configuration, installation, and other SDLC phases. The Seven Pernicious Kingdoms taxonomy also uses a relatively small number of categories to make it easier for developers to remember, and the Top 25 is a flat list that tries for broader coverage at the small expense of usability. Finally, the Top 25 emerged from the direct input of dozens of individuals and is backed with extensive information in the CWE entries themselves. With all that said, we believe that Seven Pernicious Kingdoms is an important taxonomy in the understanding of software weaknesses, and its influence is reflected in much of CWE. |
