Shannon Lietz has helped pioneer and codify much of the work that’s become known as DevSecOps. Over the last decade, she has continually sought how to better bridge the worlds of information security with what actually needs to be secured and who needs to be doing the securing. Shannon is currently VP of security at Adobe, which is the fifth largest software company by market capitalization. 

In this transcript of her 2022 DevOps Enterprise Summit presentation, she shows that even though the term DevSecOps is being widely used in our industry, we still have a long way to go to truly create the ideal interaction between information security and the rest of the organization. In this presentation, Shannon shares what she’s doing right now with this community. Specifically, her work with RAVE metrics. 

___

I’m really excited to be here at DevOps Enterprise Summit. It’s been a lifelong dream. I am here to share a little bit about my recent research and current research. As you all may know, I have been in this industry for a long, long time and I’m going to share with you today a little bit about RAVE metrics. So let’s RAVE. 

We’re going to measure software value and trust and talk a little bit about the overview of some of the work that I’ve been doing to pull it together. And then I have an ask for you at the end. So stay tuned. 

I’ve been in the industry so long that, honestly, I started out as a Dev. So as much as I’m a “security professional,” I would say I’ve just really become a DevSecOps professional over the course of my career. 

DevSecOps

So maybe you’ve heard about DevSecOps. I always ask people, have you heard of it? And what I find over the years is it went from a conversation at an ISACA presentation (you may not know what that is, but basically it’s a group out there that does information security and it’s a practitioner’s group) and I remember my first slides. I actually had a tortoise and a hare and I was explaining how the security industry needed to evolve. And so as much as folks here are really involved in DevOps, I believe that a lot of us are really trying to bring security into the forefront of software and make it much easier as well. 

So I’m sorry about DevSecOps, because the name does have a whole bunch of folks in DevOps kind of worried about that. But at the same time, I’m also not sorry because I am finding that over the course of the last 10 years, software has been increasingly getting better at doing security before it gets released.

And that means that we’re checking our software and making sure that it’s as resilient as possible. So that’s my plug for security. I actually have an interesting take on what I think has been happening in the security industry and DevOps and all these things. And so this talk is really going to be focused on more about measurement and some of the things I’ve learned. 

But I’m going to start you off with sort of the journey toward how I get to this point with this software metrics conversation? If you look back in 2014, the essence of all of this came from sitting down and realizing we were security folks and the developers were basically moving around some of those clunky clipboards that we had. And so we finally sat down and wrote down really what we needed to do to change. And it was like we need to lean in instead of say no.

I think at one point I got a T-shirt sent to me that said the word no on it with a period. And it was like that was the brand that was being sent around, that was what security was really all about, it had to be our way or the highway. 

In software development, that can really be a pain, if you will. Being a developer myself, I would say I know what it’s like to be sitting there trying to make something work and then being told, oh, by the way, you have to layer on all these different things to be able to make your software secure, capable, available at the same time that you’re just trying to figure out how to make it work for somebody and make it useful. 

So in 2014, I would say we kind of put this down, and it was a little bit of an experiment and at the same time it was a pretty good experiment, I think.

Now what was also really interesting is in 2014 we knew we needed to get data and security science. It was actually pretty expensive back then to try and do what people are doing these days with security capabilities and security science, if you will. Big data was pretty expensive. It’s actually gotten way cheaper. It’s become more commoditized over the years. 

And then this notion of business-driven security scores really getting to the point where we weren’t just saying, here’s a list of things you have to do, thousands of things you have to do, but really getting to the point where how can we summarize it and make it much more simple? And so I would say what came out of that 2014 realization has been many, many years, but one of the big most critical things is we’ve been putting all of the security capabilities into the CI/CD program.

We’ve been actually building things into the software pipeline. And at the end of the day, I think it’s been measurement that’s been the most critical and most necessary element of pulling people together. So why do I say that? And by the way, I find it to be extremely challenging to talk about security measurement and how you’re going to actually be part of the conversation of building software.

Metrics

So when it comes down to it, the reason behind this is metrics really create a little bit of that guiding light, that North Star, Measure What Matters, the John Doerr book, how do we actually start to determine what we’re going to do and how we’re going to solve problems? And so at the forefront for a security professional, we’re all trying to figure out how do we actually make this thing that’s really important, getting rid of adversaries in our software, taking away their advantage, taking away the attack surface, how do we really make that come to the forefront? And the idea behind this is that we could go focus on what we can measure.

The idea behind metrics is really interesting and unique, and what we can measure is often not what we should measu