An update was recently made to the CWE Top 25 for the first time in several years. This update included a new methodology to objectively determine which CWEs are most common and most dangerous. This update brings CWE into alignment with the constantly changing application security landscape and bears in mind real problems occurring in real applications today. This update also included changes to the On the Cusplist from CWE, which essentially extends the Top 25 to the Top 40. More on this below.
The CWE or Common Weakness Enumeration is a community supported list of the most common cybersecurity weaknesses. It considers a wide variety of dangerous software issues, in fact over 800 of them ranging from memory problems like buffer overflow to tainted data issues like SQL injection (SQLI). It’s perhaps most well-known for its CWE Top 25 list that is used as a secure coding standard.
The interesting thing about CWEs list of weaknesses is that they have a correlation with real problems that have happened in real software systems. When bad things happen in cybersecurity, like a data breach, a hacked router, or a vulnerable security camera, there will be a record in the National Vulnerability Database, or NVD. (Ok, not everything ends up in NVD – but maybe it should.) Each entry is identified with a unique number called a CVE, or Common Vulnerability Enumeration and is assigned an NVD score called a CVSS, which is the Common Vulnerability Scoring System to show how dangerous the security issue is.
This CVE describes the security issue in a way that can be used to compare similar issues across other products and software. When there is a problem with a home security camera and with an office router, it is possible to recognize that the underlying problem is the same. Maybe the problem is that there’s weak encryption or that a default password has been programmed into it. So, the CVE helps us discuss security problems in an apples-to-apples, and oranges-to-oranges way so that we can better understand, plan, and respond.
Each CVE is eventually populated with CWE IDs associated with the root weakness in the code that gives rise to the security issues in the CVE, for example, a discovered vulnerability in a router, at some point, an investigation leads to identifying the code responsible. This root cause is described in terms of the weakness in the software such as an unchecked input string that the vulnerability exploited.
Now that’s a bit of a long walk and with too many acronyms, but it basically means you can indeed correlate published security problems with the underlying software weakness in code. Ultimately then, as a developer you can avoid the problems that are happening to real applications and devices in the real world.
Earlier in 2019 they added new CWEs related to quality and reliability. With time, this will increase. For the time being, these are limited to mostly security weaknesses. Given there are so many of them, where do you start? The CWE includes a list of Top 25 in an attempt to help determine the most critical, likely and impactful security weaknesses in software. However, the Top 25 is a starting point. For teams already checking for these weaknesses, they should continue down the list. But if you haven’t done anything yet, it’s a great place to start.
The CWE Top 25 has remained relatively static until late 2019. In 2019, we had, for the first time, an update to CWE the first time since 2011. The entire CWE gets updated on a regular basis, however the Top 25 hasn’t as much, at least until now.
This new list was based on not only the NVD, but also based on real world problems found internally in large organizations that had issues that weren’t publicized or included in NVD. This was a change in approach since it took into account a lot of different data sources and also added some subjectivity based on industry opinion.
What’s interesting with the latest update is a more objective approach. The downside, of course, is that we might have lost something in the sense that we don’t have access to the private data used to generate the new list. The pro is that we know what the CWE Top 25 represents – “the real-world list and order of the most common weaknesses” – from all the reported vulnerabilities as expressed in the National Vulnerability Database.
There is meaning to the placement of a CWE on the Top 25 – there relative level of danger based on the CVSS score each. For example, CWE at position 25 isn’t nearly as dangerous as number one, although to be clear; all weaknesses should be considered dangerous, they’re all bad and the ultimate goal is to fix them.
The other interesting thing about CWE Top 25 that a lot of people are unaware of, is that there is a thing called On the Cusp. These are the CWEs that almost made it to the Top 25, On the Cusp is what I like to refer to as the honorable mentions, or maybe dishonorable mentions. Once you’ve finished the rooting out top 25, go to On the Cusp. That’s the next thing that’s important.
If you’re wondering where to get started, the CWE Top 25 is a great starting point, no matter what kind of application you have. If you’re getting close to eliminating all the top 25 weaknesses in your software, take a look at the On the Cusp rules. The CWE Top 25 weaknesses is referenced by Underwriter’s Laboratory UL 2900, which is a cybersecurity certification for connected devices. Another, great place to go next. For web applications, take a look at OWASP and the OWASP Top 10.
If you are a Parasoft customer or a static analysis tools user and weren’t aware of the CWE Top 25 update, it’s a good time to look at your tool configuration. Look to make sure that you’re covering the latest CWE list, as this is literally the state of the art in software security weaknesses.
In the future, it makes sense to keep any eye on the standard and incorporate changes over time. It’s also important for tool vendors to conform to the latest CWE. Since you are relying on them, to some degree, to be the experts in supporting and reporting based on the new rules. As you progress in secure development, make sure that your tools support the On the Cusp rules, because, again, there isn’t a hard stop in security weaknesses at 25.
To learn more about Parasoft’s CWE solution, please visit https://www.parasoft.com/solutions/compliance/cwe/.
Arthur has been involved in software security and test automation at Parasoft for over 25 years, helping research new methods and techniques (including 5 patents) while helping clients improve their software practices.