Introducing the Secrets Management Maturity Model
Secrets management has arguably become one of the most discussed DevOps topics in recent years. We've seen a lot of technical debates about how to find the best balance between security and flexibility, but none seems to have really cracked the problem with a definitive answer. The thing is, we are pretty sure such an answer doesn't exist.
Why? Because there is simply no one-size-fits-all.
But then, what are the best options on the table? We've seen (sometimes radically) different opinions on "the right way" to manage secrets: "you should always use a vault!", "encrypted secrets in git are not safe!", "long-lived secrets should be banned", and some more extreme "developers should never have to touch a secret". As you already know, this is not realistic. Secrets are used by all people & assets in modern software factories and show no sign of slowing down.
Getting a better idea of one organization's maturity regarding how secrets are managed, supervised, and protected against (involuntarily) leaks is paramount.
That is exactly the purpose of the Secrets Management Maturity Model, our new white paper, that you can download without filling out a form:
No time to read but still want to do a quick assessment of your posture on secrets? We've got just what you need! Take 5 minutes to answer this (free and anonymous) questionnaire, and you will get your maturity level plus a chart to see where your weaknesses and strengths are:
The Model: 4 attack surfaces considered
In our model, we acknowledge that the state of secrets management in modern software development shops is always a mixture of various ad-hoc solutions, that we can map to four major areas of the SDLC:
- Developer environment
- Source code management
- CI/CD pipeline & artifacts
- Runtime environments
From there, one is able to evaluate its current maturity on a five levels scale for each of these areas, and how it can move to the next level. Here is a view of the levels and their overall associated maturity:
Beyond the maturity model, a key takeaway from this document is that an effective secrets management process needs to address its failure modes: "What happens after a secret has leaked?", "How can we be sure that no secrets have leaked in the past?", 'What can we do to prevent them from leaking in the first place?" are some of the most important questions to ask for an organization wanting to improve its secrets security resilience.
Secrets are no different than other security processes, in that human error is–by a wide margin–the first cause behind security failures. Preparing for when (not if) a secret will be hard-coded somewhere across the development cycle must be part of the secrets management process.
We hope that this maturity model will be helpful for you to make sense of where you are and where you want to go to improve on secrets protection.
