Golang stdlib vulnerabilities

[AlexB1986]

Hello! Thank you for the great tool!

I am wondering, is it possible with Trivy to detect known CVEs in Golang runtime environment used during binary compilation while scanning it with (with trivy rootfs /path/to/binary)?
Let's say I have a binary compiled with <go1.19.8: is there any way to ask Trivy to provide me an information that used runtime has known issues (like https://pkg.go.dev/vuln/GO-2023-1703 / https://avd.aquasec.com/nvd/2023/cve-2023-24538) ?

As far as I understand from this article Trivy fetches information about dependencies from binary (something like go version -m) and provides information about known issues. Although information about runtime version is available in binary (if it is not stripped), I was not able to find a way how to ask Trivy to output known issues in go runtime for some testing binaries, e.g. rakkess (with go1.13.7) from raesene/alpine-containertools image mentioned in the article.

I definitely missing something, thanks for you support!

[itaysk]

can you please try trivy fs --scanners vuln /path/to/bin

[AlexanderBarabanov]

Thanks @itaysk , it tried but it does not work.

Details and observations.

1. Trivy version used:

# trivy -v
Version: 0.41.0
Vulnerability DB:
  Version: 2
  UpdatedAt: 2023-05-02 12:07:22.495162215 +0000 UTC
  NextUpdate: 2023-05-02 18:07:22.495161715 +0000 UTC
  DownloadedAt: 2023-05-02 12:45:12.514268391 +0000 UTC

2. As a testing binary I used usr/local/bin/rakkess from raesene/alpine-containertools container image. I copied this binary to host filesystem.

# ls -l /go_trivy_test/
total 28140
-rwxr-xr-x 1 1001 landscape 28815360 Feb  8  2020 rakkess

This binary was compiled with go1.13.7 with known security issues, e.g. CVE-2023-24538 - https://pkg.go.dev/vuln/GO-2023-1703:

# go version -m /go_trivy_test/rakkess
/go_trivy_test/rakkess: go1.13.7
        path    github.com/corneliusweig/rakkess
        mod     github.com/corneliusweig/rakkess        (devel)
        dep     cloud.google.com/go     v0.38.0 h1:ROfEUZz+Gh5pa62DJWXSaonyu3StP6EA6lPEXPI6mCo=
        [omitted]

3. I scanned it with trivy fs --scanners vuln - Trivy did not detect any binary file in the provided folder:

# trivy fs --scanners vuln /go_trivy_test/ --debug
2023-05-02T16:19:55.268+0200    DEBUG   Severities: ["UNKNOWN" "LOW" "MEDIUM" "HIGH" "CRITICAL"]
2023-05-02T16:19:55.288+0200    DEBUG   cache dir:  /root/.cache/trivy
2023-05-02T16:19:55.289+0200    DEBUG   DB update was skipped because the local DB is the latest
2023-05-02T16:19:55.289+0200    DEBUG   DB Schema: 2, UpdatedAt: 2023-05-02 12:07:22.495162215 +0000 UTC, NextUpdate: 2023-05-02 18:07:22.495161715 +0000 UTC, DownloadedAt: 2023-05-02 12:45:12.514268391 +0000 UTC
2023-05-02T16:19:55.289+0200    INFO    Vulnerability scanning is enabled
2023-05-02T16:19:55.289+0200    DEBUG   Vulnerability type:  [os library]
2023-05-02T16:19:55.289+0200    DEBUG   Walk the file tree rooted at '/go_trivy_test' in parallel
2023-05-02T16:19:55.304+0200    DEBUG   OS is not detected.
2023-05-02T16:19:55.304+0200    DEBUG   Detected OS: unknown
2023-05-02T16:19:55.304+0200    INFO    Number of language-specific files: 0

4. I scanned it with trivy rootfs --scanners vuln - Trivy detected binary file and provide information about known issues:

# trivy rootfs --scanners vuln /go_trivy_test/ --debug
2023-05-02T16:20:56.566+0200    DEBUG   Severities: ["UNKNOWN" "LOW" "MEDIUM" "HIGH" "CRITICAL"]
2023-05-02T16:20:56.581+0200    DEBUG   cache dir:  /root/.cache/trivy
2023-05-02T16:20:56.581+0200    DEBUG   DB update was skipped because the local DB is the latest
2023-05-02T16:20:56.581+0200    DEBUG   DB Schema: 2, UpdatedAt: 2023-05-02 12:07:22.495162215 +0000 UTC, NextUpdate: 2023-05-02 18:07:22.495161715 +0000 UTC, DownloadedAt: 2023-05-02 12:45:12.514268391 +0000 UTC
2023-05-02T16:20:56.582+0200    INFO    Vulnerability scanning is enabled
2023-05-02T16:20:56.582+0200    DEBUG   Vulnerability type:  [os library]
2023-05-02T16:20:56.582+0200    DEBUG   Walk the file tree rooted at '/go_trivy_test' in parallel
2023-05-02T16:20:56.599+0200    DEBUG   OS is not detected.
2023-05-02T16:20:56.599+0200    DEBUG   Detected OS: unknown
2023-05-02T16:20:56.599+0200    INFO    Number of language-specific files: 1
2023-05-02T16:20:56.599+0200    INFO    Detecting gobinary vulnerabilities...
2023-05-02T16:20:56.599+0200    DEBUG   Detecting library vulnerabilities, type: gobinary, path: rakkess

