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.
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:
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.
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:
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.
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.