The traditional solution of a siloed secrets manager that requires direct integration from every application appears to shine with its simplicity. But suppose the reality is a constant source of paper cuts and frustration for developers and DevOps teams due to a clunky UI dashboard and awkward to implement SDKs. In that case, it's negatively impacting how fast teams can ship software.
Or worse. The mandated secrets manager is a form of security theatre as the number of secrets stored is a mere fraction of the actual number of secrets in use across different clouds and platforms.
This article aims to reframe how you view secrets management by illustrating the fast-emerging "SecretOps approach to managing secrets.
In doing so, it should become clear why the traditional siloed approach is no longer adequate and is actually hurting your security posture by masking the true nature of how secrets are managed across your organization.
Platform Native Secret Stores and Language Agnostic Environment Variables
Is a siloed approach to secrets management truly outdated?
Take a look at a cross-section of modern infrastructure platforms such as Cloudflare Workers, Vercel, Netlify, and AWS Lambda, and there are two things they all have in common:
- They have a native secret store built into their platform.
- They use the language-agnostic solution of environment variables for injecting secrets at runtime.
Product teams are rewarded for shipping software fast, and developers are constantly looking for ways to be more productive, which in turn, makes writing code more enjoyable.
While no one would argue that security is not essential, adoption will always struggle in the face of perceived and unnecessary friction that is driven by compliance.
Therefore, given a choice between a platform-native secret store without the need for language-specific SDKs vs. a siloed secrets store that presents significantly more friction, it's not surprising developers will opt for the platform's offering if, in their eyes, security isn't compromised as a result.
SecretOps: An Infrastructure and Automation-Driven Approach
With SecretOps, the problems associated with siloed secrets, uncontrolled secrets sprawl across multiple clouds and platforms, and security theatre from the realization that your secrets manager is likely being bypassed for productivity gains can become a relic of the past.
SecretOps is built on six principles:
- Secrets Management is about developer productivity as security requirements should be table stakes.
- A hub-and-spoke model centralizes secrets management and storage while supporting automatic secrets syncing to any deployment platform (including other secrets managers).
- Because all secrets management activity is now centralized (eliminating manual updates at the platform level) audit and activity logs can finally and accurately present a complete picture of how every application organizes, syncs, and consumes secrets.
- A Secrets Manager is not just a Key-Value Store but organizes secrets as developers would expect: into discreet projects/applications with a customizable list of environments.
- Configuration and secrets should be combined to provide a single pane of glass view for how an application is configured in any environment.
- Shared secrets referencing allows a single secret change to instantly propagate and sync to every linked deployment platform.
SecretOps differs from traditional secrets management. It deeply understands the features Developers and DevOps teams need based on how modern software is developed, built, tested, deployed, and audited.
It embraces, not fights, the multi-cloud and platform world by syncing secrets to wherever developers need them to be, including support for other secrets managers.
SecretOps is doing for secrets management what GitHub did for Git repositories by building a flexible and developer-centric set of tools and automation workflows with a full-featured UI on top of the secrets storage layer.
Modern Secrets Management Requires a SecretOps Approach
While SecretOps may seem like a radical paradigm shift, it simply acknowledges the realities of modern-day software development and embraces how developers and DevOps need a secrets manager to function so that it works with them, not against them.
The rigid and locked-down strategy of siloed secrets may have worked in the past, but it's now clear that a SecretOps approach is required to remove security theatre, increase developer productivity, and confidently manage application config and secrets at scale.
Our vision for SecretOps Platform is to establish a new category of developer tooling to provide every developer, student, hobbyist, startup, and enterprise with the features they need to manage application secrets securely. And in minutes or a few hours, not days, weeks, or months.
That is our strategy for raising the security posture of any application, regardless of the language, framework, cloud or, platform.
If our vision resonates with you, then I'd encourage you to give a Doppler a try today.