Has CWE Jumped the Shark?

The Common Weakness Enumeration (CWE) is a MITRE run, community-developed list of common software and hardware weaknesses (Wikipedia Page). The project defines a “weakness” as “a condition in a software, firmware, hardware, or service component that, under certain circumstances, could contribute to the introduction of vulnerabilities.” This taxonomy has several uses but they tend to skew a bit more academic and SecDevOps than practical day-to-day security (i.e. patching). You can view the full list of CWE, but be warned it is literally a 2,812 page PDF file.

In practice, the National Vulnerability Database (NVD) has associated CWE IDs to individual disclosures historically. More recently, CVE Authorized Data Publishers (ADP) have been given authority to generate this metadata as well. In limited cases, there are instances where vague details are given about a vulnerability but a CVSS score and/or CWE score is provided, both of which can give a lot more context. Developers can use CWE to help direct where to perform more code auditing and do additional training on secure coding practices. Overall, CWE can be very helpful.

Like all of the “C” projects managed or started by MITRE (e.g. CVE, CPE, CME), they are funded by U.S. taxpayers. Programs like CVE are ongoing, meaning vulnerability disclosures will not stop ergo cataloging them must not stop either. Other programs like CWE arguably have a development lifespan, and I believe that should be the case here. That is not to suggest CWE should go away, just that the funding for this program should be cut back or cut entirely. The remaining work needed to manage the program should be folded into CVE, transferred to NIST, and should not receive any real budget to continue.

Realistically, there is a fairly finite number of classes of vulnerabilities. Even when abstracting e.g. “classic buffer overflow” (CWE-120) to “out-of-bounds read” (CWE-125) or “out-of-bounds write” (CWE-787) for example, you will hit a wall sooner than later. Additionally, as new technology comes out such as large language models (LLM), new classes of vulnerabilities will manifest such as “Improper Neutralization of Input Used for LLM Prompting” (CWE-1427, the latest at the time of this blog). However, that doesn’t happen very often these days. A “community-developed” list such as this does not require that much time or effort to maintain in my opinion.

The list was further expanded to include “Categories” such as “ICS Operations (& Maintenance): Gaps in obligations and training” (Category-1378) and “Views” such as “Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses” (View-1430). To me, some of these seem more like justification for continued contract money than real benefit. You can maintain a “Top” list of CWE without needing a “View” of it.

Recently, while doing some CWE integration work in VulnDB, I was curious and asked one of our amazing data manglers (Tomas Acosta, thank you!) the simple question, “how many CWE IDs are not associated with any vulnerabilities?“. As with any vulnerability-related statistic, metric, or even “simple” numbers, there should be caveats. In this case, the big one being that not all vulnerabilities (even in the CVE ecosystem) have a CWE associated. Despite that, NVD has been assigning CWE for some time so the data set is fairly substantial. So… the answer, now sorted:

