Suppress invalid CVE-2016-1000027

[ThomasVitale]

What happened:

The CVE-2016-1000027 is flagged as critical for applications using any 5.x version of the Spring Framework.

What you expected to happen:
The Spring team has explained that the CVE is invalid (spring-projects/spring-framework#24434 and details spring-projects/spring-framework#24434 (comment)), so I would expect grype not to flag it. An open issue also exists to reject this CVE: CVEProject/cvelist#5949.

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

Scan with grype any application using any 5.x version of the Spring Framework.

[Turbots]

+1 Please suppress this invalid CVE, as it is stopping a lot of people using Grype to continue with a certain application deployment... The security scanning step is stopping the CI/CD pipelines and preventing customers to go to production with new releases.

[spiffcs]

Thanks for the bump on this issue @Turbots and thank you @ThomasVitale for filing the issue. I'm working on closing a PR for grype at the moment and then will pick this up and resolve the FP based on the evidence provided and related support that's been listed.

[spiffcs]

@Turbots while we work on a fix that possibly lowers the severity of this vulnerability in the grype feed service you can specify matches you'd like to ignore via the ignore configuration linked below:
https://github.com/anchore/grype#specifying-matches-to-ignore

If this does not work for you let me know if there are other workarounds to explore that can unblock the production gates

[joshbressers]

This issue is a lovely example of many hurdles the current vulnerability ecosystem suffers from (on a side note, the Cloud Security Alliance has a project called GSD to try to discuss and solve many of these problems)

I'm going to ignore the discussion of if this should or shouldn't have an ID. I think that's more art than science at this point.

But I do think we can all agree the severity is pretty 🍌

This is not a critical issue by itself. Unfortunately CVSS is not capable of scoring something like this because the ID is completely dependent on the use case of a framework. This is like demanding a lumber yard tell you how strong of an earthquake a stack wood can withstand if you build a house with it.

I would give this a CVSS3.1 score of 0
AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N
Not because it deserves a 0, but because the severity is low and this is the only intellectually honest way to score this.

That said, there is value in having this ID around even as low. It provides an opportunity for spring users to take steps to ensure they are not deserializing untrusted data.

I would prefer we fix the severity instead of completely removing the ID from our data set.

If anyone has opinions on this matter please speak up, this will help define future policy decisions around the Grype data

[OfriOuzan]

We encountered the same issue on the following environment
What happened:
In a Vulnerability Scanner Benchmark Research we are conducting, we executed Grype on 20 different containers and found out that Grype has multiple False Positives.
What you expected to happen:
We expected Grype not to report on these CVEs.
How to reproduce it (as minimally and precisely as possible):
Install the Docker Images (from the links below) and execute Grype using the following command:
grype <container_name> —-output json > <output_file_path>

• Output of grype version:
  Application: grype
  Version: 0.41.0
  Syft Version: v0.50.0
  BuildDate: 2022-07-06T15:20:18Z
  GitCommit: 0e0a9d9
  GitDescription: v0.41.0
  Platform: linux/amd64
  GoVersion: go1.18.3
  Compiler: gc
  Supported DB Schema: 4

Jenkins

• Container Details:
  https://hub.docker.com/layers/jenkins/jenkins/2.358/images/sha256-01600c1acde3391286945f775f2e5b2366f9b96fbe012a3ffa5159073c0c6392?context=explore

• OS (e.g: cat /etc/os-release):
  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/"

• CVEs
  CVE-2016-1000027
  Grype wrongly identified CVE-2016-1000027 as vulnerable.
  According to the debian website, the vulnerable component is the libspring-java package which does not exist on the container.
  Grype identified the spring-core file with version 5.3.21 as vulnerable.
  The actual version that exists on the container is 5.3.16.
  However, according to the open issue that referenced a maintainer discussion about the case, the vulnerability is invalid.

[Schwaller]

This affects everybody that uses spring ... please fix it soon. @OfriOuzan great analysis!

[willmurphyscode]

Hi all,

Since this issue was opened, Grype has switched from using CVE data to using GHSA data by default for Java packages.

We still find the GHSA version of this issue, GHSA-4wrc-f8pq-fpqp, and it is still marked as critical. From Grype's perspective, we are correctly reporting what the upstream data source says.

But, since we use GHSA now, it's possible for users to seek to correct the data by raising an issue or PR against https://github.com/github/advisory-database. If such a correction is accepted up stream, Grype will results will reflect the corrected data after about 24 hours.