I’ve been trying to figure out what exactly the Sec in DevSecOps is for a couple years or so, and I think I’ve got something. Three things in fact. Keep in mind that DevSecOps isn’t all of security, it’s just a small subset that focuses on the software you write and run.
Anyhow, here’s the first.
A “secure software supply chain.” That’s a fancy word for trusting and validating the code goes into your apps, the builds. This is code your write, other services you use, and nowadays external services you might rely on. Not only that, but the tools that you and your developers use to put together the apps. Source control, collaboration, and project management tools: everything is a target!
To figure out what to do here, chart out every single activity that happens from idea to coding to a person using that feature. What are you doing to secure each step? And pay close attention to the arrows in between the boxes, that’s where a lot gets hidden.
Once you’ve verified this, you’ll need to document it and make sure it obeys the policies you have in place. Most all organizations have their own security policy and also external policy, such as laws and regulations, they need to follow. You’ve got to document it!
Here is the transcript:
I’ve been trying to figure out exactly what DevSecOps is for a couple of years now, and I think maybe I’ve got a good idea of it. There’s three parts to it.
Secure Software Supply Chain
The first one is a secure software supply chain. Now this is just a fancy word for saying that you trust the entire process of your software being built. This can go all the way back to specifying what it looks like. Definitely writing the code and compiling it, verifying the third-party libraries, you use don’t have any problems in them and fit to the policy that you have, but also looking at the configuration and the deployment things that you have.
Now, what’s important to pay attention to here, I think, are what I like to think of as the arrows between the boxes and this is where the idea of a secure software supply chain is something different than what we traditionally do.
And that says that you look at this entire chain, the activities, the boxes that are occurring, but then also the handoffs between them. When you move, for example, the code you’ve built the finished application over to testing, and then you move it from testing over to production and knowing that nothing changes outside of what you want to and that means that you still trust and have verified this code as it moves through that supply chain.
Now, this also means that the third-party libraries that you depend on you verified and trusted and are compliant with your policy.
The other important part to think about, and again, you have this wider view of everything every activity that it takes to build your code is to think about and check on and verify and trust the tools that you’re using, whether it’s version control , even project management tools, the registries that you’re pulling third-party components from, but you need to also look at that part of your supply chain and ensure that you trust it.
Also, this means that you need to be able to trust third party services that you use – services that you might use in the public cloud or wherever else.
The idea of a secure software supply chain is that security problems can happen anywhere in the life of the application, not just when the application is running and even not only when you’re using third-party libraries or if your developers have put bugs in there that are security problems, but the whole process of creating the tools around using it, how it’s configured and deployed. The scope that you’re looking at with DevSecOps is all of that supply chain.
There’s more, of course, including the other two things. To check it out look at a write-up that I did recently on DevSecOps, which you can click on wherever the clicking might be, or you can go to TanzuTalk.com/videos to read that write up.