> 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.