CWEs in NVD CVE feed: analysis and complaints. As you probably know, one of the ways to describe the nature of some software vulnerability is to provide corresponding CWE (Common Weakness Enumeration) ids. Let’s see the CWE links in NVD CVE base.

I have already wrote earlier how to deal with NVD feed using python in “Downloading and analyzing NVD CVE feed“. You can easily get CWEs ids iterating over cve_dict['CVE_Items'].

for item in cve_dict['CVE_Items']:
    print(item['cve']['CVE_data_meta']['ID'])
    print(item['cve']['problemtype']['problemtype_data'][0]['description'])

The sample output:

... 
CVE-2008-5549
[{u'lang': u'en', u'value': u'CWE-264'}, {u'lang': u'en', u'value': u'NVD-CWE-noinfo'}]
...
CVE-2011-1181
[]
...
CVE-2013-4219
[{u'lang': u'en', u'value': u'CWE-189'}]
CVE-2013-4220
[{u'lang': u'en', u'value': u'NVD-CWE-noinfo'}]
CVE-2013-4221
[{u'lang': u'en', u'value': u'CWE-91'}, {u'lang': u'en', u'value': u'CWE-16'}]
...
CVE-2015-6126
[{u'lang': u'en', u'value': u'CWE-362'}, {u'lang': u'en', u'value': u'NVD-CWE-Other'}]
...

As you can see, CWE list can be empty (also “NVD-CWE-noinfo” and “NVD-CWE-Other”), there may be only one CWE and multiple CWEs.

Statistics:

Has one CWE	57408
“NVD-CWE-Other”	26304
“NVD-CWE-noinfo”	6490
Has more than one CWE	978
Empty CWE list	399

* I filtered CVEs if "** REJECT **" in item['cve']['description']['description_data'][0]['value'].

As you can see, ~65% CVEs has actual CWE data. Not so bad.

Let’s see what these CWE ids really are. In NVD feed you can find only id, like “CWE-189”. To figure what is about you should use CWE dictionary. See them in Release Downloads. But they are a bit tricky to use, so I decided simply parse this page with CWE categories, that were used in NVD specifically.

So, the CWE usage in NVD CVE base looks like this:

And now it’s time for complaining.

I still do not understand the logic of CWE usage in the database NVD. As an information security specialist, I would like to see CWE id as a standard label telling me how this vulnerability can be exploited by an attacker. If this vulnerability is about Remote Code Execution,for example, I would like to see there CWE-94 (‘Code Injection’).

In real life it’s not like that at all. Let’s take for example CVE-2017-12939.

A Remote Code Execution vulnerability was identified in all Windows versions of Unity Editor, e.g., before 5.3.8p2, 5.4.x before 5.4.5p5, 5.5.x before 5.5.4p3, 5.6.x before 5.6.3p1, and 2017.x before 2017.1.0p4.

NVD classifies it:

Vulnerability Type: Input Validation (CWE-20)

Well, I’m glad that they have RCE because of insufficient input validation, but how should I understand by CWE-20 that this is some serious problem? It seems useless in this sense.

Or let’s take, for example, Heartbleed which was classified as:

Vulnerability Type: Buffer Errors (CWE-119)

Despite the fact that there is CWE – CWE-359: Exposure of Private Information (‘Privacy Violation’) (2.11). Why did not they use this id?

Unfortunately, CWEs in NVD base can be interesting now only for software developers of corresponding vulnerable products for improving SDLC. And these identifiers do not characterize the possible usage of this vulnerabilities by an attacker.

However, CWE classification by itself has all necessary capabilities for solving this task. It seems useful to perform some additional work on NVD database to add some more meaningful CWEs to the entities. It can be partly done by processing CVE description searching some key words like “Remote Code Execution”, “obtain sensitive information”, “Denial Of Service” etc. This method was probably used by third-party vulnerability base cvedetails.com for detecting “Vulnerability type”:

https://www.cvedetails.com/cve/CVE-2017-1000357/

Furthermore, it can be assumed that the vulnerabilities of the same type should have similar CVSS vectors. This can be used to validate classification and in the case when vulnerability description is not informative enough.