packeto buildpacks are still using go 1.20 which is unsupported / EOL triggering security alerts

[candrews]

I noticed that many Paketo Buildpacks projects are still using go 1.20 which is EOL / unsupported according to https://go.dev/doc/devel/release

I discovered this issue because security scanners are now reporting vulnerabilities against Paketo Buildpacks and the images they build. For example, CVE-2023-45288 is reported frequently and being a high severity vulnerability it sets off some loud alarms. I'm confident that this vulnerability and the others reported are not exploitable, but their presence is still troublesome for it still requires effort to suppress the findings and justify the reasoning.

Can all usages of go 1.20 please be upgraded to at least go 1.21, ideally 1.22?

I see that Paketo used to have an automatic process for doing go upgrades, as I see many PRs like paketo-buildpacks/native-image#251 by @paketo-bot. Perhaps that automation can be revived?

[sophiewigmore]

Thanks for the ping @candrews. We should definitely bump the Go version, and try to automate doing this in the future

[sophiewigmore]

@robdimsdale thank you SO much for the in-depth explanation. Since the toolchain changes in 1.21, I've been quite confused on how this behaviour is meant to work, this helped a lot. I like your proposal to keep go updated as well 👍

[dmikusa]

Sounds good to me.

[robdimsdale]

PR to add the above here: paketo-buildpacks/github-config#928

[robdimsdale]

PR has been merged - we should see toolchain getting written when the workflows run, starting next monday.

[dmikusa]

Is there someone that can follow through and make sure we end up releasing buildpacks after this change has been applied?

I know for a fact that web-servers & nginx (the culprit) are using Go 1.22.2 which has a flagged CVE so images from those buildpacks are generating images flagged with CVEs. We probably don't need to release all the buildpacks, but any buildpack that inserts an exec.d helper that's a Go binary should.

For example:

layers/paketo-buildpacks_nginx/nginx/exec.d/0-configure (gobinary)
==================================================================
Total: 1 (HIGH: 1, CRITICAL: 0)

┌─────────┬────────────────┬──────────┬────────┬───────────────────┬───────────────┬────────────────────────────────────────────────────────────┐
│ Library │ Vulnerability  │ Severity │ Status │ Installed Version │ Fixed Version │                           Title                            │
├─────────┼────────────────┼──────────┼────────┼───────────────────┼───────────────┼────────────────────────────────────────────────────────────┤
│ stdlib  │ CVE-2024-2[47](.../actions/runs/9356761067/job/25755033257#step:5:48)88 │ HIGH     │ fixed  │ 1.22.2            │ 1.22.3        │ golang: net: malformed DNS message can cause infinite loop │
│         │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2024-24788                 │
└─────────┴────────────────┴──────────┴────────┴───────────────────┴───────────────┴────────────────────────────────────────────────────────────┘

[candrews]

Would it be helpful for me to submit PRs to the various projects doing this work?

I'm eager to get this done as it's causing a lot of headache and paperwork for my Powers That Be.

[dmikusa]

Ugh, more security issues. 1.22.3 was the most recent when we released last time. We'll do another round. Hopefully the Go CVEs slow down soon :)

[candrews]

Do you have an issue you're using to track the go 1.22.4 upgrade?

I'm getting a lot of noise due to CVE-2024-24790 being reported in the buildpacks so I'm really looking forward to this update.

Perhaps you could use dependabot, renovate, or some other tool to keep updating the go version going forward, eliminating the need for manual work?

[dmikusa]

It isn't updating it that's the problem. Go gets updated automatically for patch releases. It's that buildpacks need to be re-released, that is more work and not something we can commit to for every CVE reported.

We aim to release stack updates that fix High and Critical CVEs within 48 hours of the patch release. For stack updates fixing Low and Medium CVEs, we aim to release within two weeks.

https://paketo.io/docs/concepts/stacks/#when-are-paketo-stacks-updated

We follow the same policy for buildpacks and when we'll cut new releases for CVEs. CVEs that do not impact buildpacks would also be in the two-week category, but please take note that is best-effort, not a guarantee.

[candrews]

CVE-2024-24790 is a Critical CVE - so shouldn't it be addressed within 48 hours of the patch release?

[dmikusa]

How would that impact buildpacks? That's the thing with buildpacks, we use a very small part of the Go runtime, most CVEs are not even related to methods we're using. Even if we did use one, because of what buildpacks are doing it would be very hard to exploit in a meaningful way.

The primary use case we watch out for are with exec.d processes. These get put into your application container, so they could impact runtime which is the biggest concern. Most/all of these that we install are very simple. They look at env variables and set env variables. They're not doing anything network-related (I don't know of any that do). So there shouldn't be anything at runtime invoking Go runtime network calls. That stuff happens at build time, but there are way easier ways to do whatever you want at build time without a CVE being required, so again they don't meaningfully impact buildpacks.

tl;dr. We look at Go CVEs, but 99% of them are not going to impact buildpacks in a way that would be HIGH/CRITICAL, so they fall into the two-weeks window.