Is DevSecOps a Thing...? Or, What is DevSecOps?

This is a 10 minute overview of what I think DevSecOps is, has become, etc. It was originally for an IDC Nordic conference.

Here's the transcript, apologies for the time codes:

Introduction - DevSecOps?

Well, thanks for having me here. I've been trying to figure out what DevSecOps means for a little bit, and I think I've finally settled on three things that it is. So what I want to do is go over what those things are, and also related a little bit to what DevOps is and why it's actually kind of justified to use that infix of DevSecOps. 

Kubernetes is driving interest in DevSecOps

So why is this relevant now? Well, I don't know about you, but every time I see a survey about people's barriers to using any technology, security is always relevant.

In fact, I think security is always in the top three, maybe even top two things that CIOs and people worry about the spend that they have, especially nowadays. So security is always relevant, but it's particularly relevant now because a lot of people are thinking about and building out their Kubernetes strategy.

Now, why, why are they doing this? Kubernetes is basically a great way of standardizing your infrastructure, whether it's in public cloud or on premise or edge devices, whatever the infrastructure is that you're building and running applications on, kubernetes is a great way to remove a lot of the toil, standardize, and make better that infrastructure.

So you're not dealing with a whole bunch of different types of infrastructure. That's what this idea of multi-cloud is. It's almost like the "write once run" anywhere thing from a while ago. But as you can see in our most recent survey, the state of Kubernetes survey security has risen up to be the number one thing that people are concerned about, which I think is totally valid.

Whenever you have a new technology, people don't know it, they haven't used it. They don't trust it. They've got to learn about it, and security is that thing most with the technology that, uh, and often because the security people come in later and, uh, you know, you're testing something out initially and now you need to harden it and make sure that it's secure. So it becomes the thing that people worry about most.

I think also what you see here is that, skills longer are the number one thing. And people have actually learned a, had to work with Kubernetes pretty well, which isn't encouraging. 

The Three Parts of DevSecOps

So as people are trying to investigate and make Kubernetes more secure, I think this is why this idea of DevSecOps becomes one important and also something that we can actually kind of define now.

And I think there's three important things to it, a secure software supply chain, which I always think is enjoyable when there's an adjective in front of something. I mean, I don't think anyone would ever want an unsecure software supply chain. We should just call it a software supply chain, but you know, secure kind of

underscores the secure part of it. And then there's the idea of the platform for security, thinking about security as a product, the technology is the automation that you're building around it. And that finally enables, uh, what's in the middle of this, this idea of a better culture of security, a culture that has more security involved in it and kind of tactically this idea of shifting left, which is a very DevOpsy idea.

Right. And we'll see how that, uh, that compares. 

Secure Software Supply Chain

So the first idea is a secure software supply chain. Now, what is the supply chain? A supply chain is just the further evolution of an automated build, a build pipeline, which is also further evolved into continuous delivery or continuous deployment - whatever you want to call it.

I know they're different, but like, we don't have to worry about that for now. Uh, but thinking beyond even CI/CD and as the supply chain name would think about, would say thinking about where the inputs for your build pipeline for your, your, your supply chain comes from. Right. And the important thing, when you start thinking about securing your supply chain is to write out, uh, you know, go find a big whiteboard or do it online or whatever.

But put out not only all the activities that it takes to think of some application and get it into production. And also all of the inputs, all of the third party, libraries and services, and also code that you write and also the configuration that you use throughout this. Also the tools that you're using, every single thing involved, the entire supply chain.

Think about all those activities, but also think about the arrows between those activities what's going on in those handoffs. Are there things that you're not accounting for there and as we'll get to, how long does it take between those handoffs and how porous are those things? And once you have this view, it's important to start thinking about securing and hardening that supply chain. 

Supply Chain Attacks

