00:00:02

Two years ago, I discovered a DevSecOps maturity model created by Navin VBar inside one of the world's most innovative organizations, the US government. This one came with a special twist, though. You see, Navin didn't start with a picture of a destination, nor did an event start with a minimum requirements for DevSecOps. Instead, he started with a picture of where his organization stood at that very moment. You see, some people had the mindset that we're already doing DevSecOps security is already baked into our development and our operations practices. But Navin started with seven important words, not considered viable for a DevSecOps platform. It was an important observation on the current state of their practices in a key differentiator. You see these seven words that they used said, this is where we are, this is what we're doing, this is what we've implemented, but this is not yet DevSecOps.

00:01:12

For example, let's look at level one patch management. So patch management, this state is manual. It's not enforceable. The patch states are undiscoverable, but there it hangs at the top, not considered viable for a DevSecOps platform. By contrast, level two says security informs application. Owners of patches and application owners are responsible for updating, being aware of and implementing those patches. At level three applications, uh, application owners are automatically notified of the patches. And at level four, the platform is automatically checking for those patches or testing those patches. Now, the cool thing about this is the model was not a technology roadmap. The twist was, it was a communications tool. They used it to say, you are building some, you've built something like this. But we want that. The model validated the current state, that the current state was something that security and development and operations were intertwined.

00:02:25

They just weren't yet DevSecOps. So the cool thing about this model is it goes through 11 different disciplines and within those disciplines, patch management, change management, asset management, availability management, finance management, and other disciplines, each one of these disciplines was described by different levels. Level one, level two, level three, sometimes level four. But level one was always considered, not considered viable for a DevSecOps platform. The model that they developed focused on success metrics of repeatability, low redundancy, and high collaboration. It also focused or emphasized automation and auditability. So it said that we wanna prize these over subjective decision making. And in fact, any decisions that qualified what would be a successful release had to be codified in code. Now, this DevSecOps maturity model also shared high value metrics, metrics that, uh, define business needs and compliance requirements. And this is how they measured whether they were being successful or not.

00:03:44

Now, this model is freely available on the GSA website today, and it can be very helpful to any of your organizations, but it's not the only DevSecOps maturity model that's out there. In fact, there are others that I've gone and collected over the years that your organization might be able to use that tell you, this is where we are, this is what we've doing, this is what we're doing, this is where we're heading, this is how we measure ourselves. So I know every one of you wants a hold of this maturity model. So I've sent my out of office email to respond to each of you. If you send an email toWeeks@sonotype.com right now, you don't need a thank you or anything. It will send you all the links to Navin model and the other models that I've shared here that you can use in your own organization. But I'm gonna leave you with seven words to help not considered viable for a DevOps platform. How can you use these words in your organization to get to the next level of your journey or your transformation? I'm Derek Weeks. Thank you.