The personal problems I have with the NVD and CVEs in general are:
- CVEs can be disputed, and this is not based on evidence and can be marked as not affected with as little evidence as "EOL" or end-of-life. See 100% of CVEs filed against SAP, for example. All valid exploits, all work, all are used in the wild by ransomware, and all are still disputed by SAP.
- CVEs are free-form text, which makes even version strings uncomparable. Most projects down the line don't "sanitize to ASCII" and don't know about this. But there are many CVEs (~1%ish) with Chinese idiom symbols as a "." character replacement. Nobody fixes that, ever.
- CVEs and their affected hardware/software matching strings (CPEs) are utterly useless. They are an abstraction for the manual excel spreadsheet world, and literally every linux security tracker implements their own somewhat crappy parser to match against the real upstream projects, their package names and/or the source code origins (e.g. a git repo link).
- CPEs are redundant. The linux kernel itself has more than 200 different CPE strings, and none of them are recorrected after they have been filed by the reporting person. What the actual duck. Have fun trying to find out if Arch Linux is affected when the initial CVE was filed against, say, SUSE or Oracle Linux.
- Most hardware vendors wait to confirm or deny anything until their hardware is EOL. Smart, right? Nobody knows so it must be secure, right? Looking at you, Cisco, Fortinet and the like. And now you are wondering why exploits from 2016 are still used and shared in Telegram channels of ransomware developers?
- There is no mandatory PoC in the CVE database. This could change so much in the ecosystem, especially with the hardforked still-patched feature frozen packages of distributions like Debian. Debian's security tracker is littered with "marked as fixed" but actually "can't fix it because code diverged too much from upstream already" CVEs. And guess what, those are exactly those exploits used in the wild by root/bootkits.
- As the article author states, CVEs are never recorrected. This is the biggest issue of all of them. Nobody maintains a sane state of the database, even the new git repositories are buggy as hell and don't validate against their own schema. Nobody fixes those CVEs "upstream" and nobody maintains old CVEs that turn out to affect more upstream projects. Prime example is log4j, because literally almost all java software is affected when they bundle(d) it; which almost all of them do. I complained to this but basically can't or won't be fixed [2], [3], [4] because even the new schemas are experimental (for over 8 years now).
Source: am scraping literally all linux security trackers to make a better CVE database for automatic comparison purposes. And it's a super ducked state of affairs. [1]
[1] https://github.com/tholian-network/vulnerabilities
[2] https://github.com/CVEProject/cvelistV5/issues/4
[3] https://github.com/CVEProject/cvelistV5/issues/5
[4] https://github.com/CVEProject/cvelistV5/issues/6
- CVEs can be disputed, and this is not based on evidence and can be marked as not affected with as little evidence as "EOL" or end-of-life. See 100% of CVEs filed against SAP, for example. All valid exploits, all work, all are used in the wild by ransomware, and all are still disputed by SAP.
- CVEs are free-form text, which makes even version strings uncomparable. Most projects down the line don't "sanitize to ASCII" and don't know about this. But there are many CVEs (~1%ish) with Chinese idiom symbols as a "." character replacement. Nobody fixes that, ever.
- CVEs and their affected hardware/software matching strings (CPEs) are utterly useless. They are an abstraction for the manual excel spreadsheet world, and literally every linux security tracker implements their own somewhat crappy parser to match against the real upstream projects, their package names and/or the source code origins (e.g. a git repo link).
- CPEs are redundant. The linux kernel itself has more than 200 different CPE strings, and none of them are recorrected after they have been filed by the reporting person. What the actual duck. Have fun trying to find out if Arch Linux is affected when the initial CVE was filed against, say, SUSE or Oracle Linux.
- Most hardware vendors wait to confirm or deny anything until their hardware is EOL. Smart, right? Nobody knows so it must be secure, right? Looking at you, Cisco, Fortinet and the like. And now you are wondering why exploits from 2016 are still used and shared in Telegram channels of ransomware developers?
- There is no mandatory PoC in the CVE database. This could change so much in the ecosystem, especially with the hardforked still-patched feature frozen packages of distributions like Debian. Debian's security tracker is littered with "marked as fixed" but actually "can't fix it because code diverged too much from upstream already" CVEs. And guess what, those are exactly those exploits used in the wild by root/bootkits.
- As the article author states, CVEs are never recorrected. This is the biggest issue of all of them. Nobody maintains a sane state of the database, even the new git repositories are buggy as hell and don't validate against their own schema. Nobody fixes those CVEs "upstream" and nobody maintains old CVEs that turn out to affect more upstream projects. Prime example is log4j, because literally almost all java software is affected when they bundle(d) it; which almost all of them do. I complained to this but basically can't or won't be fixed [2], [3], [4] because even the new schemas are experimental (for over 8 years now).
Source: am scraping literally all linux security trackers to make a better CVE database for automatic comparison purposes. And it's a super ducked state of affairs. [1]
[1] https://github.com/tholian-network/vulnerabilities
[2] https://github.com/CVEProject/cvelistV5/issues/4
[3] https://github.com/CVEProject/cvelistV5/issues/5
[4] https://github.com/CVEProject/cvelistV5/issues/6