You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
@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.
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).
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:
What you expected to happen:
It should only report CVE-2023-29403 since that's the only vulnerability that affects the runtime library:
Steps to reproduce the issue:
Run
Anything else we need to know?:
Environment:
syft version
:cat /etc/os-release
or similar):The text was updated successfully, but these errors were encountered: