Knowing what could hurt you can help you.
That’s the point of the nonprofit MITRE’s 2020 Common Weakness Enumeration (CWE) Top 25 Most Dangerous Software Errors (CWE Top 25) list, released a few weeks ago.
As the title states, it’s a list of software problems most likely to cause you trouble—errors, bugs, and potential attack vectors. They could allow system hijacking, data leaks (and theft of sensitive data), denial-of-service (DoS) attacks, system crashes, execution of arbitrary code, and more.
As MITRE put it, “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 idea is that if you know about them, you can fix them. And since MITRE provides this handy list of the worst, you should fix those in particular, because bad guys surely are aware of them as well.
This is not something new from MITRE, but the lists are coming more quickly than in the past—much more quickly. When the company posted a list in September 2019, it was the first since 2011. At the time, the organization intended to make it an annual report, but this update came even sooner, in August 2020.
Jennifer Lang, external communications lead at MITRE, said each year’s list would be based on data from the previous two years, so this year’s list comes from CWEs found in 2018-19.
“As the overall mappings between vulnerability and weakness improve, and less time is needed to review existing mappings, the goal will be to release the list closer to the spring,” she said.
MITRE, which is funded by the U.S. Department of Homeland Security (DHS), said in a press release that the list is meant to be “a community resource that can help developers, testers, and users—as well as project managers, security researchers, and educators.”
The list contains the types of weaknesses that are familiar to security experts. Among the top 10 are cross-site scripting (XSS), SQL injection, improper input validation, out-of-bounds read, and exposure of sensitive information to an unauthorized actor.
It’s important to note that a weakness is not a vulnerability—at least not yet. As MITRE puts it, weaknesses like these “can lead to serious vulnerabilities in software.”
That means they are considered precursors, but they don’t qualify for the higher-profile Common Vulnerabilities and Exposures (CVE) list, also maintained by MITRE and created from data within the National Institute of Standards and Technology’s (NIST) National Vulnerability Database (NVD), as well as the Common Vulnerability Scoring System (CVSS) scores associated with each CVE.
Lang said weaknesses are types of mistakes in software that “contribute to the introduction of vulnerabilities within that software under the right conditions.”
“A vulnerability is a specific occurrence of one or more weaknesses that can be exploited under the right conditions to cause the software to behave in an unintended manner,” she said. “But as the conditions may not exist for exploitation, not every weakness is a vulnerability.”
Ksenia Peguero, senior research lead at Black Duck, added that “not every weakness qualifies for a CVE for two reasons. One, a weakness in the code may be mitigated by a control outside of the codebase. Also, CVEs are vulnerabilities that are reported in certain versions of specific software. CWEs, by contrast, are classes of vulnerabilities.”
“For example, the 2020 list has CWE-287, improper authentication, which can manifest in everything from weak password requirements, to incorrect implementation of OAuth flow, to a complete bypass of authentication services,” she said.
“Another example of a class of vulnerabilities is CWE-522, insufficiently protected credentials, which can range from lack of password hashing, to lack of salt, to using of weak hashing algorithms, like MD5.”
While there are thousands of vulnerabilities and weaknesses discovered every year—the 2018-19 NVD data used to compile this year’s list contained approximately 27,000 CVEs that are associated with weaknesses—not all of them are necessarily a major threat. And as has been noted many times at security conferences, it’s impossible to fix every defect in software. Any organization that tried would rarely get a product to market. It would grind development to a halt.
The CWE Top 25 list is a way to help developers and organizations set priorities. They can address the most significant threats without slowing development down.
The MITRE list should also not be the only resource organizations use to improve the security of their software. Some critics note that the CVE doesn’t assign a number to all vulnerabilities—in 2018 it was reported that only 62% of known vulnerabilities assigned a number.
Peguero said the CWE list “may be skewed, because it is based only on the vulnerabilities that do get a CVE number. To get a CVE number, the vulnerability must be publicly disclosed and must be in a popular enough, usually publicly facing, application.”
“A lot of vulnerabilities that get reported in bug bounty programs do not get disclosed and do not get a CVE number, because the process is lengthy and tedious,” she said, adding that the OWASP Top 10 relies on more accurate data “as it is based not only on open source and publicly known applications, but also on internal commercial applications assessed by different security companies.”
She said she was surprised to see CWE-862, missing authorization, at the bottom of the MITRE list—number 25. “From what Black Duck consultants see in client code, this weakness occurs much more often than some others on the CWE list,” she said.
But as is always the case with the MITRE Top 25 CWE list, the OWASP Top 10, or any other list, if you want the benefits, you have to use the information in them. That means finding and fixing the identified weaknesses in your software.
And there are multiple software testing and analysis tools on the market, all designed to help with that. Having a list of the riskiest vulnerabilities can point to which tools are best to find and fix them.
According to Lang, “most of the static analysis tools on the market have incorporated the CWE Top 25 into their products as a way to triage and report findings from their analysis.”
That includes Coverity®, which, as Yatin Patil, former product manager at Synopsys, and Anna Chiang, former senior manager, product marketing at Synopsys, write in a blog post, “is one of only a few major static application security testing (SAST) solutions that are strong in identifying both code quality issues and security issues.”
Peguero said a static analysis tool like Coverity will be best at identifying an out-of-bounds read (CWE-787) or out-of-bounds write (CWE-125), while a dynamic analysis tool like Tinfoil will be best at identifying issues with missing authorization (CWE-862) or missing authentication for critical function (CWE-306).
And a software composition analysis (SCA) tool like Black Duck® can help organizations find open source software coding weaknesses and potential licensing conflicts.
All of which points to another important reality: A single tool won’t do it. It takes a combination of testing tools, throughout the SDLC, used at the right time, to bring a product to market with robust security.