[FP]: Kotlin runtime libraries detected as JetBrains runtime

[OrangeDog]

Package URl

pkg:maven/org.jetbrains.kotlin/kotlin-parcelize-runtime@1.7.20

CPE

cpe:2.3:a:jetbrains:runtime:1.7.20:*:*:*:*:*:*:*

CVE

CVE-2025-29 903

ODC Integration

{"label" => "Gradle Plugin"}

ODC Version

12.2.2

Description

Above details are just one example. I've gone for this suppression:

<suppress>
    <packageUrl regex="true">pkg:maven/org\.jetbrains\.kotlin/.*</packageUrl>
    <cpe>cpe:/a:jetbrains:runtime</cpe>
</suppress>

[github-actions]

Maven Coordinates

<dependency>
  <groupId>org.jetbrains.kotlin</groupId>
  <artifactId>kotlin-parcelize-runtime</artifactId>
  <version>1.7.20</version>
</dependency>

Suppression rule:

<suppress base="true">
    <notes><![CDATA[
    FP per issue #8668
    ]]></notes>
    <packageUrl regex="true">^pkg:maven/org\.jetbrains\.kotlin/kotlin-parcelize-runtime@.*$</packageUrl>
    <cpe regex="true">cpe:/a:jetbrains:runtime(:.*)?$</cpe>
</suppress>

Link to test results: https://github.com/dependency-check/DependencyCheck/actions/runs/29427119172

[chadlwilson]

Approved

If you want something more generic (or to, like, help), please submit a PR to the generatedSuppressions branch that amends the suppression added here.

[github-actions]

Suppress rule has been added to the generatedSuppressions branch.

[OrangeDog]

@chadlwilson I wasn't sure if you'd be comfortable with my broad pattern.

[chadlwilson]

Well, if there are say 3+ artifacts under that group with runtime in the name sufficient to cause FPs it's probably worth widening the suppression rather than adding them one-by-one. Doesn't seem that risky to conclude that nothing in the kotlin group should match their JRE fork.

[chadlwilson]

No harm starting with an automated suppression and then siding it via a PR anyway. Makes it easy to start with a reviewed example since the automation produces actual evidence (which people would usually omit before the project had the automation, making it take forever to evaluate if it's a bug, config issue etc etc)

[OrangeDog]

Aside: what's the reason for using (:.*)?$ in generated <cpe> elements?

As well as it being equivalent to .*, wouldn't it speed everything up for them to be regex="false"?

[chadlwilson]

#8531 has an approximation of an explanation, but it’s not equivalent to .*. (If there are any chars after the product name, they must be prefixed by a colon)

Basically the goal is to avoid a whole swathe of false negatives from the earlier “generated suppression” approach.

Here’s another summary since it was spread across a few PRs unfortunately.

• Non regex matches are prefix-matched. That creates false negatives because it’d end up suppressing, for e.g, cpe:/a:jetbrains:runtime_kotlin as well as the intended cpe
• if one adds a colon to the end of the prefix match (like we occasionally used to) to ensure the product name matches exactly, the suppression will stop working for certain range-matched vulns where the product version is not explicit
• a fix for this on non-regex matchers is on master, but old versions won’t have this fix, and generatedSuppressions are used by all versions, so we need the rules to be backward compatible for some time.
• so we have to use regex to express that the Cpe either has to have no version at all, or the product name is an “exact match” regardless of version etc.

[OrangeDog]

Oh of course, I was thinking of (?:, but it's (:. Sorry.

[chadlwilson]

Yeah, it’s a bit messy, but figuring out how to change the actual suppression-to-CPEIdentifier rules seemed too sensitive.

Ideally I’d like to understand this stuff better so I can at least fix the ability to express suppressions against extra fields like target_sw including via CPE 2.3, which might be an improvement short of actually correcting all of the core matching logic.

But maybe it’s all moot if the NVD is going to decrease in utility further over time.