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

[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).