Why .env files are a security disaster (and what we do instead)

A company experienced a security breach when a new hire accidentally committed production API keys to a public GitHub repository via a .env file. This led to a frantic effort to secure the system, highlighting the risks associated with .env files. The company realized that improper handling of environment variables, especially the sharing of `.env` contents, was a major security vulnerability. Engineers often manually distributed secrets causing bottlenecks in development and security risks via platforms like Slack. Existing secret management tools were complex and cumbersome, hindering non-developers' ability to set up environments. The company aimed to create a solution with zero-friction UX and top-tier security, even if it seemed contradictory. They created their own secret management tool that injected secrets directly into the runtime process, avoiding disk storage and implementing Just-In-Time leases. This was achieved through a lightweight CLI and a VS Code extension, making the new system nearly invisible to users. The solution drastically improved onboarding, eliminated leaks, and stopped the sharing of secrets through direct messages by the team. This focus on usability led to a more secure system, demonstrating that a good developer experience enhanced security. The company then released their solution, RunEnv, as a secret manager to solve this industry-wide problem.