False Positive on any artifact with an ID or group ID that contains the name of a vulnerable library

[mikaelcarlstedt]

Looks like something has happened to the library pattern matching recently.

Example:

False positive CVE-2005-2311 on one of our internal library dependencies - reported as cpe:2.3:a:sms:sms:0.1.0:snapshot:*:*:*:*:*:*

<dependency>
  <groupId>com.sinch.sms</groupId>
  <artifactId>msisdn-validation-management-api</artifactId>
  <version>0.1.0-SNAPSHOT</version>
</dependency>

Same thing with another internal library named ha-scheduled-message-grpc, which was reported to contain an old vulnerability in GRPC library from 2017.

[theHilikus]

Not sure if this is the same issue but we also noticed recent builds crashing (on Dec1 things were building, on Dec2 things started crashing) due to old CVEs, including GRPC libraries with CVEs from 2017

[ERROR] opencensus-contrib-grpc-util-0.24.0.jar: CVE-2017-8359, CVE-2017-7861, CVE-2017-9431, CVE-2017-7860
[ERROR] proto-google-cloud-firestore-v1beta1-0.88.1.jar: CVE-2017-8359, CVE-2017-7861, CVE-2017-9431, CVE-2017-7860
[ERROR] proto-google-cloud-logging-v2-0.84.2.jar: CVE-2017-8359, CVE-2017-7861, CVE-2017-9431, CVE-2017-7860
[ERROR] proto-google-iam-v1-0.13.0.jar: CVE-2017-8359, CVE-2017-7861, CVE-2017-9431, CVE-2017-7860
[ERROR] 
[ERROR] See the dependency-check report for more details.

[mikaelcarlstedt]

@theHilikus That first filename containing grpc indicates it's the same issue.

[stevehipwell]

@jeremylong are you seeing this as an issue or expected behaviour?

[jeremylong]

@stevehipwell this is expected behavior. See How dependency-check works. I've cleaned up the ones I could - a better solution for grpc is likely needed.

[stevehipwell]

@jeremylong I've read how this works but I'm unsure as to if the expected behaviour is for a lib whos name contains another lib name to be identified as this often unrelated lib. For example unless a postgres driver has a version over 9.x it's constantly flagged as vulnerable against postgres. The most common ones are things like grpc, json, xml, etc.

[jeremylong]

expected behavior - use suppression rules.

[Chr1stian]

@jeremylong What is a good way to write a suppression rule that ignores the warnings related to grpc version, but still will warn about any new OWASP positives for the given package/dependency?

My current attempt after reading the docs/wiki, but really unsure if it works as intended:

<suppress>
        <notes><![CDATA[
        This suppresses false positives identified on gRPC security. https://github.com/jeremylong/DependencyCheck/issues/2995
        ]]></notes>
        <packageUrl regex="true">^pkg:maven/com\.lightbend\.akka\.grpc/akka\-grpc\-runtime_2\.13@.*$</packageUrl>
        <cpe>cpe:/a:akka:akka</cpe>
        <cpe>cpe:/a:grpc:grpc</cpe>
        <cpe>cpe:/a:lightbend:akka</cpe>
        <cpe>cpe:/a:lightbend:akka-http</cpe>
        <cpe>cpe:/a:lightbend:akka_http</cpe>
    </suppress>

[FyiurAmron]

@Chr1stian & @mikaelcarlstedt

Looking at the suppressions, I see that we simply need:

    <suppress base="true">
        <notes><![CDATA[
        FPs from #2995 (grpc)
        ]]></notes>
        <packageUrl regex="true">^pkg:maven\/(?!io.grpc\/).*$</packageUrl>
        <cpe>cpe:/a:grpc:grpc</cpe>
    </suppress>
    <suppress base="true">
        <notes><![CDATA[
        FPs from #2995 (sms)
        ]]></notes>
        <packageUrl regex="true">^pkg:maven\/.*$</packageUrl>
        <cpe>cpe:/a:sms:sms</cpe>
    </suppress>

note for sms - that one is due to https://bugs.gentoo.org/97187 ; it's 20 years old and no maven package exists that physically can have it, thus an umbrella suppression for pkg:maven can be added.

BTW this pattern (negative regex) has been used some times already ( here , here , here etc. etc.)

I created #7250 & #7251 for reference, though I see the CI bot chokes on FP reports created with regexes :}