fix(fp): convert hosted/generated suppressions to conservative regex prefix matchers

[chadlwilson]

Description of Change

As discovered myself in #8521 (comment) unfortunately my change in #8510 caused some unintentional regression of suppression applicability for hosted suppressions, since the trailing bits of the CPE are removed for vulnerabilities without versions in them (typically ones with startsWith/endsWith ranges at NVD such as https://nvd.nist.gov/vuln/detail/CVE-2025-15104)

The existing code does not normalise the suppression rule CPE URI from the suppressions before comparing the string representation prefix. This means vulns with affected versions like cpe:2.3:a:validator:validator:*:*:*:*:*:* will no longer match as they are correctly normalized by the code to cpe:/a:validator:validator without a trailing : before matching to the prefix rule. I'd forgotten about this CPE 2.2 vs 2.3 difference :-(

This change converts them to regexes - so it's possible to express the matching across ODC versions. An alternative would be to just revert things and leave the false negative possibilities.

• It's probably not great (complexity, readability, performance) to have to do regex matching everywhere here, however since hosted suppressions are supported across older versions, the alternative would leave us stuck without consistent conservative matching, as requires code change to fix.
• Happy to take feedback though - WDYT @jeremylong @marcelstoer?
• I'll follow up with a "fix" of some sort on master as well once we've agreed approach; to improve the non-regex matching; and/or to improve the regex matching speed.

Related issues

• caused [FP]: isorelax (via msv group) being misattributed as Nu HTML Checker/validator #8521
• caused by chore(fp): convert hosted/generated suppressions to more conservative CPE prefix suppressions #8510

Have test cases been added to cover the new functionality?

no

[chadlwilson]

Sorry forgot to tag @nhumblot for feedback 🙏🏻

We might get a swathe of FP reports today because of my mistake here. I'll handle them if so.

[jeremylong]

LGTM

[chadlwilson]

Sorry for the hassle. 😓

[chadlwilson]

@jeremylong unfortunately #8516 didn’t seem to lead to the publish workflow being triggered.

https://github.com/dependency-check/DependencyCheck/actions?query=workflow%3A%22Publish%20Suppressions%22

would you be able to trigger the workflow manually for now so we can get the fix out?

[ArkanEPITA]

Hello,

Since the new way of handling the packageUrl with regex, the matching seems to be incrorrect. The package "pkg:maven/org.hibernate.validator/hibernate-validator@8.0.2.Final" should be matched by the following suppression in the generatedSuppression file:

<suppress base="true">
    <notes><![CDATA[
    FP per issue #8243, #8244, #8247, #8249
    ]]></notes>
    <packageUrl regex="true">^pkg:(?!maven/nu\.validator/validator@|npm/vnu-jar)(:.*)?$</packageUrl>
    <cpe regex="true">cpe:/a:validator:validator(:.*)?$</cpe>
</suppress>

Yet, the CVE-2025-15104 still fails the check.

The packageUrl regex changed from ^pkg:(?!maven/nu\.validator/validator@|npm/vnu-jar).* to ^pkg(?!:maven\/nu\.validator\/validator@|npm\/vnu-jar)(:.*)?$ here

Other package url doesnt seem to be touched (I didnt check each of them though).

Reading the comment on this issue and the linked one, I don't know why pkgUrl matching changed as the topic seems to be around cpe matching. Is it an oversight ?

• AFAIK, the package URL spec doesnt specify multiple "semi-colon followed by char" sequences and only a semi-colon after the pkg scheme. So I don't know what this commit tried to achieve there.

[chadlwilson]

See #8525 for the fix (already linked above) - apologies for the hassle.

[chadlwilson]

None of these suppression rules have any automated tests whatsoever, so occasionally screw ups will happen, unfortunately (including systemic issues such as the widespread false negatives that this PR and #8510 are attempting to fix for the <cpe> matchers)

[chadlwilson]

Copilot would probably have caught this, but I forgot to ask it for review. Oops.

[ArkanEPITA]

Right ! Have not seen that, thanks a lot :)