Dependency update - Golang 1.22.5/1.22.7

[synergiator]

Trivy report with Kubectl 1.31.0:

┌─────────┬────────────────┬──────────┬────────┬───────────────────┬────────────────┬─────────────────────────────────────────────────────────────┐
│ Library │ Vulnerability  │ Severity │ Status │ Installed Version │ Fixed Version  │                            Title                            │
├─────────┼────────────────┼──────────┼────────┼───────────────────┼────────────────┼─────────────────────────────────────────────────────────────┤
│ stdlib  │ CVE-2024-34156 │ HIGH     │ fixed  │ 1.22.5            │ 1.22.7, 1.23.1 │ encoding/gob: golang: Calling Decoder.Decode on a message   │
│         │                │          │        │                   │                │ which contains deeply nested structures...                  │
│         │                │          │        │                   │                │ https://avd.aquasec.com/nvd/cve-2024-34156                  │
│         ├────────────────┼──────────┤        │                   │                ├─────────────────────────────────────────────────────────────┤
│         │ CVE-2024-34155 │ MEDIUM   │        │                   │                │ go/parser: golang: Calling any of the Parse functions       │
│         │                │          │        │                   │                │ containing deeply nested literals...                        │
│         │                │          │        │                   │                │ https://avd.aquasec.com/nvd/cve-2024-34155                  │
│         ├────────────────┤          │        │                   │                ├─────────────────────────────────────────────────────────────┤
│         │ CVE-2024-34158 │          │        │                   │                │ go/build/constraint: golang: Calling Parse on a "// +build" │
│         │                │          │        │                   │                │ build tag line with...                                      │
│         │                │          │        │                   │                │ https://avd.aquasec.com/nvd/cve-2024-34158                  │
└─────────┴────────────────┴──────────┴────────┴───────────────────┴────────────────┴─────────────────────────────────────────────────────────────┘

[jeremyrickard]

@synergiator thanks for your issue.

We did not bump the go dependency prior to our most recent patch releases because upon review these CVEs are not present in the way we use Go. Trivy unfortunately does not do real analysis and this report is incorrect.

[itaysk]

Hello from team Trivy :)

Trivy detects Go standard library as a dependency and will report vulnerabilities in it. As @jeremyrickard mentioned, Trivy (or any other SCA scanner) doesn’t do reachability analysis to determine if vulnerabilities are reachable, but even a tool that does, like govulncheck could miss that due to the absence of call graph information in Go binaries. This and more is documented in Trivy’s Go scanning documentation.

To address this, we recommend publishing VEX (Vulnerability Exploitability eXchange) documents, that announces this vulnerability as not reachable. This process has just became super easy thanks to Trivy’s built in integration with VEX Hub.
IMO this is a perfect candidate for VEX so that scanners will automatically suppress it. You can read more about it here and feel free to reach me or the Trivy team if you need assistance with VEX.

[BenTheElder]

#3738 Already tracks go update.

I don't know that we want to be investing more time in supporting scanners, as-is they consume a lot of our time for questionable benefit to the project.

Please remember these binaries are free and you can always contribute to upgrading go versions or build locally

That's probably a question for SRC.

[BenTheElder]

That's probably a question for SRC.

Er:

• SRC == https://github.com/kubernetes/committee-security-response
• SRC: Should we start publishing VEX?
• SRC: Who will maintain and verify them? If we start publishing these we want to be sure that they're correct.

cc @kubernetes/security-response-committee

In this particular case I think we should invest in shipping updated go, we didn't rush it in the most recent patch release because the vulns aren't relevant anyhow, but we continuously invest in staying on stable up to date go releases anyhow.

[itaysk]

I don't know that we want to be investing more time in supporting scanners, as-is they consume a lot of our time for questionable benefit to the project.

Fair enough, I can understand how dealing with all of that could be a burden. FWIW I think the time was already invested, by looking into this report and writing a response. VEX would simply allow you to write the same response in JSON instead of plain english, and then scanners could become aware of it and perhaps even save you time in the future. I'll make the suggestion for SRC, thank you.

[BenTheElder]

FWIW I think the time was already invested, by looking into this report and writing a response. VEX would simply allow you to write the same response in JSON instead of plain english, and then scanners could become aware of it and perhaps even save you time in the future. I'll make the suggestion for SRC, thank you.

Yeah that's fair, I think there's an additional cost because while one of us can say in plain english "I don't think this is valid don't worry about it" that's not quite the same as publishing official metadata that says the same.

IE we either have bureaucratic overhead, or we are kinda YOLO-ing publishing this.

We have generally instead invested in not tripping scanners to begin with (e.g. distroless images), and we have more low hanging fruit there (e.g. further streamlining go upgrades, we don't quite have everything just respecting https://github.com/kubernetes/kubernetes/blob/master/.go-version)

Personally I think minimizing the false positives is the best approach, like in this case we do want to ultimately upgrade Go regardless, but in the meantime we can tell people "we don't think this is valid, up to you to decide if that's OK or help us update Go".

[ritazh]

xpost kubernetes/kubernetes#121454 and kubernetes/sig-security#116 would be good to continue the discussions there as we hash out details for next steps.

[justaugustus]

Superseded by #3778.
/close