Is there a way to disable the new feature of detecting vulnerabilities in Go's standard packages?

[macedogm]

Question

Hey 👋🏻

The new feature, with v0.51.0, of detecting vulnerabilities in Go's standard packages is really nice! Thanks for implementing it. However, I've a concern that it might inflate the number of vulnerabilities detected in Go binaries, specially because it's mentioned that:

It's important to note that the detection is based on the Go version, and Trivy does not consider whether the standard package is actually being used in the binary.

Some questions:

1. Is there a way to disable it through a flag (or are there plans to add such flag)?
2. Are there plans to use go version -m <path/to/the/binary> to try to identify if the package is actually in use?
3. Was it considered to instead of listing all the possible vulnerabilities, to list a kind of generic vulnerability flagging that the identified Go version is old/outdated/EOL and in the description of the issue to list all the CVEs that it's affected?

Thanks!

Target

Container Image

Scanner

Vulnerability

Output Format

None

Mode

None

Operating System

No response

Version

Version: 0.51.0

[knqyf263]

1. Is there a way to disable it through a flag (or are there plans to add such flag)?

No. You need to use .trivyignore.

2. Are there plans to use go version -m <path/to/the/binary> to try to identify if the package is actually in use?

go version -m doesn't show the standard package names. It shows 3rd party module names, though.

3. Was it considered to instead of listing all the possible vulnerabilities, to list a kind of generic vulnerability flagging that the identified Go version is old/outdated/EOL and in the description of the issue to list all the CVEs that it's affected?

Trivy doesn't detect all possible vulnerabilities, like toolchain vulnerabilities. It detects stdlib vulnerabilities.

[macedogm]

@knqyf263 thanks for your reply. All of your comments make sense to me. I've two more questions, please:

Would it make sense to try to collapse all the stdlib related vulnerabilities in only one that is about the used Go version having known CVEs? Then this vuln could list all the related CVEs. The idea would be to compact the results and reduce the output size. The question would be, which vulnerability ID this "compacted" Go "has knowns CVEs" would be assigned. Does this makes sense to you? Please let me know if I wasn't clear enough.

Trivy doesn't detect all possible vulnerabilities, like toolchain vulnerabilities. It detects stdlib vulnerabilities.

Why is that, please? There is no CVE feed for Go toolchain CVEs or there are some technicalities involved?

[knqyf263]

Would it make sense to try to collapse all the stdlib related vulnerabilities in only one that is about the used Go version having known CVEs? Then this vuln could list all the related CVEs. The idea would be to compact the results and reduce the output size. The question would be, which vulnerability ID this "compacted" Go "has knowns CVEs" would be assigned. Does this makes sense to you? Please let me know if I wasn't clear enough.

Do you mean Trivy picks up only one vulnerability for stdlib vulnerabilities?

Why is that, please? There is no CVE feed for Go toolchain CVEs or there are some technicalities involved?

The Go database explicitly distinguishes between toolchain and stdlib. The toolchain vulnerabilities are exploitable at build time if I understand correctly. It doesn't make sense to detect them in Go binaries.