As part of a security team tasked with triaging endless CVSS scores that all make the assumption you are directly piping unauthenticated malicious data to the code in question, using whatever the worst way of doing it is, I approve of not giving misleading "worst case" CVSS scores. They are almost never worst case, are frequently trivial, and suck up a huge amount of resource.
Glad to hear developers are also pushing back against the madness. I do think just patching known bugs quickly is the best way to go. Alternative might be some kind of AI assisted triage process.
EDIT: CVSS evaluates vulnerabilities in the context of the entire system. It makes no sense to apply it to software components; you just don't know what the solution actually looks like from down there. So it's just an inappropriate method to use in the first place.
A bootable container, kernel included, is not a container. Building a whole new OS image for patches isn't a bad idea, but depending on the workload this might be a non-starter. At the very least, make updates to the OS image incremental ala OSTree. kexec can also be a nice speedup on server hardware but that carries its own risks from kexec itself but also from lack of exercising cold boot. It's not nice to find out about a few percent of hosts failing to boot all at once because nothing tested it for months until the power outage.
IMHO, optimizing your update process and treating whole OS environments like we do containers is good, but there are plenty of environments like stateful services where a rolling reboot can still take months to complete if done in a naive way.
I really don't understand the argument being made, here, it genuinely feels nonsensical to me:
- it talks about Kernel CVEs while talking about a user-space tool (containers).
- with respect to a kernel bug, what's the difference between updating/downgrading a kernel container image (whatever that means) and just doing the same for the kernel installed on the machine? Unlike a whole distro' which is made out of many moving parts with complex (and brittle) interactions, where updating can break things in ways that cannot trivially be rolled back (which makes stateless containers a good idea for user space), the kernel is pretty much a monolith and you can trivially switch between versions (even on a consumer Linux desktop you can use the previous kernel simply by selecting it in the grub list…).
I tried a lot to get this in reality - using fedora silverblue. But that thing sucks. It is slow. Really dogslow. Devs are blaming rpm-ostree or btrfs - no idea. I wish there was something like ChromeOS but open.
Hint: Maybe firefox should pivot (re-do Firefox OS) to that.
Outlining this as precision versus using 100s of thousands on chainguard, seems like 2 extremes pitted against eachother, when hardened images is largely free now: https://hub.docker.com/hardened-images/catalog
> Greg’s argument is a hard truth: “Usage is different for each user.” He cannot score a vulnerability because he doesn’t know if you’re running a cloud-native microservice or a legacy industrial controller.
What about having several use cases in mind, and give the scores for each of those?
> We must stop litigating which fixes matter and start treating every kernel bug fix as relevant (a bug is a bug). We must stop running patching as a project and bake it into the pipeline so that applying stable fixes is simply what the system does (the patch is the policy).
Ah, so it's simply "apply all the fixes automatically", i.e. "the Chainguard way" but, again, fully automated. Okay?