In this instance, I am referring to (say) build-essential on Debian. If I have a C compiler in my runtime image, and someone compromises the host, they can build further tooling in the host because I gave them a hammer and nails.
We generally have to follow NIST guidelines, and therefore our containers:
Are not writeable (generally)
Contain only the packages necessary to execute the software in the container
Require allow listing for egress (meaning nothing in the container can talk to the outside world); this implies an egress proxy
Only allow specific connections in (ingress proxy)
...
Cloudron does some of this already. (To be clear: the reason I only use the official packages, and stay up to date, is because I trust the core product. Kudos to y'all, always.)
Hence, the story I'm waving (which I think Tim is as well) is that there might be a large, common build image for Cloudron (containing all of the build tools), but the runtime image (which a multistage build would copy into) is light/tight and shouldn't contain (say) a C/C++ compiler. You generally can't avoid having your language runtime(s) (e.g. ruby), but that doesn't mean that the runtime image needs the capability to install new libraries: everything should already be there for the app to execute.
Maybe that helps explain my thinking/comment.
