When viewing an IQ Server evaluation report, you will have seen vulnerabilities reported with an ID of "Sonatype", and may have wondered what they mean and how they differ from public CVEs.
Sonatype ingests vulnerability information from a large number of sources, including GitHub advisories, feeds, blogs, and occasionally our Security Research team's own findings. For vulnerabilities lacking a CVE identifier at the time of their discovery, Sonatype assigns these a proprietary Sonatype-XXXX-YYYY identifier, where XXXX is the year the vulnerability was publicly disclosed and YYYY being the vulnerability number, unique in that year.
Should a CVE ID later be assigned to a vulnerability we have already assigned a Sonatype ID to, we do not remove the original Sonatype ID. Instead, we add a note to the Explanation section of our data with the CVE ID.
This is an intentional step in the workflow to prevent duplicate notifications from triggering and the need for customers to repeatedly waive violations, where applicable.
For some vulnerabilities, such as the vast majority of those reported to OSS projects via their GitHub "Issues" section, a CVE ID is almost never requested by the project developers/vulnerability reporters and never assigned. The assignment of a Sonatype ID by us facilitates the cataloging of such vulnerabilities in our data much quicker and prevents duplicates. Other times, in cases where a large number of CVE IDs were assigned for the same type of flaw (e.g. Jackson Databind deserialization flaw, ZIP Slip vulnerability, etc.), Sonatype may decide to group all of these CVEs under one Sonatype ID, to reduce noise and duplicate alerts.
Another use case of the Sonatype ID is when our automated malware detection systems find malicious/suspicious components. For every such case, we need not wait on a CVE assignment and are able to provide world-class data on malicious components and vulnerabilities much faster by using our Sonatype IDs.