grype icon indicating copy to clipboard operation
grype copied to clipboard

Published 20 hours ago • verified publisher icon anchore

Java false positives - netty-reactive-streams, maven-resolver-api, etc

Open mathrock opened this issue 3 years ago • 11 comments

What happened: Various java third-party libraries are incorrectly mapped and compared to the underlying framework/ecosystem. netty-reactive-streams is mapped to netty and maven-resolver-api is mapped to maven CPEs even though they are not directly part of those ecosystems and are versioned independently. There are others, but this is a sampling.

Examples:

  • Latest netty-reactive-streams=2.0.5 (pom), yet it is being treated as netty=2.0.5
  • maven-resolver-api=1.6.3(pom), yet it is being treated as maven=1.6.3

What you expected to happen: No false positives

How to reproduce it (as minimally and precisely as possible):

$ echo "FROM maven:3.8.2-ibmjava-alpine
> RUN mvn dependency:get -Dartifact=com.typesafe.netty:netty-reactive-streams:2.0.5" | docker build -t java-false-positives:netty-reactive-streams - && grype java-false-positives:netty-reactive-streams | egrep "netty-reactive-streams|maven-resolver"
Sending build context to Docker daemon  2.048kB
Step 1/2 : FROM maven:3.8.2-ibmjava-alpine
3.8.2-ibmjava-alpine: Pulling from library/maven
Digest: sha256:dbac210dcbf16f1af8a9b76b1b21a13906c95082bb7729f1ba3e4a4fa0538cd9
Status: Downloaded newer image for maven:3.8.2-ibmjava-alpine
 ---> bc245e67d0e6
Step 2/2 : RUN mvn dependency:get -Dartifact=com.typesafe.netty:netty-reactive-streams:2.0.5
 ---> Using cache
 ---> 993f84c6921c
Successfully built 993f84c6921c
Successfully tagged java-false-positives:netty-reactive-streams
 ✔ Vulnerability DB                [no update available]
 ✔ Loaded image
 ✔ Parsed image
 ✔ Cataloged packages              [266 packages]
 ✔ Scanned image                   [54 vulnerabilities]
maven-resolver-api              1.6.3                       CVE-2021-26291       Critical
maven-resolver-connector-basic  1.6.3                       CVE-2021-26291       Critical
maven-resolver-impl             1.6.3                       CVE-2021-26291       Critical
maven-resolver-spi              1.6.3                       CVE-2021-26291       Critical
maven-resolver-transport-wagon  1.6.3                       CVE-2021-26291       Critical
maven-resolver-util             1.6.3                       CVE-2021-26291       Critical
netty-reactive-streams          2.0.5                       CVE-2014-3488        Medium
netty-reactive-streams          2.0.5                       CVE-2015-2156        High
netty-reactive-streams          2.0.5                       CVE-2019-16869       High
netty-reactive-streams          2.0.5                       CVE-2019-20444       Critical
netty-reactive-streams          2.0.5                       CVE-2019-20445       Critical
netty-reactive-streams          2.0.5                       CVE-2021-21290       Medium
netty-reactive-streams          2.0.5                       CVE-2021-21295       Medium
netty-reactive-streams          2.0.5                       CVE-2021-21409       Medium

Anything else we need to know?: Debug logs from grype showing the matching logic:

