False positive on Artifactory ruby gem

[isuftin]

What happened:

Grype is hitting a false positive on the "artifactory" ruby gem which has the latest version of 3.0.15 ( https://rubygems.org/gems/artifactory/versions/2.3.2 ) - I am assuming it thinks that this is the JFrog Artifactory software installation?

NAME            INSTALLED               FIXED-IN                                                                              TYPE  VULNERABILITY        SEVERITY   
artifactory     3.0.15                  4.16                                                                                  gem   CVE-2016-10036       Critical    
artifactory     3.0.15                  6.18                                                                                  gem   CVE-2019-19937       High        
artifactory     3.0.15                  6.7.8, 5.11.8, 6.1.6, 6.3.9                                                           gem   CVE-2020-7931        High        
artifactory     3.0.15                  7.25.4, 7.24.7, 7.23.8, 7.21.14, 7.19.12, 7.18.11, 7.17.14, 7.12.10, 7.11.8, 6.23.30  gem   CVE-2021-3860        High        
artifactory     3.0.15                  6.17.0                                                                                gem   CVE-2019-17444       Critical    
artifactory     3.0.15                  7.28.0, 6.23.38                                                                       gem   CVE-2021-41834       Medium 

What you expected to happen:

No false positive

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

An example of the Chef Development Kit Docker image we build and is failing the scan:

FROM ubuntu:20.04

ENV CHANNEL=stable
ENV DEBIAN_FRONTEND=noninteractive
ENV PATH=/opt/chef-workstation/bin:/opt/chef-workstation/embedded/bin:/root/.chefdk/gem/ruby/2.7.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

WORKDIR /

COPY requirements.txt .

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    python3.8=3.8* \
    python3-distutils=3.8* \
    wget=1.20.3* \
    curl=7.68.0* \
    openssl=1.1.1f* \
    zlib1g=1:1.2.11.dfsg-2ubuntu1.3 \
    git=1:2.25* && \
    \
    wget -q  https://bootstrap.pypa.io/get-pip.py -O  get-pip.py && \
    python3.8 get-pip.py && \
    rm get-pip.py && \
    python3 -m pip install --no-cache-dir -r requirements.txt && \
    wget -q --content-disposition "http://packages.chef.io/files/${CHANNEL}/chef-workstation/${MINOR_VERSION}/ubuntu/20.04/chef-workstation_22.7.1006-1_amd64.deb" -O /tmp/chef-workstation.deb && \
    dpkg -i /tmp/chef-workstation.deb && \
    rm /tmp/chef-workstation.deb && \
    \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* /var/log/*log /var/log/apt/* /var/lib/dpkg/*-old /var/cache/debconf/*-old && \
    \
    useradd --system --create-home --shell /bin/bash --uid 1001 chef && \
    \
    chef -v

USER chef

Just for completeness sake, requirements.txt:

certifi==2022.6.15
charset-normalizer==2.1.0
idna==3.3
pychefrevival==0.3.1
requests==2.28.1
six==1.16.0
urllib3==1.26.9

Anything else we need to know?:

• Output of grype version:

Application:          grype
Version:              0.47.0
Syft Version:         v0.54.0
BuildDate:            2022-08-17T20:00:45Z
GitCommit:            08b4ef493b36a65f6149c9092d083d5d57540cdc
GitDescription:       v0.47.0
Platform:             linux/amd64
GoVersion:            go1.18.5
Compiler:             gc
Supported DB Schema:  4

• OS (e.g: cat /etc/os-release or similar):

This is being run on a GitLab runner within a Docker image we create for Grype using alpine:3.16

[isuftin]

I think this is related to #244

[kzantow]

Thanks for reporting this @isuftin ! We are currently evaluating approaches to reduce false positive matches like this - namely CVEs mismatching on CPEs. Unfortunately this isn't a trivial problem to solve, but we some paths forward we're exploring.

[willmurphyscode]

Hi @isuftin,

Thanks for the report! This sort of ecosystem confusion is caused by using CPEs from NVD as a matching source, because CPEs don't include language/ecosystem information, and so are liable to this type of confusing artifacts from one ecosystem with another.

In order to prevent this type of false positive, Grype now uses GHSA data matching by PURLs by default for language ecosystem packages that support it. I believe this has fixed this type of false positive (though I'm no longer able to build that Dockerfile, so I can't check for sure.)

You can read more about the switch to GHSA at our blog post: https://anchore.com/blog/say-goodbye-to-false-positives/

I'm closing this, since I believe it's fixed, but please let me know if I've missed something.