Ignore Go compiler affecting CVE when Docker image only contains a binary compiled with Go

[sunwhawhang]

What happened:

Note: Opened issue in grype (anchore/grype#1782) but thought it's more directly related to syft.

Related to bug reported in grype: anchore/grype#1370, quay.io/calico/kube-controllers:v3.20.0 image does not have Go compiler but only contains a binary that was compiled with the Go compiler and statically linked against the Go runtime library.

The issue was fixed in #2195, however, now it's reporting false positive CVE's that only affect to Go compiler itself: CVE-2023-29402, CVE-2023-29404 and CVE-2023-29405:

❯ grype quay.io/calico/kube-controllers:v3.20.0 -q | grep -E '29402|29403|29404|29405'
stdlib                               go1.15.2                                                                               go-module  CVE-2023-29405       Critical  
stdlib                               go1.15.2                                                                               go-module  CVE-2023-29404       Critical  
stdlib                               go1.15.2                                                                               go-module  CVE-2023-29402       Critical  
stdlib                               go1.15.2                                                                               go-module  CVE-2023-29403       High    

What you expected to happen:
It should only report CVE-2023-29403 since that's the only vulnerability that affects the runtime library:

❯ grype quay.io/calico/kube-controllers:v3.20.0 -q | grep -E '29402|29403|29404|29405'
stdlib                               go1.15.2                                                                               go-module  CVE-2023-29403       High    

Steps to reproduce the issue:
Run

grype quay.io/calico/kube-controllers:v3.20.0 -q | grep -E '29402|29403|29404|29405'

Anything else we need to know?:

Environment:

• Output of syft version:

  # From `grype version` (0.74.7)
  Syft Version:        v0.105.1
  

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

  NAME="Ubuntu"
  VERSION="18.04.5 LTS (Bionic Beaver)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu 18.04.5 LTS"
  VERSION_ID="18.04"
  HOME_URL="https://www.ubuntu.com/"
  SUPPORT_URL="https://help.ubuntu.com/"
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
  PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
  VERSION_CODENAME=bionic
  UBUNTU_CODENAME=bionic
  

[spiffcs]

@sunwhawhang - If we know that the binary was compiled with a version of Golang that was vulnerable to the listed CVE, how can we prove this is a false positive?

The go command may execute arbitrary code at build time when using cgo. 
This may occur when running "go get" on a malicious module, or when running any other command 
which builds untrusted code. This is can by triggered by linker flags, specified via a "#cgo LDFLAGS" directive. 
The arguments for a number of flags which are non-optional are incorrectly considered optional,
allowing disallowed flags to be smuggled through the LDFLAGS sanitization.

I think a prudent security team would want the binary to be recompiled with a version of go that was not susceptible to this kind of LDFLAG injection.

We believe it's correct to include a package in the SBOM representing the go stdlibrary when we have detected a binary built with that version of the std lib.

NVD labeling does not distinct between the std library vs the toolchain used to compile the binary.

We don't think this is definitely a false positive and believe the default case should be to include this package when detecting a binary built by go vx.x.x

cc @joshbressers for more thoughts on if we should even include an option that allows users to drop this package entirely

Grype should be able to add an ignore rule for this vulnerability if a security team review the compilation process to guarantee that no arbitrary code execution could have happened at build time.

[wagoodman]

Not saying this is the right thing to do, but we could start filtering out cmd/* related CVEs from the go source repo based on affected package information within the go vulnerability report linked to the CVE in question (in this case CVE-2023-29402).