Is there a way to force bottlerocket ecs-2 AMI to use containerd 2.0?

[FalkWoldmann]

Hi, right now, WIZ security scanner is falsely reporting that bottlerocket-aws-ecs-2-aarch64-v1.42.0-5ed15786 is vulnerable to CVE-2024-40635, even though the deployed containerd version already patched the issue. Anyhow, we cannot ignore these findings, which is quite annoying. One idea would be to explicitly use containerd 2 and I found a PR that integrated support for it (#485 and #4375), but it looks like it's not enabled yet for the AWS managed bottlerocket AMIs. Is there a way to manually enable it?

[yeazelm]

WIZ security scanner is falsely reporting that bottlerocket-aws-ecs-2-aarch64-v1.42.0-5ed15786 is vulnerable to GHSA-265r-hfxg-fhmg, even though the deployed containerd version already patched the issue.

That variant is on containerd 1.7.27 which is the patched version. I'm curious to know what logic Wiz is using to flag this because this should be a straighforward case where the version is the patched version for that CVE. I'd recommend asking them specifically since I can't speak to how they are detecting this.

One idea would be to explicitly use containerd 2 and I found a PR that integrated support for it (bottlerocket-os/bottlerocket-core-kit#485 and #4375), but it looks like it's not enabled yet for the AWS managed bottlerocket AMIs. Is there a way to manually enable it?

There is no way to change out containerd in a Bottlerocket image. It is part of the immutable image. If you would like containerd 2.0 or later in an ECS variant, we should cut a feature request for that and we can track it separately. Nonetheless, for this purpose you shouldn't need containerd 2.0 so I'm entirely not sure if you actually want containerd 2 for other reasons besides this finding?

[FalkWoldmann]

Hi! Thanks for the quick response. No, it's just for getting rid of the false positives. Containerd 1.7 works just fine for us.