As we all know correlation is a very important aspect of vulnerability scanning. While performing a vulnerability scan, first assets are identified. Then a corresponding CPE is identified for each identified asset. Then CVEs are mapped to identified CPEs and thus vulnerabilities are correlated to identified assets.
CPE names are created on an as needed basis meaning CPEs are only generated when a CVE is released and the vulnerable target does not have an existing CPE. This implies the absence of a matched CPE name also indicates the absence of any issues.
The root of the problem is that to generate a useful CPE for a software component it needs to be predictably created and totally unique in order to match it against a central database which is then in-turn mapped to known vulnerabilities. The two fundamental limiting issues are:
- No central control over the naming of open-source components (i.e. not unique and predictable)
- The pace and manner in which components are created makes a central dictionary impractical
Use of CPEs for correlation has introduced false positives as well as false negatives. Following are the drawbacks of using CPE for correlation:
- There are CVEs which are not mapped to CPEs.
- There are assets which are not mapped to CPEs.
- According to CPE naming specification, version 2.3 representing user-defined configurations of installed products is out of scope.
- CPE has no provisions to tell you whether a vulnerable extension is installed or not.
Please refer below URLs for more details:
https://owasp.org/www-project-web-security-testing-guide/latest/5-Reporting/02-Naming_Schemes
https://www.arxiv-vanity.com/papers/1705.05347/
https://www.veracode.com/blog/managing-appsec/using-cpes-open-source-vulnerabilities-think-again
Solution: Switching to more evolved naming schemes such as SWID and PURL.
Happy Learning !!