[0009] DEBUG searching for vulnerability matches for pkg=Pkg(type=java-archive, name=netty-reactive-streams, version=2.0.5)
[0009] DEBUG found 8 vulnerabilities for pkg=Pkg(type=java-archive, name=netty-reactive-streams, version=2.0.5)
[0009] DEBUG   ├── vuln="CVE-2014-3488" type="Fuzzy Match" searchedBy={"nvd" ["cpe:2.3:a:netty:netty:2.0.5:*:*:*:*:*:*:*"]} foundBy="java-matcher"
[0009] DEBUG   ├── vuln="CVE-2015-2156" type="Fuzzy Match" searchedBy={"nvd" ["cpe:2.3:a:netty:netty:2.0.5:*:*:*:*:*:*:*"]} foundBy="java-matcher"
[0009] DEBUG   ├── vuln="CVE-2019-16869" type="Fuzzy Match" searchedBy={"nvd" ["cpe:2.3:a:netty:netty:2.0.5:*:*:*:*:*:*:*"]} foundBy="java-matcher"
[0009] DEBUG   ├── vuln="CVE-2019-20444" type="Fuzzy Match" searchedBy={"nvd" ["cpe:2.3:a:netty:netty:2.0.5:*:*:*:*:*:*:*"]} foundBy="java-matcher"
[0009] DEBUG   ├── vuln="CVE-2019-20445" type="Fuzzy Match" searchedBy={"nvd" ["cpe:2.3:a:netty:netty:2.0.5:*:*:*:*:*:*:*"]} foundBy="java-matcher"
[0009] DEBUG   ├── vuln="CVE-2021-21290" type="Fuzzy Match" searchedBy={"nvd" ["cpe:2.3:a:netty:netty:2.0.5:*:*:*:*:*:*:*"]} foundBy="java-matcher"
[0009] DEBUG   ├── vuln="CVE-2021-21295" type="Fuzzy Match" searchedBy={"nvd" ["cpe:2.3:a:netty:netty:2.0.5:*:*:*:*:*:*:*"]} foundBy="java-matcher"
[0009] DEBUG   └── vuln="CVE-2021-21409" type="Fuzzy Match" searchedBy={"nvd" ["cpe:2.3:a:netty:netty:2.0.5:*:*:*:*:*:*:*"]} foundBy="java-matcher"


[0009] DEBUG searching for vulnerability matches for pkg=Pkg(type=java-archive, name=maven-resolver-api, version=1.6.3)
[0009] DEBUG found 1 vulnerabilities for pkg=Pkg(type=java-archive, name=maven-resolver-api, version=1.6.3)
[0009] DEBUG   └── vuln="CVE-2021-26291" type="Fuzzy Match" searchedBy={"nvd" ["cpe:2.3:a:apache:maven:1.6.3:*:*:*:*:*:*:*"]} foundBy="java-matcher"
[0009] DEBUG searching for vulnerability matches for pkg=Pkg(type=java-archive, name=maven-resolver-connector-basic, version=1.6.3)
[0009] DEBUG found 1 vulnerabilities for pkg=Pkg(type=java-archive, name=maven-resolver-connector-basic, version=1.6.3)
[0009] DEBUG   └── vuln="CVE-2021-26291" type="Fuzzy Match" searchedBy={"nvd" ["cpe:2.3:a:apache:maven:1.6.3:*:*:*:*:*:*:*"]} foundBy="java-matcher"
[0009] DEBUG searching for vulnerability matches for pkg=Pkg(type=java-archive, name=maven-resolver-impl, version=1.6.3)
[0009] DEBUG found 1 vulnerabilities for pkg=Pkg(type=java-archive, name=maven-resolver-impl, version=1.6.3)
[0009] DEBUG   └── vuln="CVE-2021-26291" type="Fuzzy Match" searchedBy={"nvd" ["cpe:2.3:a:apache:maven:1.6.3:*:*:*:*:*:*:*"]} foundBy="java-matcher"
[0009] DEBUG searching for vulnerability matches for pkg=Pkg(type=java-archive, name=maven-resolver-provider, version=3.8.2)
[0009] DEBUG searching for vulnerability matches for pkg=Pkg(type=java-archive, name=maven-resolver-spi, version=1.6.3)
[0009] DEBUG found 1 vulnerabilities for pkg=Pkg(type=java-archive, name=maven-resolver-spi, version=1.6.3)
[0009] DEBUG   └── vuln="CVE-2021-26291" type="Fuzzy Match" searchedBy={"nvd" ["cpe:2.3:a:apache:maven:1.6.3:*:*:*:*:*:*:*"]} foundBy="java-matcher"
[0009] DEBUG searching for vulnerability matches for pkg=Pkg(type=java-archive, name=maven-resolver-transport-wagon, version=1.6.3)
[0009] DEBUG found 1 vulnerabilities for pkg=Pkg(type=java-archive, name=maven-resolver-transport-wagon, version=1.6.3)
[0009] DEBUG   └── vuln="CVE-2021-26291" type="Fuzzy Match" searchedBy={"nvd" ["cpe:2.3:a:apache:maven:1.6.3:*:*:*:*:*:*:*"]} foundBy="java-matcher"
[0009] DEBUG searching for vulnerability matches for pkg=Pkg(type=java-archive, name=maven-resolver-util, version=1.6.3)
[0009] DEBUG found 1 vulnerabilities for pkg=Pkg(type=java-archive, name=maven-resolver-util, version=1.6.3)
[0009] DEBUG   └── vuln="CVE-2021-26291" type="Fuzzy Match" searchedBy={"nvd" ["cpe:2.3:a:apache:maven:1.6.3:*:*:*:*:*:*:*"]} foundBy="java-matcher"

