nostr:npub1l3gpk6vrudg8r67swqlex5alv9ch59s4lw46kk6hekuxe2n3aczsyqvu48

To add, and address a separate point:

you're trusting them to not only update their app in the container image, but every underlying utility and library used.

Most projects that I can think of, building container images usually is part of the CI/CD pipeline, and those images usually start their build with a number of apt / dnf / yum / apk / pkg / etc. invocations to pull the libs, meaning that every application update is, within a day or two, an image update, and usually a library update since it's in effect firing up a very lightweight VM, running a bunch of package installations, and then copying its own files in.

Some places even build the app in the container with the libraries to make sure it's all set up correctly for the environment, and then have a second build stage, so you're not holding all the build-time dev dependencies that it needs, but that's getting a bit besides the point.

nostr:npub1trdnqrfstufc45awha43p6xy2n0v6czuhapzh4r09hap08dg0c6s9gussx

nostr:npub17j5xgxhtskpcp0kjd9ldjhm3w6ggns7kkvfp44lk4qsrdwawmjeqvd0ny5 nostr:npub1trdnqrfstufc45awha43p6xy2n0v6czuhapzh4r09hap08dg0c6s9gussx

That's better, but if the application running on the image requires a raft of other programs running (e.g. LAMP/LNMP stack), that's still a huge leap of trust that those will stay sufficiently up-to-date.

Even without dependent processes, the libraries themselves can often be attack surfaces.

I get that it's a very convenient solution to a pretty hairy problem, but it introduces some pretty hairy problems of its own, no?