The Missing Third

I believe every developer deserves amazing collaboration tools for managing secrets. Using a secrets manager shouldn't come at the cost of a brain aneurysm. In fact, I think a platform designed for developers of all backgrounds can bring moments of joy to your day, promote healthy security hygiene, and boost your overall developer productivity. Doppler was built from the ground up because the Universal Secrets Platform (USP) I needed simply didn't exist.

I am sure at this point you may be asking who are you? What is a secret - sounds mysterious? What is a USP? How does it differ from a traditional secrets manager or even a dotenv file? Lots of questions, I’ll start off with a simple one - who am I.

Hi - I am Brian 👋, an introvert who plays an extrovert in real life. I love building things (mostly through code and legos), have a passion for making weird art, and hanging with friends. I am sharing all this to show I am just another person, another developer, like you. Below are my thoughts on how the current way of managing secrets is broken and a proposed solution through what I call a Universal Secrets Platform (USP).

App = Code + Compute + Secrets

From my experience, running an application typically requires at the minimum code, compute, and secrets. Three pieces of a puzzle that form a living picture. We are lucky to live at a time where amazing collaborative source control platforms exist enabling distributed teams to build together. This paired with CI/CD and cloud-based hosting allows for fully automated deployments that can reach users in most regions at near infinite scale. But what about the other, often deemed less exciting piece to running applications — secrets?

For context, secrets are typically API keys, database urls, certificates, environment variables, and other app configuration such as a port variable. They are often used to grant access to highly sensitive data/services and thus should never be stored in an unencrypted format such as in code or dotenv file.

Responsibility to our users

Secrets are the literal keys to our digital kingdom and deserve to be treated as such. Before Doppler I didn't think much about secrets, as my job was to ship features to customers as fast as possible. Building and shipping is an adrenaline rush, and through that rush, it became easy to lose sight of what I was doing.

I thought of secrets as a means to an end, a required piece of the puzzle that let my code talk to services like Stripe and Twilio. I never stopped to think about the impact it would have if those secrets ever became "not so secret". In one decision, made now or years ago, I could have accidentally leaked all of our users data that had been entrusted with us. I often would store our production Stripe key in an unencrypted dotenv file which granted access to our customer's credit cards and bank accounts. The impact that one secret could have had on their lives if it ever got leaked would have been tremendous.

It's easy to forget that behind the UUID of a user is a real person with a life and loved ones. They trust us with their data, the least we should do is protect. While you might be thinking that a leak would never happen to you, the Twitch source code leak was a brutal reminder that the unexpected can happen at any time, to anyone. I hope this gives you a moment of pause to reframe how you think about the secrets you already have today.

.... a minute later. Pause is over, onwards!

A missing puzzle piece

It would be painful to imagine a world before the likes of GitHub, where you had to take code and share it over email/FTP and then perform surgical merge resolution to adopt the changes. This wouldn’t just happen once, but every time anyone changed code. Then to deploy that newly minted code to production, one person would need to SSH into a server and upload the code manually. Hoping and praying along the way that they didn’t mess up and accidentally bring the service down. These workflows were manual because we didn’t have pull requests, CICD, infrastructure as code, cloud computing, or other fancy automations we benefit from today.

But everything isn’t as automated as it seems, as much of the same problems exist today with secrets. Take dotenv for example… which is a file that holds a list of secrets in an unencrypted (🤦) human-readable format. Each developer and every environment (e.g. staging, production) needs its own dedicated dotenv file that is specific for that machine. This file should never be tracked by source control, leaving developers to the manual, error-prone, and time-consuming dynamics that we previously experienced with code before source control existed. These unencrypted files are then passed around Slack, email, other productivity tools that are not designed to store the literal keys to the kingdom.

Then when updating the ".env" file for production and other environments, the developer has to add the secrets manually. In the case of a medium to large company, they would need to create a task/ticket for the DevOps team who is responsible for managing infrastructure.

