Match CPEs is nondeterministic

[getvictor]

Fleet version:
4.80.2

---

💥 Actual behavior

The CPE matching algorithm produces nondeterministic results for the "Line" messaging app. The NVD CPE database contains two products whose names contain "line": ge:d60_line_distance_relay (a GE industrial relay) and linecorp:line (the LINE messaging app). Both pass the cpeItemMatchesSoftware check because the term "line" appears in the software name.

Since SQLite does not guarantee row ordering among equally-qualifying rows, the algorithm returns whichever match SQLite happens to return first. This means the same software can be assigned different CPEs across runs, leading to inconsistent vulnerability detection results.

Observed in QA testing: 14 software entries for the Line app were assigned ge:d60_line_distance_relay in one run and linecorp:line in another, with identical input data.

🛠️ To fix

Add a deterministic tiebreaker when multiple CPE candidates pass the cpeItemMatchesSoftware check. Options include:

1. Prefer exact vendor match: If the software's vendor field matches one candidate's vendor exactly, prefer that candidate.
2. Add ORDER BY to the query: Add ORDER BY c.vendor, c.product to ensure consistent ordering across runs.
3. Score-based ranking: Weight matches higher when the vendor term appears in the software's vendor field (not just the name).

🧑‍💻 Steps to reproduce

These steps:

• Have been confirmed to consistently lead to reproduction in multiple Fleet instances.

1. Ensure hosts have the "Line" messaging app installed (any version, e.g., 3.5.1 on Chrome or 4.3.1 on macOS).
2. Run fleet vuln_processing --dev and query the resulting CPE:

   SELECT s.id, s.name, s.version, sc.cpe
   FROM software s JOIN software_cpe sc ON s.id = sc.software_id
   WHERE s.name LIKE '%line%' AND sc.cpe LIKE '%line%';

3. Clear software_cpe and run fleet vuln_processing --dev again.
4. Compare the CPE values; they MAY differ between runs (ge:d60_line_distance_relay vs linecorp:line).

🕯️ More info

QA

This is hard to QA. We have another bug that fixes the bigger issue here: #41644

For this one, just spot check vulnerabilities for any regressions.

[getvictor]

Jacob's estimate:
If option 1 works i.e. the vendor field can be correctly matched on, 3
If option 2: 2
Option 3: 3

[getvictor]

Let's go with option 1 for now.

Agreed on 3. Need to do a CVE before/after comparison.