If an attacker can read other processes' envs you've pretty much lost as they're
1. Inside your process which means they can see the decrypted values.
2. Root which means they can get into your process to see the decrypted values.
I'm not sure if your average dev has a threat model that assumes in memory scrambling let alone leaked env vars. After all we're talking about the standard way to do it being populating a file with the decrypted secrets and just leaving it there. All the security is already kernel security.
I'm honestly not sure who dotenvx is aimed at.
- No one security conscious is going to be cool just making the cyphertext available publicly or even internally.
- Someone scrambling in-memory secrets isn't using dotenv to begin with, is using SecretsManager and the like, and probably doesn't want to change those to now go through the filesystem. You now get less auditing because all those secrets are bundled and you now only know "they accessed the decryption key."
- And someone using dotenv for secrets doesn't have a threat-model where this meaningfully improves security.
In adittion, if I'm not mistaken, child processes inherit the parent env vars, so if your application forks or use subcommands, you may be exposing the whole environment trove to 3rd party scripts, no root needed. Also, most vulnerabilities that enables execution of code will happily leak the env vars, no root access or "being inside the process" thingy (I know, code execution is technically "inside the process", but without requiring privileged levels)
I’m advocating people use something like SecretsManager, not this thing. In-memory only > env vars > secret files on disk.
I find env vars very precarious because harmless developer debug logging, actions like sshing into a container and typing `env` etc can easily expose them.
File on disk can be read by an attacker with via subdirectory path traversal bug
It’s much less likely for in process only secrets to be exposed by common mistakes/bugs
1. Inside your process which means they can see the decrypted values.
2. Root which means they can get into your process to see the decrypted values.
I'm not sure if your average dev has a threat model that assumes in memory scrambling let alone leaked env vars. After all we're talking about the standard way to do it being populating a file with the decrypted secrets and just leaving it there. All the security is already kernel security.
I'm honestly not sure who dotenvx is aimed at.
- No one security conscious is going to be cool just making the cyphertext available publicly or even internally.
- Someone scrambling in-memory secrets isn't using dotenv to begin with, is using SecretsManager and the like, and probably doesn't want to change those to now go through the filesystem. You now get less auditing because all those secrets are bundled and you now only know "they accessed the decryption key."
- And someone using dotenv for secrets doesn't have a threat-model where this meaningfully improves security.