You can use the 2019 CWE Top 25 to help focus your application security efforts. Learn more about this list of the 25 most dangerous software weaknesses.
Lists of the best-of-the-best are always popular. But sometimes it’s important to have a list of the worst-of-the-worst.
Which is what the nonprofit MITRE provided in September with the release of its latest Common Weakness Enumeration (CWE) Top 25 Most Dangerous Software Errors list.
The 2019 CWE Top 25 is a list of horribles—errors, bugs, and potential attack vectors—that could lead to horrible things. Examples include hijacking of systems, data leaks (and therefore theft of sensitive data), denial-of-service (DoS) attacks, system crashes, execution of arbitrary code, and attackers preventing the software from working.
The list puts organizations on notice about the worst current software weaknesses, to help them avoid all those horrible things. MITRE calls it a “community resource” for those in the software industry, to give them “insight into some of the most prevalent security threats.”
It’s important to note that a “weakness” is not a “vulnerability”—at least not yet. As MITRE, which is funded by the federal Department of Homeland Security, puts it, the 2019 CWE Top 25 “is a demonstrative list of the most widespread and critical weaknesses that can lead to serious vulnerabilities in software.”
Put another way, these weaknesses are considered precursors to CVE entries. CVE (Common Vulnerabilities and Exposures), also maintained by MITRE, is a “dictionary” with definitions for tens of thousands of publicly disclosed cyber security vulnerabilities.
Ksenia Peguero, senior research lead at Synopsys, explains the difference: “Not every weakness qualifies for a CVE for two reasons,” she said. “One, a weakness in the code may be mitigated by a control outside of the codebase. Also, CVEs are vulnerabilities that are reported in specific software and their certain versions. CWEs, by contrast, are classes of vulnerabilities. For example, CWE-20 ‘Improper Input Validation’ or CWE-200 ‘Information Exposure’ are extremely wide classes that may manifest in many different ways in different applications.”
Jennifer Lang, external communications lead at MITRE, adds that “weaknesses are types of mistakes in software that could 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. “As the conditions may not exist for exploitation, not every weakness is a vulnerability.”
Chris Robinson, product security assurance lead at Red Hat, offers another way to understand it. “Think of CVE as a universal identifier for one computer problem,” he said. “CWE describes the ‘why’ behind the vulnerability—the coding/programming reason the vulnerability exists.”
The last time MITRE released a CWE Top 25 list was 2011. But the 2019 list, unlike the previous one, is “data-driven,” rather than based on surveys and interviews. Besides the CVE list, it gathered data from the National Institute of Standards and Technology (NIST), the National Vulnerability Database (NVD), which is within NIST, and the Common Vulnerability Scoring System (CVSS), which assigns scores to entries in the CVE database.
And Lang said the intent now is to publish the list annually.
The top weaknesses include improper restrictions on the bounds of a memory buffer and so-called cross-site scripting (XSS), a common vulnerability caused by a lack of control of user input on a webpage.
The 2019 CWE Top 25 is a “worst-of-the-worst” list. So it looks like the intent might be to help organizations save time and set priorities. They don’t have to wade through multiple lists of many thousands of vulnerabilities. Instead, they can focus on the couple dozen risks most likely to do them harm.
That, Lang said, is one of its purposes. “The 2019 CWE Top 25 list is one way to glean actionable insight from a vast amount of publicly available vulnerability data,” she said. She also noted that organizations can use it to check the software quality offered by vendors or open source projects. Doing so can help them avoid buying software “riddled with errors” when better alternatives are available.
Alternatively, “software vendors and projects can use the list as a priority ‘cheat sheet’ to eliminate the most prevalent and dangerous software errors prior to release,” she said.
Robinson said there are multiple uses for the list. “Organizations like Red Hat use CWE to conduct historic analysis of issues,” he said. “What trends do we see in a particular package or project? Are the same coding flaws being made over and over again? If so, we can devote time to raise [awareness] with the developer to avoid repeating those problems in the future.”
Yatin Patil, product management manager at Synopsys, cautioned that using the CWE Top 25 shouldn’t substitute for using other lists. “No one list is fully comprehensive; neither do they all address the same space,” he said. “Some only list vulnerabilities, some only focus on open source, etc. So it’s always good to consider everything.”
Robinson agrees, noting that different lists offer different kinds of assistance. “The CVE is one unique computer problem. Those CVEs should also include data around the root cause (CWE) and also a description of how the problem works (CVSS),” he said. “The three identifiers combined help security practitioners evaluate their risk if that CVE impacts their environment.”
Bottom line: The CWE Top 25 lists 25 ways to improve software security that can offer significant benefits. But, of course, you have to use it.
All the software testing and analysis tools on the market can help you find and fix bugs and other errors. Having a list of the riskiest software weaknesses helps you determine which tools you need.
For example, static analysis security testing (SAST) can detect code quality errors that lead to exploitable weaknesses like buffer overflow (No. 1) or “out-of-bounds read” (No. 5). Software composition analysis (SCA) can help organizations find coding weaknesses and potential licensing conflicts with open source software components.
Who is in charge of monitoring lists like the CWE Top 25? And who decides what, if anything, the organization needs to do?
“It depends,” Robinson said, “but vulnerability management is a shared responsibility. Generally someone has responsibility for governance—typically an InfoSec team—and another is responsible to ensure execution/deployment of those vulnerability fixes, which would be DevOps, Ops or ‘the computer guy.’”
But overall, experts agree that vulnerability management should influence the software development life cycle (SDLC)—from the beginning.
It’s called “shifting left,” and Patil said he hopes this list will push development teams in that direction.
“Think about the costs of releasing vulnerable applications, the negative publicity from being breached, or worse still, the downstream costs of exposure/loss of user data, like we saw with the Equifax data breach,” he said.
Robinson offers a final caution: You should evaluate lists of both weaknesses and vulnerabilities to see how they might apply to your digital assets. A list can be useful “as the proverbial canary in the coal mine, but in no way should it be treated as the ultimate authority on how vulnerabilities apply to specific products or how they might be deployed on-site or in-cloud for a consumer,” he said.
So use those lists to “follow up with the provider/owner/maintainer of the flawed package to understand more deeply the potential impacts as it relates to that particular deployment,” he said.