-
Notifications
You must be signed in to change notification settings - Fork 1
Description
As a security researcher or software remediator I struggle with triaging and remediating a CVE when I don't know the CPE or PURL associated with it. This is even harder to do when vulnerability enrichment processes post-publication try to fill the gaps and do so incorrectly.
For example CVE-2025-62499 tells me there's a vulnerability with a technology called MovableType, but there's no CPE. The CISA enriched data here provides me with a product name and version information, but no CPE or PURL. One of the very popular scanning tool vendors that reported this vulnerability did their own "research" and associated this vulnerability with an software component provided by a company called "SixLabors" -- perhaps because the CVE was associated with a technology provided by a vendor called "Six Apart." It was a mistake. They tried to fill the gap, one that could be filled at the time the CVE was published so that we don't have to rely upon vendors (and their mistakes) to understand the public report.
For those in a regulated industry, we now have to formally address the misidentified vulnerability that affects many applications that are not and have never used MovableType. We don't have the luxury of ignoring this as a mistake. Rather, we have to document that it's a false positive, provide evidence of this, and ideally create a process to identify this so that we don't get another batch of false positive findings. All because the CVE was published without enough information to use in an automated manner. Reading the description to infer the affected products does not scale. We need a CPE or PURL so that we can match the report to an application.