anyone know how to fix the following CVE kotlinx-s...

# server

[Alfy]

anyone know how to fix the following CVE kotlinx-serialization-core-jvm-1.3.2.jar: CVE-2020-29582, CVE-2019-10102, CVE-2019-10101, CVE-2019-10103?

[Alfy]

That's the latest version.

[Sam]

I believe it could be a false positive warning

[Sam]

A lot of the CPEs match things under kotlinx when they should really only match kotlin

[Sam]

For example CVE-2020-29582 says "In JetBrains Kotlin before 1.4.21...". So the CPE is supposed to match all the org.jetbrains.kotlin with versions less than 1.4.21. The org.jetbrains.kotlinx packages shouldn't be matched, because they're separate libraries and not part of the Kotlin versioning scheme.

[Sam]

I'm not sure if it's the CPE itself which is wrong, or the tooling which is used to check for matches.

[Sam]

In my projects I've added a suppression rule so that cpe:/a:jetbrains:kotlin is suppressed for org.jetbrains.kotlinx

[Richard Gomez]

@Alfy can I ask which tool or source you're using to detect these?

• CVE-2020-29582: kotlinx-serialization 1.3.2 doesn't have an explicit dependency on kotlin <1.4.21, so it is indeed a false positive.
• CVE-2019-10102: That's for ktor and not kotlinx.serialization
• CVE-2019-10101: For kotlin < 1.3.30
• CVE-2019-10103: The IDEA kotlin template (?)

[Alfy]

I think I'll go with supressing them, seems like a false postive

[Alfy]

@Richard Gomez we're using sonarcloud

[Alfy]

@Sam thanks!

[Richard Gomez]

In my experience, SonarQube isn't very useful for CVEs. Something like Snyk or Nexus IQ is much better, albeit paid.

[Alfy]

I propose snyk to my team, and we're currently thinking about it

[Richard Gomez]

The root cause in a lot of causes is, as Sam mentioned before, CPEs. It's a terrible format/specification and most CPEs seem like lazy guess work at best. For example, the CPE for CVE-2021-44228 is `cpe2.3aapachelog4j2.0-::*:*:*:*:*`,* but the actual affected package was org.apache.logging.log4j:log4j-core.

Tools like Snyk, Nexus IQ, or Jfrog Xray are backed by actual security research teams that not only review the advisories, but translate them to the appropriate affected packages. Tools like SonarQube just dump the NVD feed into your project and make you figure out whether it's a false positive or not.

There was a specification created called "Package URL" that was intended to fix the issue. Instead, it seems like NIST went with "SWID" tags, which IMO are just as confusing and bad as CPEs.

[Alfy]

lol did not know about that.. still new at this.

[Alfy]

Thank you for the explanation @Richard Gomez