Environments must then be updated in a timely manner as the secrets need to be available before the new code that uses them is deployed. This creates a tricky race condition when code is automatically pushed from GitHub while secrets are configured by humans. There is also a greater chance of the service going down when secrets are touched manually as human error can strike in the moment through a seemingly innocuous typo. Secrets need to be perfect, if they are off by even a single character from what they need to be, it can cause serious problems.

Adding or updating a secret in a dotenv file may sound simple, but in reality, it’s much more complex. Changes are often made in groups where some secrets are added, while others are removed or even updated. Imagine distributing all of those changes by hand day in and day out. Sounds like a recipe for a typo.

Automated and collaborative tooling

At this point you may be asking why there isn't a tool that already exists since the conventional way is so painful. Truth be told, I asked the same question before I started Doppler. To my surprise, there are tools that exist but I hadn't heard of them because they weren't built for me. I am a developer, heart and soul, and those tools were built for the security teams. I found the user experience sucked, SDKs complex, on-premise requirements frustrating, and lack of built-in management features left the developer experience out of the equation while ticking all the right boxes for security.

I am a visual person, I want a dashboard. I don’t like repeating high-risk mundane tasks. I want integrations like GitHub where my secrets are automatically deployed alongside my code. Lastly I am human, I forget things and make typos. I want a tool that has my back by catching my mistakes before they become costly. And in the event I do mess up, I should be able to instantly roll back the changes from a click in a dashboard. I want the automation benefits that have revolutionized how we build and ship software applied to the one area that developer tools forgot—secrets.

We as an industry need to define a new devtools category that captures what we as a development community need for managing secrets securely, from individual developers to enterprise organizations.

I propose that we need a Universal Secrets Platform (USP). A single source of truth for developers and their teams to manage, store, and automate secrets syncing to every major hosting platform and cloud provider. Universal is the differentiating prefix and comes with four requirements:

• Universally accessible and useable for developers of all skill levels and specialties. From junior developers to the most senior.
• Universally empowers least privilege access. Developers and machines should only have access to the secrets they need.
• Universally provides a full-featured and easy-to-use dashboard and CLI that takes minutes, not days or weeks to learn.
• Universally supports every operating system and infrastructure, from Serverless to Containers, static-sites to Virtual Machines, and everything in-between.

So how does this differ from the secrets managers that exist today? AWS and GCP both have secrets management offerings while new cloud providers like Vercel and Netlify also allow for securely storing secrets. To see the difference, we need to separate storage from management to match reality. The secret “managers” we have today actually only offer simple Key-Value storage and lack support for the workflows developers need in practice. In our new model, we should treat them as storage destinations. The USP becomes the central source of truth, responsible for distributing secrets to the corresponding storage destinations. This also serves as a multi-cloud solution for a modern-day data center.

Let’s take a look at an example through the lens of a project. Straight off, we notice that every environment, including local development, is supported. Not only that, but every developer gets their own isolated secrets store. There is automated testing in place through CircleCI while Netlify is used staging and production deployments. Each one of these environments (development, staging, and production) has at least one destination ranging from a developer’s laptop to CircleCI and Netlify.

A Universal Secrets Platform is the hub where all those secrets are stored, managed, and versioned across environments. When they are changed in the USP, secrets automation updates them in each linked platform (CircleCI and Netlify in this case) with the option of automatically triggering a rebuild or redeploy. This model mirrors what source control platforms provide today. When code is pushed to a branch, GitLab pushes those changes to the destination infrastructure such as AWS.

Measuring success

As an industry, we will have a strong signal that this category is going to be successful when developers treat it like they would a source control platform. As essential as code reviews through pull requests are in today’s software development life cycle, so too will be managing secrets at the cloud and platform level. From the collaborative features enabling distributed teams to work effectively together, to the automations that enable CICD workflows, there is a lot left to do.

Use a Universal Secrets Platform

My hope is that you as a developer walk away from this long-winded article looking to add a Universal Secrets Platform to your toolbox. It's a completely different way of thinking about managing secrets, but just like when GitHub first pioneered the notion of a 'pull request’, once you see the benefits, there's no turning back. Together let's make the internet a more secure place for the projects we work on and the users they serve.