> 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?
> What about having several use cases in mind, and give the scores for each of those?
i imagine the same reason they don't score for 1, it takes time that could be allocated elsewhere
tbh i think scoring for multiple scenarios would take more time and be less useful. kernel devs are not implementors, they may have never used docker or built a cut down kernel for an iot device, they just build a general purpose kernel
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.
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.
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…).
> 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?
> What about having several use cases in mind, and give the scores for each of those?
i imagine the same reason they don't score for 1, it takes time that could be allocated elsewhere
tbh i think scoring for multiple scenarios would take more time and be less useful. kernel devs are not implementors, they may have never used docker or built a cut down kernel for an iot device, they just build a general purpose kernel
> What about having several use cases in mind, and give the scores for each of those?
Or assign one score according to the worst case scenario.
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.
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.
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…).