Author: Greg Bulmash

Your version control system, like Git, is a primary vector for secret sprawl, unintentional source poisoning, and intentional source poisoning. In a shift left model, there are degrees of leftness. The most left you can get is to test all the code before the developer tries to commit anything and train them thoroughly in the best practices. But when we rely on people to remember to do things consistently and correctly, we're cutting holes in the safety net. We need mechanisms.

At Amazon, they have a saying: "Good intentions don't work. Mechanisms do." Humans can feel fatigued, rushed, distracted, or otherwise encumbered, and despite all intentions to follow best practices, they don't. When you automate enforcement of best practices, you can ensure those practices are followed in a much more consistent and correct fashion.

Managing your secrets well is imperative in software development. It's not just about avoiding hardcoding secrets into your code, your CI/CD configurations, and more. It's about implementing tools and practices that make good secrets management almost second nature. 

A Quick Overview of Secrets Management

What is a secret? It's any bit of code, text, or binary data that provides access to a resource or data that should have restricted access. Almost every software development process involves secrets: credentials for your developers to access your version control system (VCS) like GitHub, credentials for a microservice to access a database, and credentials for your CI/CD system to push new artifacts to production.

Using environment variables to store secrets instead of writing them directly into your code is one of the quickest and easiest ways to add a layer of protection to your projects. There are many ways to use them, but a properly utilized `.env` file is one of the best, and I’ll explain why.

They’re Project Scoped

Environment variables are a part of every major operating system: Windows, MacOS, and all the flavors of *nix (Unix, BSD, Linux, etc.). They can be set at an operating system level, user level, session level… It gets complicated, and where/how you define them matters to the scope in which they can be accessed.