5, 7, 8, 9, 13, 33, 38, 43, 44, 45, 46, 47, 48, 49, 51, 52, 53, 54, 55, 58, 62, 71, 72, 102, 103, 104, 105, 106, 107, 109, 110, 132, 135, 142, 143, 145, 151, 152, 157, 160, 161, 162, 163, 164, 165, 174, 175, 181, 207, 217, 218, 222, 224, 238, 243, 245, 246, 247, 333, 370, 373, 375, 382, 383, 396, 397, 423, 430, 432, 433, 443, 458, 462, 464, 469, 478, 481, 483, 486, 487, 492, 493, 495, 496, 498, 500, 508, 510, 511, 514, 515, 516, 529, 531, 533, 535, 536, 537, 541, 542, 543, 545, 546, 553, 554, 558, 560, 568, 572, 574, 575, 576, 577, 578, 579, 580, 581, 582, 583, 584, 585, 586, 589, 593, 594, 595, 596, 600, 607, 608, 609, 615, 619, 637, 651, 652, 655, 663, 666, 673, 685, 695, 766, 768, 773, 781, 785, 793, 795, 796, 797, 806, 831, 1041, 1042, 1043, 1044, 1045, 1046, 1048, 1053, 1054, 1058, 1060, 1061, 1062, 1063, 1064, 1065, 1066, 1067, 1069, 1070, 1071, 1072, 1073, 1074, 1078, 1079, 1080, 1082, 1084, 1085, 1086, 1087, 1089, 1090, 1091, 1092, 1093, 1094, 1095, 1097, 1098, 1099, 1101, 1102, 1105, 1106, 1109, 1110, 1111, 1113, 1114, 1115, 1116, 1117, 1119, 1120, 1121, 1122, 1123, 1124, 1126, 1127, 1164, 1174, 1177, 1192, 1193, 1209, 1222, 1229, 1232, 1235, 1239, 1243, 1248, 1249, 1252, 1261, 1265, 1267, 1268, 1271, 1273, 1276, 1277, 1280, 1290, 1292, 1293, 1294, 1296, 1297, 1302, 1310, 1311, 1312, 1313, 1315, 1316, 1317, 1318, 1322, 1324, 1331, 1338, 1339, 1351, 1384, 1420, 1421, 1426, 1427

That’s 265 IDs that are not associated. For fun, that is 200 if you ask Gemini, 283 if you ask Copilot, and 198 if you ask ChatGPT but that rant is for another day. So 265 IDs out of how many one might ask. Good question and I can maybe answer because the current CWE page says there are 940 IDs, but the latest download of XML data has 965. Who’s counting! If we use the larger number, that is 27% of IDs that were created and have not been used. To me, that suggests that CWE has lost its way a bit. But, is it really that bad?

First, it is important to note that this list does not include ‘categories’ or ‘views’, which is to be expected. Second, let’s take a look at a few random IDs from this list and see why they might not have been used. Take the first on the list, CWE-5, which corresponds to “J2EE Misconfiguration: Data Transmission Without Encryption” and I already have questions. How does an ID this low not get used, and why does it specify J2EE in the title but not in the description? Over the years it became a child of CWE-319 which is “Cleartext Transmission of Sensitive Information“. Why abstract CWE-5 for J2EE specifically, especially that early on?

Next, look at CWE-33 which is “Path Traversal: ‘….’ (Multiple Dot)“. Another curious case where an early ID is very specific, and that early on the four dots (if we use their example) was pretty rare. But, most disclosures were effective using two dots (i.e. /../) so four wasn’t commonly tested or needed. If it isn’t supposed to represent four specifically, then this could apply to a majority of unencoded path traversals and we’d expect to see it more often, or it should have been deprecated. This is a good example of one that should be clarified or discontinued.

CWE-62, or “UNIX Hard Link” is a peculiar one. Hard-link attacks against Unix systems were common enough in the 1990s that I would expect to see this used. Instead, it suggests that it was due to not backfilling CWE into those historic vulnerabilities and/or CVE making little effort to do historical coverage. Rather than try to do decent coverage the first couple years, they did a token backfill primarily around CERT and a few other sources and then began tracking more moving forward. Of course, we know that approach still causes them to miss many thousands of vulnerabilities a year.

How about CWE-333 which covers “Improper Handling of Insufficient Entropy in TRNG“? That is definitely a thing we see, right? Apparently not, and instead we see CWE-331 for “Insufficient Entropy” and CWE-338 for “Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)” instead. This again leads me to wonder why CWE-333 was abstracted from CWE-331 despite it apparently not being seen in a vulnerability disclosure.

Finally, how about CWE-1427 which I know we see in the wild? “Improper Neutralization of Input Used for LLM Prompting” is all the rage lately, for a couple years at least, yet somehow it hasn’t been used by NVD? Once again, it begs the question why we’re having MITRE create CWE IDs that see no use. What value does that serve? If they are essentially mistakes and should not be used in favor of other IDs, then deprecate them. If the dust settles around the current administration and government cuts, I’ll have to submit a FOIA request to see how much money taxpayers are on the hook for to cover this project.