Incorrect purl for [email protected] results in missed CVE

[willem-delbare]

What happened:

Scanning an image with mysql-connect-java.jar results in incorrect purl. This results in missed CVE

wrong purl = pkg:maven/com.mysql/[email protected]

What you expected to happen:

purl = pkg:maven/mysql/[email protected]

Note difference between
https://mvnrepository.com/artifact/mysql/mysql-connector-java
and
https://mvnrepository.com/artifact/com.mysql/mysql-connector-j

[spiffcs]

It looks like this jar was moved to a different group ID and the vulnerability data is split between the two.

We need to figure out how to handle this case and investigate if we're handling it elsewhere.

This screenshot from the first link shows the move

[kzantow]

I think once V6 lands, having a per-ecosystem package name alias table would be a reasonable solution to handle this type of thing, where the matching processes matches against all name aliases: newer packages we discover should find and include the old alias(es), and older-named packages should find and additionally include the new alias(es).

[westonsteimel]

The upstream vuln data (GitHub Advisories) should already be accounting for both in the cases where it matters the most. Is there a specific example observed where that isn't the case? I've just reviewed the records and don't see any obvious ones where it is likely to make an impact on vuln matching. The 8.x series is split between the old and new names, anything less than 8 is only in the old namespace and anything newer is only in the new one

[westonsteimel]

So for the example provided with version 8.0.30, the only relevant one I see is GHSA-m6vm-37g8-gqvh and it has both variations so should result in vulnerabilities being reported

[westonsteimel]

But yes, grypedb v6 will make this more robust since we'll have a way to alias packages so that both com.mysql:mysql-connector-j and mysql:mysql-connector-java would be found whether or not the vuln data accounts for it.

[westonsteimel]

Ah, I see the problem here now though, it's that the purl raised up has mysql-connector-java as the artifact id rather than mysql-connector-j, so it won't match any of the records because it isn't the new or old name, it is a combination of both. This is likely because the metadata doesn't actually contain a maven groupid/artifactid combo so syft is having to guess it from classpath or something

[westonsteimel]

This is just another example of where maven artifact identification based on included metadata can be difficult and having a secondary database of lookups by digest would really improve the quality

[westonsteimel]

@kzantow , I don't see another way to fix this in syft other than with lookup by digest. We can't use the hardcoded mappings because that is all about mapping a known groupid to the artifactid that syft comes up with and in this case it is the artifactid that is incorrect. Also the 8.x metadata records that are split between the old and new namespaces look the same so you'd have to pick one and be wrong with the others.