A process would need to have the same permission (same user) or root to read /proc/$PID/environ no? or what mechanism is there for a process to read another process env vars (not children processes, that was already mentioned)? unless of course, a process dumped them in some world-readable file (like logs as mentioned) or some other silly way
still works if your system is a single application container
otherwise it does not
This is (part of) the reason programs accept secrets like passwords normally only (or strongly recommended) over stdin or similar instead of env variable or cmdline.
Or why it's not rare (or was in the past, probably is today) to have a encrypted cert file and inject the password to it through a side channel.
It's also not rare for programs to dump environment variables in various situations, including to logs. Or e.g. an intrusion detection program might snapshot all programs running + their cmd arguments + their (creation) env and then run analysis on it.
And while you can use e.g. selinux and similar to add a ton of security and prevent such issues, or use systemd to run the program under ad-hoc users with minimal permissions and various isolation it's very often not done.
Since the rule describes runtime configuration, it shouldn't be involved with the build process at all
- env variables are prone to be dumped in various contexts and might leak secrets to e.g. logs
- env variables might leak, e.g. in context of docker build stages etc. (but then using building a docker image to build both the image and the software is often anyway not a good idea)
- env variables are often easily accessible by other processes
the method you mentioned of ad-hoc injecting a secret as env by some form of security manager for containers avoid many such problems