dependency-track: CPE matching: Fix false positives due to wildcard (*) in Component CPE

Great, thanks for clarifying. I think we’re in line then. Let me finish the work on this over the coming days, I can provide a container image again that you can use to verify if everything looks good from your side.

Ok, so I did lots of testing over the weekend, and I’m not convinced that enforcing the minimum requirements is a good idea. There are just too many legitimate cases of mixed SUBSET and SUPERSET relationships.

Most prominently, the case mentioned in https://github.com/DependencyTrack/dependency-track/issues/3178#issuecomment-1815155611 is super common. CPEs with version range always have version set to ANY. Which means you’re pretty much guaranteed to encounter SUBSET relationships during matching. This isn’t even a NVD data quality issue, it’s how the NVD has always used version ranges.

@Jasper-Ben Using the BOM you shared in https://github.com/DependencyTrack/dependency-track/pull/1929#issuecomment-1759423518, I only get 23(!) vulns when enforcing the minimum requirement for matching. It just discards too many valid matches.

To deal with the specific problem in this issue, I’m thinking to add these additional checks to the existing matching logic:

• If comparison of vendor yields SUBSET, and comparison of product yields SUPERSET, then it’s a no-match
• If comparison of vendor yields SUPSERSET, and comparison of product yields SUBSET, then it’s a no-match

Essentially implementing https://github.com/DependencyTrack/dependency-track/issues/3146#issuecomment-1782651142, as a damped-down enforcement of minimum required matching.

---

@Jasper-Ben I pushed a container image with my changes:

docker pull dependencytrack/apiserver:3178-fix-cpe-matching

For testing, it will emit a WARN log when it discards matches based on the criteria described above. Example:

2023-11-19 19:05:15,160 WARN [InternalAnalysisTask] cpe:2.3:*:*:zstandard:1.5.2:*:*:*:*:*:*:*: Dropped match with cpe:2.3:h:amd:*:*:*:*:*:*:*:*:* due to ambiguous vendor/product relation
2023-11-19 19:05:15,161 WARN [InternalAnalysisTask] cpe:2.3:*:*:zstandard:1.5.2:*:*:*:*:*:*:*: Dropped match with cpe:2.3:a:pascom_cloud_phone_system:*:*:*:*:*:*:*:*:* due to ambiguous vendor/product relation
2023-11-19 19:05:15,161 WARN [InternalAnalysisTask] cpe:2.3:*:*:zstandard:1.5.2:*:*:*:*:*:*:*: Dropped match with cpe:2.3:h:intel:*:*:*:*:*:*:*:*:* due to ambiguous vendor/product relation

but then when I looked at how GitHub recognizes that just now I see I’m irrelevant.

@officerNordberg This may be related to you pushing commits using a different email address than what is configured in your GitHub profile. GitHub is unable to make the connection between the two when generating the contributor stats.

On topic: I’ll schedule this for 4.11. 4.10 is supposed to go out this week or next at the latest. I’m expecting 4.11 to follow closely, as we look to shorten release cycles.

I have some ideas for the discussed VEX use case that I need to write down in a separate issue. There is overlap with ingestion of VDRs, which we also want to support. Processing embedded VEX / VDR is definitely something DT must support.

Please keep the feedback coming, although of course contributions would be very welcome as well. 😃

Jup, with all due respect for the DT devs

I was going to say “hey, I get it, I’m one of them, or at least a contributor” but then when I looked at how GitHub recognizes that just now I see I’m irrelevant. 👎 Oh well. So much for my efforts.

FWIW this is the VEX document we currently apply as a workaround for this issue:

vex-false-positives.json