The comments about how, "you should never have vulnerable docker containers," makes me laugh. I would challenge you to do the work the next couple times the, "Friday afternoon, pin it till Monday," situation happens and make that statement again. Realistic mode would be with a php container. As soon as you get into language depencency chains (npm, composer, pip, etc), "Just update it," immediately becomes a painfully naive statement. PHP is hard mode because you also have c extensions to deal with and it's a *very* common language, even if it's no longer in Vogue. I agree with you that the work needs to be done. And I agree that it shouldn't be, "pinned till Monday and then forgotten," or more likely, "pinned till Monday, then Monday morning business decides some other random thing is suddenly a huge priority." Which is something you can easily deflect if you have the gumption, experience, and political clout to tell business to pound sand on security issues when neccesary. But it's rare to find ops teams that curate that. And this is ignoring the common situation of, "We have a centralized 'devops' team (which isn't how it's supposed to work but is very common) and disparate dev teams, none of whom talk to each other or coordinate tools/technology/languages/etc." "Just patch the container," turns into, "Learn a whole new language, dependency chain, and sometimes application to do work business won't otherwise prioritize. And also chase dev and qa around for verification." I'm not going to get into the xz situation, but running bleeding edge versions of dependencies patches all the time also has a crop of issues unrelated to just, "The app broke." I'm sure you didn't mean it that way, but the statement, "You shouldn't have out of date or vulnerable containers in your environment ever," comes off as very, "Decree from the security ivory tower," that is tolerated to an extent and ignored/actively undermined in extreme cases.