That's because along this whole supply chain, not just in each box, but even between the arrows, there's all sorts of ways that people can get in and that your security can be compromised. So you need to start thinking about once we've drawn that up there, how can we ensure that we're not opening ourselves up to these various types of attacks?

How do we make sure that we're not only securing each of the components in each of the areas. But also, how do we make sure we're not sacrificing actual productivity and just getting software out the door, right? You don't want security to be a blocker to the, getting the kind of weekly cycle of doing software that you see in good organizations nowadays, where they can get an feature out the door on a weekly basis so they can incrementally get more and more feedback about improving the software that they're doing.

You can't really block that kind of progress for security or, I mean, I guess you can, but it's really not going to help you out very much.

Security as a Platform

So part of how you get to that point is thinking about security as a, as a product. Now, this is where we build in the DevSecOps world on top of DevOps, quite a bit. Early on in DevOps, we had this idea of a DevOps as tools, as automation, and then that evolved into a lot of process and culture. And in the last couple of years, what you've really seen is that idea start building on site reliability engineering. And as you layer this Kubernetes layer to standardize your infrastructure, you get to the point where you can build a platform. 

Now we used to call this a platform as a service, but we don't really use that phrase. I don't know why, but people don't seem to like it. So you can just call it as platform. 

But you're building a platform that your developers are using kind of like you would be using services from public cloud or services from old Java app servers or what our internal enterprise architecture is that you have. But you have this set of services, not only the middleware and services that their applications rely on, but the build service that they use, the project management service that they use, the way of doing configuration for production, that they're using all of this type of stuff that's built into a plan. That essentially your developers use to automate a lot of the infrastructure, the configuration, the release management, the monitoring, to standardize that sort of stuff, so they can focus on what the application developers do best moving pixels around the screen, putting features in their applications.

Now, what does it mean, the, "as a product part"? Well, it means that instead of just providing services, infrastructure, even middleware and, uh, stuff like that to developers, you instead ake a new product management approach to them and investigate and discover what they need and come up with the best way of solving that problem.

You do what a product manager, what you do, what the application developers themselves are doing, will you study what's needed what the customer wants to do, developers in this case, and you come up with theories of the best way to provide it to them of the best way to do it. That makes them as efficient as possible, and also satisfies the needs that you have.

So, if you think about this in the security standpoint, a lot of this comes down to identifying what those desire paths are. As you can see here now, a desire path is essentially what you see this worn into any sort of landscape, uh, sort of a situation where you've originally designed paths to do one thing.

But over time, people discover the actual best way to use that path. They discover what they need, the fastest, most efficient way to go things, and they actually paint out by wearing through the grass, what the best pathway. Now for security, what this means is studying how you can make doing the right thing, the easiest thing for developers, adding in templates and defaults to the configuration that they're using, the packages that they're using, putting in guardrails, so it's very difficult for them to do things that are insecure. And Kubernetes can help out a lot here by enforcing things, uh, by enforcing, for example, a lot of networking configuration and just making it not possible to do bad things, but think about product managing, paying attention to how developers are functioning in the best way to do things for them.

And you build that into the platform. 

Shift Left

So this makes it possible to do that whole shift left thing, to start having security people and developers actually work with each other more, collaborate together more and be more empathetic with each other. 

Security people understand what it is, developers need to do. Developers start to understand security a little bit more. And the key thing here that we learned from dev is that shift left doesn't actually mean making developers responsible for operations or security, it means bringing those two roles together and giving them co-responsibility to just make things more secure, to make things run better.

And it really means having people collaborate and work together more, just like a good product manager works together well with developers and the customers of their products there. 

Bye, bye!

So that's a pretty quick overview of what I've discovered DevSecOps is, uh, and you know, there's all sorts of stuff.

If you're interested in, uh, other things like this that I work on, here's, here's a quick introduction on myself, places I've worked at. Uh, but with that, uh, thanks for having me and, uh, you know, it'd be great to hear how your DevSecOps stuff is going and, uh, good luck.