Shannon Lietz is widely recognized as the progenitor of the DevSecOps movement and is the founder and principal member of DevSecOps.org. She is an award-winning innovator pursuing advanced security defenses and next-generation security solutions. Lietz is currently the DevSecOps Leader for Intuit where she is responsible for setting and driving the company’s DevSecOps and cloud security strategy, roadmap and implementation.
Helen: Can you remember when you started thinking or saying ‘DevSecOps’ and why?
Shannon: I was thinking DevSecOps for a long time. Agile hit the security industry by relative surprise, just before 2010. I’ve worked at pretty progressive companies, like Sony PlayStation, which even back then was a very agile environment. And traditional security just wasn’t working there. It was around then that I started thinking about DevSecOps. The idea of connecting security, agile and DevOps and working more progressively has been in my blood for a long time. I’ve been pioneering security concepts my whole career, so I just decided to call it what it is and bought the domain devsecops.org and we wrote a manifesto. It’s been a journey ever since and there’s still a lot to learn in this space.
Helen: When you stood up devsecops.org what was your vision and has it changed at all over time?
Shannon: It has changed but it’s always been about distributing security to the decision-makers. When I look at some of the modern-day programming languages I see that the concepts are not quite there from a security perspective. We see more and more vendors rising up because they find these security problems. It’s been a kind of bolt-on strategy for quite some time. My vision for it has always been about solving probably the biggest and most core problem, which is about how to measure security.
We’ve spent a lot of time thinking about a metric that we can get comfortable with, not just having dashboards with a hundred different measures and inputs to try and Ouija board whether or not you’re doing the right thing, but something that really moves the needle. I’ve been working on something I call securability. We look at all the other -ilities like availability, reliability and concepts like site reliability engineering and start to ask ourselves if we too should have a metric. When I first started with DevSecOps I realized that, as a security practitioner, I had to do things differently. Now, years later, we’re operating in the cloud. It’s forced us to change and do things differently. There’s a lot of technology available now, like Snyk, that I think was inspired by some of the things that we learned.
Being at the forefront of all these changes and cloud and DevOps was grueling at first, but now I’m seeing that more technology is available to make it possible for developers to have some of these tools at their fingertips. GitHub just recently acquired Semmle which helps developers bake in more security so that they can write better code at the beginning of the software development journey, for example.
Helen: What is a key KPI? Or does it vary massively from organization to organization?
No, I don’t think it varies. If you’re managing your exploitability from design all the way through your pipeline and you’re thinking about how you minimize your exploitable attack surface, you’re going to have fewer escapes, which means you’re going to have less potential breaches and you’re going to have fewer opportunities for compromise. All of that gets handled by simply thinking about things like: is the decision I’m making to run fast and leave XYZ control behind the right one for my business at this time? Developers make those decisions all the time in every organization and what we need them to start thinking about is whether there’s a potential exploit. It’s that simple in my view. We’ve maybe even over complicated the concept of exploitability and that’s caused a lot of the churn. The notion of default safety and security has to become a thing.
Helen: How do you define DevSecOps?
Shannon: There’s a very crisp definition that I posted. The elevator pitch for it is bringing security to the right context for good decisions for making software safer sooner. I’ve also heard things like ‘shift left’. I wrote a shift left article. Everybody’s trying to grapple with what it really means; some people have called it built-in security and there is the built-in security maturity model BSIMM. Ultimately DevSecOps is a rallying cry for software safer sooner.
And it’s not vendor led; it’s a community-driven set of practices. There are a lot of things that people do, like bringing all of the security scanning capabilities into the CI/CD pipeline. That’s been probably the biggest change that I’ve seen—that you’re no longer seeing security practitioners trying to scan code and go out and do things that are separate from the software development and delivery process.
Helen: How do you differentiate between Rugged Software and DevSecOps?
Shannon: I’ve always favored not reinventing the wheel. It’s really hard to pioneer anything. There’s always a way of looking at something and asking what you can learn from it, inspecting the context of what you’re doing and asking what’s different. I kept asking what Rugged DevOps and Rugged Software was and we downloaded the materials and tried to apply some of the principles but we found ourselves stuck. What we realized was there was a lot of security technology out there that developers were unaware of. It wasn’t lining up against their pipeline—security seemed to be fifty steps below the software development life cycle (SDLC). For me, the difference between Rugged and DevSecOps is the idea that security technology can be pulled into the development path.
They had the same concept in general but we added more implementation detail. There were lots of places where we intersected. I’ve gone to Rugged DevOps conferences and even crossed out DevSecOps. I don’t need to ever feel like the thing that we coined has to be the concept, but I absolutely want to see things get better. The Rugged DevOps crew, they’re amazing and pioneers in their own right. But I guess when we went to practice whether what they were saying would work, it just didn’t help us as much as we needed. Maybe they weren’t working with cloud capabilities yet. At the time that they invented some of this, Amazon didn’t even have some of the security features that we started with. Maybe it’s a combination of timing and concept or maybe we’re all doing the same thing by different names.
Helen: When I see people and organizations on these journeys to adopt new ways of working, they start with agile and then adopt DevOps and then they incorporate DevSecOps. Are those the steps you see?
Shannon: I’ve seen different companies do different things. Agile does absolutely lead to DevOps. DevOps leads to cloud. To do cloud well you’re basically moving from a traditional data center model, which has a laid down set of standards and paths, to something that has to be more baked in. You’re starting to see things like security as code. The biggest transformational change in that path is when you start to give developers the power to deploy at the speed and scale they want in order to solve customer problems. DevSecOps solves for the fact that you can’t apply traditional security programs to a continuous delivery environment.
Then there’s the notion of point-in-time audits and the things that happen around compliance programs. I’m yet to see regulators and standards bodies really understanding what it takes to create compliance programs in this space. You’re starting to see DevOps practitioners realizing that one of the things that really gets them in a tangle is when they get something like the concept of segregation of duties dropped in the middle of their process. Over the next few years, we’ll see more advances in the compliance space, such as how things like PCI and ISO are addressed in a DevSecOps world.
Helen: What do you say to people who say: “Oh, we can’t be compliant if we go to DevOps because of segregation of duties.” What’s the model they need to consider?
Shannon: When we have big hardware environments that are long-lived and we build out logging and monitoring it’s all really based on laying down a kind of grid. When you move over to an environment that may last thirty minutes at a time and you start looking at Kubernetes, it lasts for a transaction. Then those paradigms, like segregation of duties, aren’t really applicable anymore. You end up moving into more of a coded environment where now somebody auditing will actually have read the code and understand how the transactions should flow. They’ll need to understand the design that the developer had in mind and their intent and implementation behind it. That’s a very different model. So, instead of having segregation of duties, you have these two pizza teams where microservices is actually the risk model. I don’t think we have any compliance paradigms yet that apply to that model.