rakkess (gobinary)

Total: 21 (UNKNOWN: 1, LOW: 0, MEDIUM: 6, HIGH: 13, CRITICAL: 1)
[omitted]

but did not provide known CVEs for Golang runtime environment used during binary compilation, e.g. I was not able no find CVE-2023-24538 in Trivy output:

# trivy rootfs --scanners vuln /go_trivy_test/ | grep "24538"
2023-05-02T16:36:08.825+0200    INFO    Vulnerability scanning is enabled
2023-05-02T16:36:08.847+0200    INFO    Number of language-specific files: 1
2023-05-02T16:36:08.848+0200    INFO    Detecting gobinary vulnerabilities...

[knqyf263]

It is not supported now. I think we have the same issue in our GitHub Issues, but I couldn't find it...

[reitzig]

Did you mean #3786 ?

Can confirm that trivy fs ignores Go binaries -- but both trivy image and trivy rootf do scan them and find CVEs!

(trivy 0.43.1 and 0.44.0)

[AlexB1986]

This issue is not about the whole Trivy ability to detect Go binaries and find CVEs, but only about ability to find CVEs in Golang runtime environment used during binary compilation.

As mentioned in one of the previous comments Trivy with trivy image and trivy rootf detects Go binary file and provides information about known CVEs in dependencies but does not detect known CVEs for Golang runtime environment used during binary compilation.

Therefore, if your Go binary is compiled with e.g. go1.13.7 (with known issue - CVE-2023-24538, https://pkg.go.dev/vuln/GO-2023-1703) Trivy detects your binary and even shows CVEs based on go.mod analysis but Trivy does not detect Golang runtime environment used during binary compilation (go1.13.7 for our example) and therefore does not show e.g. CVE-2023-24538 or other CVEs for Golang runtime environment.

I checked the latest Trivy v0.44 with raesene/alpine-containertools image (some go binaries in this image were compiled with go1.13.7) and behavior is still the same: Trivy detected go binaries, provided information about CVEs in dependencies but did not provide information about known CVEs in go1.13.7

@reitzig

[ap00rv]

i will be happy to work on this . If trivy team can provide some guidance on how they would like to see this implemented , that would be great .Thanks 😃

[rulas]

Just informative, but the image below is how we got aware of the issue:

Prometheus quay.io/prometheus/prometheus:v2.44.0)

Other tools like Grype were able to detect golang vulnerabilities in it.

[knqyf263]

It plans to be included in v0.52.0.

[knqyf263]

Adding some notes (cc: @DmitriyLewen)

We switched from the Go Vulnerability Database to the GitHub Advisory Database (GHSA) as GHSA imports data from the Go Vulnerability Database, and both use the OSV format, so their data should be consistent.

https://docs.github.com/en/code-security/security-advisories/working-with-global-security-advisories-from-the-github-advisory-database/about-the-github-advisory-database

However, I noticed that there are discrepancies between the GitHub Advisory Database and the Go Vulnerability Database.

Specifically, there are differences in the package paths. In GHSA, the "affected[].package.name" field includes package names like "net/http", whereas in the Go Vulnerability Database, it is listed as "stdlib", and "net/http" is mentioned under "ecosystem_specific".
https://github.com/golang/vulndb/blob/d97490989e7446ae88eed39434d73d454ef14426/data/osv/GO-2024-2687.json#L14
https://github.com/github/advisory-database/blob/6a39d01a5988c773309b1f80c8863d2f5d18896f/advisories/github-reviewed/2024/04/GHSA-4v7x-pqxf-cx7m/GHSA-4v7x-pqxf-cx7m.json#L21C10-L21C14

We added the Go toolchain version as stdlib in #6277. The Go Vulnerability Database format is more fit for us.

[DmitriyLewen]

@knqyf263 created aquasecurity/vuln-list-update#288 for this task.

[knqyf263]

Thanks. We'll discuss the specific implementation there.