Environment:

  • Output of grype version:
$ grype version
Application:          grype
Version:              0.20.0
Syft Version:         v0.24.0
BuildDate:            2021-09-23T02:11:21Z
GitCommit:            1a7c9d177904756b820cea1044c8a5c452d8a4c3
GitTreeState:         clean
Platform:             linux/amd64
GoVersion:            go1.16.8
Compiler:             gc
Supported DB Schema:  3
  • OS (e.g: cat /etc/os-release or similar):
$ cat /etc/os-release
NAME="Red Hat Enterprise Linux Server"
VERSION="7.9 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.9"
PRETTY_NAME="Red Hat Enterprise Linux Server 7.9 (Maipo)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.9:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.9
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.9"

mathrock avatar Sep 27 '21 18:09 mathrock

Hi @mathrock thanks for reporting the issue!

I've taken a look at reproducing the issue you find and I've successfully done so. I built the same image and instead of running grype directly on the image, I ran syft first to see what was coming back for each package (syft is the cataloging mechanism that grype uses before it tries to match vulnerabilities, and is also what generates CPEs for each package)

This is the truncated output that syft provides for the netty-reactive-streams package:

{
   "id": "84130733655414363",
   "name": "netty-reactive-streams",
   "version": "2.0.5",
   "type": "java-archive",
   "foundBy": "java-cataloger",
   "locations": [
    {
     "path": "/root/.m2/repository/com/typesafe/netty/netty-reactive-streams/2.0.5/netty-reactive-streams-2.0.5.jar",
     "layerID": "sha256:9204bc850dfa1335935ebe252dd78d0101e17f94d368230a6ba5f5dfc0430eb6"
    }
   ],
   "licenses": [],
   "language": "java",
   "cpes": [
    "cpe:2.3:a:netty-reactive-streams:netty-reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-reactive-streams:netty_reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_reactive_streams:netty-reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_reactive_streams:netty_reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-reactive-streams:reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-reactive-streams:reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_reactive_streams:reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_reactive_streams:reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactive-streams:netty-reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactive-streams:netty_reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactive_streams:netty-reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactive_streams:netty_reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-reactive:netty-reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-reactive:netty_reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_reactive:netty-reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_reactive:netty_reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactive-streams:reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactive-streams:reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactive_streams:reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactive_streams:reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-reactive:reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-reactive:reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_reactive:reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_reactive:reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactive:netty-reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactive:netty_reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:typesafe:netty-reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:typesafe:netty_reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-reactive-streams:netty:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty:netty-reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty:netty_reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_reactive_streams:netty:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactive:reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactive:reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:typesafe:reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:typesafe:reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty:reactive-streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty:reactive_streams:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactive-streams:netty:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactive_streams:netty:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-reactive:netty:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_reactive:netty:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactive:netty:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:typesafe:netty:2.0.5:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty:netty:2.0.5:*:*:*:*:*:*:*"
   ],
...

I can see that syft is in fact generating a CPE that's too generic for the package: cpe:2.3:a:netty:netty:2.0.5:*:*:*:*:*:*:*

For now, I'll just confirm that this DOES look like a false positive. I'll try and figure out why syft is generating that particularly generic CPE next.

dakaneye avatar Nov 10 '21 10:11 dakaneye

Upon closer inspection it looks like this CPE is being generated here: https://github.com/anchore/syft/blob/main/syft/pkg/cataloger/common/cpe/java.go.

It appears that this code is generating the possible vendors and product names from the package group IDs and artifact IDs. This can come from the pom.xml or the manifest itself (jar file) as far as I can tell.

If there's a way to make this more specific in this case I'm not sure... @wagoodman @luhring not sure if you know any way we can filter this generic case out!

dakaneye avatar Nov 10 '21 11:11 dakaneye

@dakaneye Yeah that's a good question. To me, this is the same category of false positive as #450, where our string manipulation during CPE generation ends up producing matches against larger projects. We'll need to think on the best way to handle this. 🤔

luhring avatar Nov 10 '21 12:11 luhring

Still related to netty, I get the following false positives on a docker image containing spring-boot-starter-webflux which includes reactor-netty-http.

reactor-netty-http  1.0.13               CVE-2014-3488   Medium    
reactor-netty-http  1.0.13               CVE-2015-2156   High      
reactor-netty-http  1.0.13               CVE-2019-16869  High      
reactor-netty-http  1.0.13               CVE-2019-20444  Critical  
reactor-netty-http  1.0.13               CVE-2019-20445  Critical  
reactor-netty-http  1.0.13               CVE-2021-21290  Medium    
reactor-netty-http  1.0.13               CVE-2021-21295  Medium    
reactor-netty-http  1.0.13               CVE-2021-21409  Medium    
reactor-netty-http  1.0.13               CVE-2021-37136  High      
reactor-netty-http  1.0.13               CVE-2021-37137  High

All of these are fixed along with netty 4.1.70 (dependency of 1.0.13 above)

Debug info:

Application:          grype
Version:              0.24.1
Syft Version:         v0.29.0
BuildDate:            2021-11-05T16:53:26Z
GitCommit:            00aa7d452348cdd1a94b25a78d0d04c6ff3fff6d
GitTreeState:         clean
Platform:             darwin/amd64
GoVersion:            go1.16.9
Compiler:             gc
Supported DB Schema:  3

Georgian avatar Nov 11 '21 10:11 Georgian

Same here, current spring-boot-starter-webflux brings in reactor-netty-http and reactor-netty-core 1.0.15, which use netty 4.1.73.Final, but get matched to netty based on their own version 1.0.15:

  {
   "id": "87a213cb3e5ec4f0",
   "name": "reactor-netty-http",
   "version": "1.0.15",
   "type": "java-archive",
   "foundBy": "java-cataloger",
   "locations": [
    {
     "path": "/app/libs/reactor-netty-http-1.0.15.jar",
     "layerID": "sha256:69b8548806d85d46963ddc586d1324d59d39cc11ec86c86d4c338bbcc9ad20ca"
    }
   ],
   "licenses": [],
   "language": "java",
   "cpes": [
    "cpe:2.3:a:reactor-netty-http:reactor-netty-http:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactor-netty-http:reactor_netty_http:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactor_netty_http:reactor-netty-http:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactor_netty_http:reactor_netty_http:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:projectreactor:reactor-netty-http:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:projectreactor:reactor_netty_http:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactor-netty:reactor-netty-http:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactor-netty:reactor_netty_http:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactor_netty:reactor-netty-http:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactor_netty:reactor_netty_http:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactor:reactor-netty-http:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactor:reactor_netty_http:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty:reactor-netty-http:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty:reactor_netty_http:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactor-netty-http:netty:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactor_netty_http:netty:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:projectreactor:netty:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactor-netty:netty:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactor_netty:netty:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:reactor:netty:1.0.15:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty:netty:1.0.15:*:*:*:*:*:*:*"
   ],
   ...
  }

I don't know exactly what kind of information syft has in its Java matcher, but I think part of the problem is that the various actual netty dependencies of reactor-netty-core and reactor-netty-http are not matched to cpe:2.3:a:netty:netty, e.g.:

{
   "name": "netty-codec-http",
   ...
   "cpes": [
    "cpe:2.3:a:netty-codec-http:netty-codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-codec-http:netty_codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_codec_http:netty-codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_codec_http:netty_codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-project:netty-codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-project:netty_codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_project:netty-codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_project:netty_codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-codec:netty-codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-codec:netty_codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_codec:netty-codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_codec:netty_codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:codec-http:netty-codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:codec-http:netty_codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:codec_http:netty-codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:codec_http:netty_codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-codec-http:codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-codec-http:codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_codec_http:codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_codec_http:codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-project:codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-project:codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_project:codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_project:codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:codec:netty-codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:codec:netty_codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-codec:codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty-codec:codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty:netty-codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty:netty_codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_codec:codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty_codec:codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:codec-http:codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:codec-http:codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:codec_http:codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:codec_http:codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:codec:codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:codec:codec_http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty:codec-http:4.1.73.Final:*:*:*:*:*:*:*",
    "cpe:2.3:a:netty:codec_http:4.1.73.Final:*:*:*:*:*:*:*"
   ],
   ...
}

Otherwise it might have been an option not to add "fuzzy" cpes to a package if an equivalent, but more specific cpe already exists in one of its dependencies. E.g. in this case, a "cpe:2.3:a:netty:netty:4.1.17.Final on io.netty:netty-codec-http 4.1.17 could override the fuzzy match from reactor-netty-http, which depends on it.

creckord avatar Feb 25 '22 13:02 creckord

Followup question: Is it possible to exclude a cpe match via .grype.yaml, e.g. something along the lines of

ignore:
  - package:
      name: reactor-netty-http
      cpe: cpe:2.3:a:netty:netty:*

I know can ignore this particular CVE for reactor-netty-http, but I would consider any netty:netty match on this package a false positive, and it would be great to be able to express that...

creckord avatar Feb 25 '22 13:02 creckord

Any update on this? At this point we switched back to legacy engine, because there is just too many false positives...

wimi avatar Mar 11 '22 08:03 wimi

@wimi - What version did you pick to go back to?

seanleblancicdtech avatar Mar 11 '22 16:03 seanleblancicdtech

@wimi - What version did you pick to go back to?

Apologies for confusion - I am actually referring to main Anchore scanner (https://github.com/anchore/anchore-engine), which is now using grype as main scan engine by default. There is an option to use a legacy engine, which does not have this issue.

wimi avatar Mar 11 '22 16:03 wimi

It looks like the analysis from @dakaneye and @creckord is right. We'll need to adjust our logic to produce less broad CPEs.

Is it possible to exclude a cpe match via .grype.yaml ...

Today you can't ignore matches by package CPE, but that's an interesting idea. For now, you'd need to specify ignore rules for each vulnerability, which I realize could be cumbersome.

luhring avatar Mar 25 '22 12:03 luhring

Today you can't ignore matches by package CPE, but that's an interesting idea. For now, you'd need to specify ignore rules for each vulnerability, which I realize could be cumbersome.

Actually, excluding a vulnerability by package CPE would be nice, too. But I was talking about excluding an artifact match from a CPE. In this case, I would like to say that "name": "reactor-netty-http", "type": "java-archive" is never, ever a match for "cpe:2.3:a:netty:netty:*:*:*:*:*:*:*:*"

I found this a highly useful feature that e.g. the OWASP Dependency Scanner has in their rather extensive suppression specification. I frequently use it to disentangle client libs from server vulnerabilities.

creckord avatar Apr 04 '22 15:04 creckord

FYI, it's still an issue in the latest version of Grype

guizmaii avatar Feb 01 '23 05:02 guizmaii

Hi @guizmaii, thanks for letting us know. We understand the root cause of this problem and it's something we are working on fixing--I'll leave this open for tracking until we have a solution. Thanks!

tgerla avatar Feb 02 '23 21:02 tgerla

Is there something we can do to help testing? These false-positives around reactor-netty-* are hitting us in quite some Java and Scala projects - we applied updates, yet still get back a ton of vulnerabilities 😅

harmw avatar Feb 21 '23 08:02 harmw

Hello all, we have made some recent changes to the way that Grype matches vulnerabilities. These Java-related false positives should all be fixed now. Please see this blog post for more detail and rationale for the changes: https://anchore.com/blog/say-goodbye-to-false-positives/

I'll go ahead and close this issue but if you run into any more false positives, please open a new issue and we would be happy to look. Thanks for your patience!

tgerla avatar Nov 30 '23 19:11 tgerla