> That feels like an abrogation of responsibility. How often are people who deal with OS packages working on kernel level vulnerabilities or are dealing with m

> That feels like an abrogation of responsibility. How often are people who deal with OS packages working on kernel level vulnerabilities or are dealing with microcode for CPUs? If someone is working on libc or libcurl are they supposed to follow and track all of the kernel level issues for every place the code would run? I would argue that someone working on libcurl is working at a different layer in the stack than someone working on a kernel. libcurl can run on multiple kernels. The same idea of layers is true when you're talking about someone working on a nodejs app and those OS layers. > To put it another way, there are two realities: > (A) No tooling support is provided to address a risk efficiently and quickly = no one addresses the risk > (B) Efficient, effective tooling is built, maintained as platform evolves, and advertised to the community = everyone does what they should I think Kelsey Hightower said it best when he said that Kubernetes is a platform for building platforms. I would argue that container systems in general are platforms for building platforms. I know people who spend a bunch of time building a platform on top of k8s at different companies. Yet, in these conversation we keep coming back to Docker or container platforms as being the platform that app developers _should_ interact with. App devs speaking out, people like Kelsey speaking up, and security issues like this all say that maybe that _should_ is wrong.