Earlier quoted context omitted.
Unless you have a secure mechanism to forbid containers from running with `--privileged` (which does not come with container runtimes that I'm aware of), or unless your container runtime launches a VM to run the containers in, then the conception of containers being a security mechanism is a pretty thin one, indeed. Containers can be part of a secure application runtime environment, but much like sugary cereal can be…
Attackers have no control over the --privileged flag, so what you're basically asking for is a lint that greps for "--privileged" and fails CI if it finds it. Some things may make this harder, like Kubernetes presumably, but idk it seems relatively straightforward and also not exactly the fault of containers.
Maybe, maybe not. It really depends on the environment. If one's orchestration system allows an attacker to supply arbitrary arguments to a runtime, then it's quite possible that a container could be run in privileged mode without explicit authorization.
Good CI hygiene is part of the solution, but again, a comprehensive approach is needed.
The thing that makes `--privileged` an attractive nuisance is that the container runtime usually runs as root, and so it's literally a mechanism for trivial privilege escalation if the agent trusts the request being given to it, and container agents are rarely configured to require authentication of any sort. (The typical default is to run without TCP enabled, and where the Docker socket has some sort of group membership required.) Compare with the traditional UNIX privilege model, in which non-root users don't get privileges, and escalation happens through an agent like sudo(1) which typically requires re-authentication unless you're explicitly adding `NOPASSWD` to the sudoers(5) file.