grype v0.71.0 stopped showing vulnerabilities for Go stdlib

[abg]

What happened:

grype v0.70.0 enabled go stdlib matching (#1550).

In grype v0.71.0 the go stdlib vulnerabilities no longer appear by default. Adding match.golang.using-cpes: true seems to return this behavior.

What you expected to happen:

Expected the same behavior in grype v0.71.0 as was introduced in v0.70.0

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

# initialize a go module using an old potentially vulnerable version
$ go1.19 mod init foo
$ cat > main.go <<EOF
package main
func main() {}
EOF
# build a binary to be scanned
$ go1.19 build .

# generate an sbom
$ syft packages --quiet --output=cyclonedx-json=sbom.json dir:.

# Vulnerabilities displayed with v0.70.0
$ go run github.com/anchore/grype/cmd/[email protected] --quiet sbom:sbom.json
NAME    INSTALLED  FIXED-IN  TYPE       VULNERABILITY   SEVERITY
stdlib  go1.19               go-module  CVE-2023-39323  Critical
stdlib  go1.19               go-module  CVE-2023-29405  Critical
...

# No vulnerabilities found with v0.71.0
$ go run github.com/anchore/grype/cmd/[email protected] --quiet sbom:sbom.json
No vulnerabilities found

# re-enabling "match.golang.use-cpes" shows Go vulnerabilities again
$ cat > .grype.yml <<EOF
match:
  golang:
    using-cpes: true
EOF
$ go run github.com/anchore/grype/cmd/[email protected] --quiet sbom:sbom.json
NAME    INSTALLED  FIXED-IN  TYPE       VULNERABILITY   SEVERITY
stdlib  go1.19               go-module  CVE-2023-39323  Critical
stdlib  go1.19               go-module  CVE-2023-29405  Critical
...

Anything else we need to know?:

Environment:

• Output of grype version:

  $ grype version
  Application:         grype
  Version:             0.71.0
  BuildDate:           2023-10-12T13:27:46Z
  GitCommit:           3d582fd85145afe3fd3726437527a321efb664e9
  GitDescription:      v0.71.0
  Platform:            linux/amd64
  GoVersion:           go1.21.1
  Compiler:            gc
  Syft Version:        v0.93.0
  Supported DB Schema: 5
  

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

  $ cat /etc/os-release
  PRETTY_NAME="Ubuntu 22.04.3 LTS"
  ...
  

[visomar]

Regarding CVE-2023-44487, we've also noticed that this is happening after upgrading Grype from 0.69.1 to 0.71.0, hiding some current positives of libraries like reactor-netty-core:1.1.12 and reactor-netty-http:1.1.12.

Setting match.java.using-cpes: true also brings back these libraries as part of the results.

As a note, we tried to use --by-cve as part of the parameters of the execution, but the result is not the same as the one obtained with match.java.using-cpes.

[jiri-muller]

I can confirm same behavior since 0.71.0. Setting match.java.using-cpes: true for me also fixes the issue.

[dbrugman]

Seems to be caused by this change; defaults for using CPEs to match vulnerabilities has been changed for Java, Dotnet, Golang, Javascript, Python, Ruby and Rust:

v0.70.0...v0.71.0#diff-2ef22c527f0a8b6e3af2cc896fac4a1356a1bb57be37773e0e57f059f8db5464R21

[wagoodman]

Correct, we have disabled CPE matching by default except for the stock matcher (which is used when there is not a specific way to search for the given package type).

You can override this behavior with a .grype.yaml to get the original behavior back:

match:
  java:
    using-cpes: true
  python:
    using-cpes: true
  javascript:
    using-cpes: true
  ruby:
    using-cpes: true
  dotnet:
    using-cpes: true
  golang:
    using-cpes: true
  stock:
    using-cpes: true

The reasoning and benefits for changing the default behavior is described here https://anchore.com/blog/say-goodbye-to-false-positives/ , shout out if you have any questions about this!

In terms of the golang stdlib matching described in this issue, I'll be adding an exception for this case in a upcoming PR (writing the tests now).

[wagoodman]

@visomar @jiri-muller can you provide additional details to help reproduce the issue (an artifact or an SBOM snippet to help reproduce the issue) and open up new issues to track? This issue describes a specific case for the go ecosystem and is about to be fixed (thus closed). Eager to get more details about issues in the ecosystems you're working with.

[dbrugman]

Thanks for the explanation and link @wagoodman !

[jiri-muller]

@wagoodman Thank you, I have created dedicated issue: #1568