CPE Name Matching: CPE name relation being SUBSET(⊂) should be a match

[Jasper-Ben]

Current Behavior

Currently, DT will only consider CPE name matching a "match", if the CPE name relation is SUPERSET (⊃) or when CPE name relation is EQUAL (=). However, to avoid false negatives a SUBSET relation (⊂) MUST also be treated as a match.

To understand this, we need to take a closer look at the NIST name matching specification, especially at table 6-2.

Here we see that there are exactly 3 cases in which a SPE attribute relation is a SUBSET: 3, 13, 15

Keeping in mind that the CVE CPE is the source CPE and the component CPE is the target CPE, let's take a closer look at what these three cases really mean:

case 5 example:

source: cpe:2.3:o:linux:linux_kernel:5.15.37:*:*:*:*:*:*:NA
target: cpe:2.3:o:linux:linux_kernel:5.15.37:*:*:*:*:*:*:*

We have a CVE CPE where the "Other" attribute is "Not applicable" and the component attribute for "Other" is "ANY". Why should the CVE not apply to the target component? Since "ANY" is a superset of "NA" (as proven in case 2), this should still match.

case 13 example:

source: cpe:2.3:o:linux:linux_kernel:5.15.37:*:*:*:*:*:x86:*
target: cpe:2.3:o:linux:linux_kernel:5.15.37:*:*:*:*:*:*:*

We have a CVE CPE where the "Target_HW" attribute is "x86" and the component attribute for "Target_HW" is "ANY". Why should the CVE not apply to the target component? Sure, it could be a false positive, if the component actually only runs on arm64, but that is up to the component to provide as accurate information as possible in order to prevent false positives. If however the component actually runs on a x86, a no-match would definitely be a false negative.

case 15 example:

source: cpe:2.3:o:linu*:linux_kernel:5.15.37:*:*:*:*:*:*:*
target: cpe:2.3:o:*:linux_kernel:5.15.37:*:*:*:*:*:*:*

We have a CVE CPE where the "Vendor" attribute contains a wildcard (the example is a bit contrived, I know) and the component attribute for "Vendor" is "ANY". Again, why should this not be a CVE match? Sure, it could again be a false positive but that is for the auditor to decide. It should not end up as false negative.

As such, cases 2-4 from table 6-4 should be a match:

Related to #2580, #2994

Steps to Reproduce

1. Create a component with CPE cpe:2.3:*:linux:linux_kernel:5.15.37:*:*:*:*:*:*:* (make sure to disable fuzzy matching for CPE)
2. This will show 0 CVE matches, with false negatives, as the "Part" attribute was empty.

Expected Behavior

The component should show correct matches + X potential false positives, e.g. since there there was no Target_HW for the component defined.

False positives are bad (that's why accurate component CPE data matters), false negatives are way worse.

Dependency-Track Version

4.8.1

Dependency-Track Distribution

Container Image

Database Server

PostgreSQL

Database Server Version

No response

Browser

N/A

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this defect was already reported

[syalioune]

Hello @Jasper-Ben
There's an ongoing discussion here #1929 that relates to this one.
I suggest you chime in to give your inputs/case for maintainers with more background/expertise on CPE matching to make the decision 😄

[Jasper-Ben]

@syalioune thanks for the link, will do! 🙂

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.