Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Grype is catching a false positive on spring-boot-starter-web because it cannot detect inherited version from parent #1012

Open
cezapata opened this issue Nov 22, 2022 · 7 comments · May be fixed by #2110
Labels
bug Something isn't working false-positive

Comments

@cezapata
Copy link

What happened:
After using the Spring Initializer tool to create a new Spring Boot App (version 2.7.5) with the Spring Web dependency, building, and running Grype to scan for vulnerabilities, we get a vulnerability detected on the following package:

spring-boot-starter-web: GHSA-36p3-wjmg-h94x

image

What you expected to happen:

When installing the dependencies, the spring-boot-starter-web package installs a version that is consistent with its parent artifact (spring-boot-starter-parent) which maps to version 2.7.5

I was expecting grype to detect the version, and note that the vulnerability it indicates does not apply since it was fixed as a prior version (2.5.12). However, the engine does not pick it up, and displays an empty version in use for the package:

image

How to reproduce it (as minimally and precisely as possible):
I have set up a repo with a dev container configured to run the repro with instructions here:

https://github.com/cezapata/appconfiguration-sample

You can run the codespace, install the maven dependencies on the app, and then run grype. Among the vulnerabilities detected, we will display GHSA-36p3-wjmg-h94x.

Anything else we need to know?:

Hard-coding the version on the dependencies fixes the problem, but we would like all the dependencies to be controlled by the parent.

Environment:

  • Output of grype version:
    Application: grype
    Version: 0.53.0
    Syft Version: v0.62.0
    BuildDate: 2022-11-18T20:36:40Z
    GitCommit: a4a62aa
    GitDescription: v0.53.0
    Platform: linux/amd64
    GoVersion: go1.18.7
    Compiler: gc
    Supported DB Schema: 5

  • OS (e.g: cat /etc/os-release or similar):
    PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
    NAME="Debian GNU/Linux"
    VERSION_ID="11"
    VERSION="11 (bullseye)"
    VERSION_CODENAME=bullseye
    ID=debian
    HOME_URL="https://www.debian.org/"
    SUPPORT_URL="https://www.debian.org/support"
    BUG_REPORT_URL="https://bugs.debian.org/"

@kzantow
Copy link
Contributor

kzantow commented Nov 22, 2022

Just to add some more context here: Syft is currently a static analysis tool and does not currently look up anything from the internet, so scanning a pom.xml with a parent pom won't have the fidelity it could. We are investigating a number of solutions for this, all of which take Syft outside the realm of strictly a static analysis tool: invoking mvn, looking things up directly against a maven repo. This is definitely an important thing for us to solve 👍

@Restage
Copy link

Restage commented Oct 25, 2023

Any news on that? Grype not beeing able to detect inherited versions from a parent seems to be a bigger issue.

@willmurphyscode
Copy link
Contributor

Hi @Restage - no particular update here, but anchore/syft#1562 is a discussion of how to enable Syft to capture more information about this type of dependency relationship so that it can be exposed to Grype.

@Wouimbly
Copy link

Wouimbly commented Dec 8, 2023

i'm using lastest spring-boot-starter-parent 3.2.0 with graalvm21 when scanning the image i have the following;
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
spring-boot-starter-web 2.5.12 java-archive GHSA-36p3-wjmg-h94x Critical

i have no forced reference to a version of spring-boot-starter-web.
When doing a simple build i only have spring 6.1.1 and springboot 3.2.0 references....
Is it a problem with grype/sbom ?
Or i'm missing something ?

Thanks in advance

@willmurphyscode
Copy link
Contributor

Thanks @cezapata for the excellent repro steps and example repository.

I want to try to state the issue as simply as possible so we can try to start working on it.

To reproduce:

git clone [email protected]:cezapata/appconfiguration-sample.git
grype -q appconfiguration-sample | grep GHSA-36p3-wjmg-h94x

Grype still finds the vulnerability.

Looking at the syft output:

syft -q appconfiguration-sample
NAME                                        VERSION  TYPE
azure-spring-cloud-appconfiguration-config  2.9.0    java-archive
maven-wrapper                               3.1.0    java-archive
spring-boot-starter-test                             java-archive
spring-boot-starter-web                              java-archive

Syft doesn't know the version of spring-boot-starter-web because it's not explicitly in the pom.xml.

However, the <relativePath/> directive in the parent node of the pom.xml is enough that syft should know to go ask Maven Central what version of spring-boot-starter-web should be installed for version 2.7.5 of spring-boot-starter-parent. Do I have that right?

@kzantow
Copy link
Contributor

kzantow commented Jan 18, 2024

Note to developers: this would need to be implemented in Syft, a couple related issues are:

@kzantow
Copy link
Contributor

kzantow commented Aug 29, 2024

Hi, Syft has implemented a fairly large enhancement to the Maven resolution, which allows it to use the network to resolve Maven artifacts much more completely. There currently is no way to enable this in Grype, unfortunately, but you are able to use Syft, and send the output to grype to get more accurate results:

$ git clone [email protected]:cezapata/appconfiguration-sample.git

$ SYFT_JAVA_USE_NETWORK=true syft appconfiguration-sample -o json | grype -o table
No vulnerabilities found

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working false-positive
Projects
Status: Backlog
Development

Successfully merging a pull request may close this issue.

6 participants