Technically Speaking

Technology never slows down and to keep up, we've had to move to a more nimble DevOps workflow. With more complex software architecture, we break things down to microservices, use separate resources, containers, and take advantage of cloud technologies. These changes introduce new risks and increase the attack surface of our systems, which means our old, monolithic single perimeter security approach doesn't work. And with cyber security threats like ransomware and supply chain attacks becoming more common, how can we secure all the things, all the time?

00:36 — INTRO ANIMATION

DevSecOps is the next step in the DevOps evolution. Security can't just be tacked on at the end of things, it needs to be an integral consideration from the start. Essentially, we need all the teams in the pipeline to shift left. Shift left places and emphasis on security early in the software development life cycle, so that potential issues can be resolved before they become major problems. DevSecOps aims to enable secure apps without requiring developers to be security experts, while still including them in the security process. Let's talk to someone who has experience with both shift left and something that may seem more to the right of the software development process, like runtime security.

Hey Chris, how's it going?

It's going well, Liz. It's been a while and I was just thinking about DevSecOps and shift left security and I mean, I know there's a, there's an aspect to these words, where it feels like a buzzword, but you have a lot of experience in this space and I just thought I would, I would get your opinion on what are the key takeaway concepts in DevSecOps and shift left security?

So, if DevOps is all about making it really easy to deploy code quickly, we can't just sort of treat security as a sort of add on to the, to the end of that process. We can't be waiting for doing security patches just once a month, you know, or twice a month, we have to be, you know, applying security processes all the time continuously, just the same way that we do continuous testing.

We really have to think about everybody participating in building more secure code from the developer writing code through to the automated testing and, and even understanding what we put into production. You know, we have complicated applications, they're not monoliths, they're, they're broken apart into a collection of services. We're doing continuous delivery or continuous deployments. You know, what are some of those key spots in that pipeline that you look for, for security?

Yeah, so the first thing that I always mention when it comes to, you know, securing your CI/CD pipeline is building more secure code with your CI/CD pipeline, is vulnerability scanning, because it's very easy, there's plenty of tools out there, open source tools, that will scan your dependencies for known vulnerabilities. Making sure that you're using known base images that have been agreed between developers and the security team. Developers might want to have, you know, every bell and whistle in the base image, but from a security perspective, the smaller the images, the better, the smaller the attack surface, so getting an agreement on what really needs to be inside a base image is a really good, is often, it's a good best practice and checking that you're only using those approved base images is easy to automate. And then another thing that you would probably want to be thinking about is how you inject credentials and secrets because you don't want those secrets baked into images. Again, something you can check for automatically, but you do need, you might need the, a certain service might need a password or a token to be able to access a database. We need to get those in somehow and there are tools that can help you inject those secrets into images at runtime.

We're thinking about how we do these processes repeatedly across every service, that's a part of the application, so there's a complexity that's coming out of just the volume or the amount of work that you have to do and so I can understand how automation is really key in making this a part of everybody's job so that it scales as we put more and more code into production is, is really a core concept here in shifting left.

Yeah and it's essential, right? Because if we're going to ship code several times a day, then we can't just have security processes the old fashioned way. And also you brought up a really great point there about decomposing architectures into smaller components and services, because we can treat those services as things that we can secure in their own right and we know that we can take the developer's intention of what those services are supposed to do and turn that into security rules. So for example, if we think about network security, we can understand which components are supposed to speak to each other and which ones aren't supposed to speak to each other and use network policy to enforce that and, so for example, if you've got a product search component, you want that to be looking at your product database, but you really don't want your product search component talking to a payment gateway and being able to enforce that through network policy is really powerful for security.

Yeah, I think that that requires some definition, some policy, some declarative view of what it should look like and then some way to, to manage that at runtime, I'm curious what you think about the evolution. I mean, we're in this shift left world and we've introduced DevSecOps, they're not brand new concepts, they're starting to take, take foot. What do you see as the evolution of these concepts and what are the core technologies that you're excited about in this space?

Well, one thing that I'm really excited about is eBPF. So I'm sure, you know, Chris, eBPF makes, makes the kernel programmable, and we can use this for so many powerful things in terms of observability, spotting what may or may not be a malicious behavior, things like unexpected network connections, unexpected executables running in your environment and because we can see, using eBPF, we can see things from the kernel's perspective. We can see everything that's running on a system in a really performant way, And that's gonna be, I think, a really powerful basis for the next generation of security tools. I mean, some of these already exist today and I think we're going to see, with the kernels that support eBPF, becoming much more widespread in production use, people are going to be adopting those eBPF based networking and security and observability tools over the next, you know, year or two pretty prolifically.

I love that concept of having the observability built into the kernel, so you get to see everything that's happening across the system, combined with the programmability, so you could actually do some of the enforcement, so you create that relatively simple declarative policy. You have ways to observe the behavior and then enforce the policy that you've, that you've defined. In the end, we're taking all this, you know, complexity that we're developing by distributing the system, using simple tools to create really a more secure posture and build a better, more secure internet in the end. Really appreciate your time, Liz, this has been a great conversation.

My pleasure, Chris.

DevSecOps is all about infusing a security mindset to produce more secure code. But to really integrate security into the pipeline, this shift in mindset needs new technologies. With eBPF and runtime security, we're building technology to give us the visibility to detect and respond more quickly. And by sharing responsibility, establishing more secure workflows with automation, and being open and transparent in our code, we can begin to connect our runtime protections and secure development practices to improve software security everywhere.

09:11 — OUTRO ANIMATION