I don't know that much about the state of container systems these days, but to me it seems it's the "comfortable" way in the "security vs comfort" tradeoff. Use where applicable and hope for better days.
Conversely, if I were sysadmin at a bank I would most definitely be concerned what was running in my network.
I've worked at a bank. It's a docker file. Running Hadoop. On top of a Linux Container. Running in Rhel 5. On top of a vmware hypervisor.
- docker containers were built from source
- Dockerfile published with the code
- Built in a new CI environment
- Pushed, Pulled and deployed from the sha
- Collecting network traffic, undertaking protective monitoring, that looks for those backdoors.
Just because you can pull arbitrary bullshit doesn't mean you have to.
Though for the record, the same sysadmins that whine about newer tools are generally the same ones that implicitly trust their older toolsets. Just because you can compile it, doesn't make it secure, so you need to be running monitoring solutions and hedging your bets no matter the tech.
Of course once we come to enterprise environments the opaque build/deployment process is atrocious.
Security has a cost, as does the lack of it, hence the trade-off.
Think about your server consuming resources: It needs a [machine] password stored someplace in order to authenticate itself to those resources. If it stores this encrypted, then an operator must be present to decrypt it when (re)starting the server. If this is stored unencrypted, then it is not and the server can be started unattended (or autoscaled or whatever). That is a security tradeoff because there are both real benefits and risks gained and lost with each approach.
If docker was ever a tradeoff, it was between taking the time to have a thoughtful architecture versus trying to get acquired, and I think we know which way they went.