[00:00:00] DJ Schleen: 

It was back in early 2017 when an annual tradition started in a hickory smoke filled lounge in San Francisco. I’d found myself at B-55 in the Marriott Marquis sitting around a large table after her day of presentations at the RSA Conference. 

Surrounding me were some of the originators of DevOps, thought leaders from the Rugged Movement, horseman from I am the Cavalry, innovators from the Chaos Engineering tribe.

…and at the head of the table was Shannon Lietz – the original gangster of DevSecOps. 

If you know anything about DevSecOps, you know who Shannon is. The DevSecOps manifesto? It’s directly from the technical mind of Shannon Lietz. How does she start? She began to develop an interest in agile development practices and the idea of . Integrating security into the development process decades ago, and she’s influenced the industry ever since. DevSecOps came out of the seeds of that idea.

A seemingly endless stream of Smoked Old Fashioneds made it to the table. 

The conversation? Passionate discussion about DevOps with Security, DevSecOps, Rugged Software. Where was it all going? Is it just the same thing? 

In what we all coined “The Smokey Lounge” friendship started between all of us. We didn’t know where this DevSecOps thing was going, but we all knew it would change everything…

And Shannon? She became one of my mentors and friends. She’s one of the most fascinating Women in Tech I’ve ever met, and shares the same values I do, dreams of a secure future, is a creator, and has a technical. Welcome back to daBOM.

Hey everybody. Welcome back to daBOM. I’m here with Shannon Lietz. How are you doing, Shannon? 

[00:01:50] Shannon Lietz:  

It’s so nice to see you again. I’m doing great. 

[00:01:53] DJ Schleen: 

You make me nervous talking to you because you’re just so damn smart. 

[00:01:57] Shannon Lietz:  

Come on now. 

[00:01:58] DJ Schleen: 

Hell yes, man. You’re like my mentor of DevSecOps. 

It’s been three years. We were talking earlier that COVID sort of got in the way of our annual RSAC meetup. 

[00:02:10] Shannon Lietz: 

I remember the last day that I went into COVID lockdown and it was like we were at RSAC, incredible, and then to think it’s been this many years since I’ve actually seen you in person.

[00:02:21] DJ Schleen: 

Yeah. I met you like six and a half years ago. We were talking about this thing that nobody had heard about, and of course we are the DevOps:Connect. It was at RSAC. People asked us, what are we doing talking about security at a DevOps conference because we were using this crazy term called DevSecOps.

 You’re the creator of devsecops.org. And when I think of you, I think DevSecOps, How did you get started with it? 

[00:02:47] Shannon Lietz:  

DevSecOps started for me, with my, changeover from being a security engineer in the early 2000, and agile came out. As a woman in tech, it was always hard to find a job at that time where I was going to get hired. 

I always had to take sort of the janitorial services of IT and security jobs. What was really interesting was, I also learned a few things about being a woman in tech and I realized I had to actually change over to an innovator. So instead of being somebody who was a commoditizer or a maintainer, I had to chase what was new and start to really spend my research energy there. 

Agile came out. Developers were starting to really, hit their rise. It was pretty clear to me that security was being left behind at that time. This is early 2000s. I was, working with Jeff Williams on a website, a leveling standard at the time, and doing some PCI-DSS and all of a sudden just became really clear to me that, my place in the universe was going to be closest to software development because I had been a software developer. It was going to be closest to security, where it originated. 

 Maybe 10-ish years later, I was watching all the Rugged stuff, trying to figure out what they meant by rugged software. I had worked with many of these folks in software security for years and years and sort of took a route into metrics during the period that they all took the turn into OWASP and some of those things.

 I was keeping pace with it. But when I had come back into it I realized we just hadn’t made much pace. It had been 10 years since I had started in that space. I kind of meandered through it, wondering if folks were going to move it forward. 

And then went through the Sony breach. Went through at ServiceNow. Got to Intuit. At Intuit, I realized that 4,500 developers was a bit of a daunting task to teach them how to do security. We were doing cloud security, AWS, all those things. I remember walking around the loop in the San Diego office area, talking to my then new boss and saying, I will love working on things here as long as it’s close to software security. I told him, I’m going to term it DevSecOps and within a few years it should be at the showroom floor of RSAC if I’m successful. And, here we are. 

[00:05:14] DJ Schleen: 

You talked about rugged software, the Calvary. Were you ever a member of I am the Calvary? 

[00:05:20] Shannon Lietz:  

I still want to be a member of I am the Calvary. Just to be clear.

I know it’s, it’s such a, I just dunno how to get in. Is there a handshake or like, what is it exactly? That’s what I’m always looking for. It’s like, is there a place I go to, secret, handshake, knock on the door. I love what I am the Calvary does. I think that it’s just a great movement and, big fan of Josh. 

[00:05:41] DJ Schleen: 

Yeah, I think we got a corner of Josh at, the Smokey Lounge there at RSAC, and, see if we can get a, that special handshake. 

You, know this is really cool. You’re a leader in the whole DevSecOps community. And now you’re talking about trust, so you’re leading again. 

Tell me what trust means. 

[00:06:01] Shannon Lietz:  

Software trust to me, was something that originated with DevSecOps. If you look back on the DevSecOps pipeline, back when I forecasted it, the way in which software developers move forward is they build value and we put a security pipeline right underneath it that said, we’re going to put in trust. We’re going to shift trust into the software development pipeline adding it to value.

 Really at that time, It became pretty apparent to me that the next 10 years after we got the security pipeline in place was going to be dedicated to software trust. How do we get to the point where we truly understand what we’re putting on our machines? How do we understand the value that’s being imparted, and how do we ensure that software stays part of our ecosystem, our humanity for a very long period of time? That’s all about the trust contracts that we originate early on in the software development pipeline, very much about unifying that software development pipeline so that we have trust contracts originating early, that developers understand the mechanics of what they’re putting into software, that they understand the maintenance requirements.

 I’ve spent the better part of the last seven-ish years, working on secure-ability and research and metrics, and all of a sudden to find with some of the work that Jezz Humble and Nicole Forsgren are working on around DORA, we need security metrics badly. We don’t just need security metrics. We need security metrics that can actually be rationalized across other metrics.

That’s essentially the beginning of what I think is the next 10 years for all of us. 

[00:07:41] DJ Schleen: 

This is where software bill materials comes in because it’s a definition of those trust contracts. How do you see this and software billing materials coming together, or billing materials in general, right? Because we can talk about software, we can talk about manufacturing. It’s all just an inventory at the end of the day.

 How does trust fit into that? 

[00:07:59] Shannon Lietz:  

I’m so excited about the Software Bill of Materials movement, and everything that’s going into it. The reason why is because as a developer, one of the things that you have to do is really figure out how you’re going to build something. What features are you going to put into your software? How are you going to solve human problems? How are you going to solve automation problems? 

 What’s been challenging over the last few decades in my career as a software developer, and remember, I’m always putting on that hat at night where I’m still building software, has been keeping track of those trust relationships, of the requirements of what I’m putting into software.

 What I believe is that software bill of materials is an amazing vehicle for us to start to originate on. What does it mean to really pull a component into your software? What does it mean to pull in a SaaS service to your software? What does it mean to pull in. even the work that you build. Let’s just say somebody builds a library and they’re putting it in and it’s the software that’s being developed in-house.

All of those things go into what it really means to keep that software valuable and trustworthy. It’s an amazing marriage, if you will, a Software Bill of Materials. An amazing marriage between value and trust that we’re just now seeing come to the forefront. 

 It’s also the reason why, folks have had this notion of, okay, so now we’re going to have Software Bill of Materials, so what do we do with these things?

They’re a really great start to understanding what it takes to build value, maintain that value, and ensure the integrity of your software long term. So that you can have a durable software trust and value proposition. Exactly. We’re constantly building software, we’re constantly scanning for vulnerabilities, and there’s two different things. There’s the things that are in our software, and then there’s the vulnerabilities or the VEX, BDRs and those kind of things that are part of it as well. 

[00:09:50] DJ Schleen: 

When you talk about transparency of a Software Bill of Materials you’re giving over to your vendors, your customers, that secret sauce that says, “Hey, this is what’s in my software. These are the decisions that I’ve made or my developers have made to bring this in.” Tell me a bit about how that works. You know what’s really going to be great? The Software Bill of Materials is going to give us this ability for a software developer to maybe slow down for a moment and plan what goes into their software and really make rationalized decisions around that process.

[00:10:27] Shannon Lietz:  

As an example, when you’re going to pick out some component part, let’s just say that you’re working on auth today. Do you really have the mindfulness of that auth component? Who wrote it? What are they doing with it? How are they updating that software frequently? How frequently if you were to have a bug in that software, whether it be a security bug or just a regular, plain old feature bug, or a usage bug, availability bug, whatever it might be. Let’s just say that that’s also part of that rationalization. 

Within the mechanics of software development, there’s sort of this notion of the tinkering that goes on when you’re trying to figure out how you’re going to do the new feature and you’re going to bring something in.

 As we get smarter and smarter about that process of creating this notion of what has to be trusted within my software and raise the bar a bit on trusted software. Really think about what does it mean to bring something onto your machine. 

Let’s just say that 80% of somebody’s software could not be updated effectively. Would you really want to have that on your machine if you knew it was that maybe vulnerable, or it could have a memory leak or it could be less available. Would you really want that as a consumer of that software? This is now where transparency and metrics sort of comes into the picture, if you will.

 If you don’t start with measurement, when you’re going to build something like, how many users am I going to support, or what’s my regular cadence of updating something? If you don’t start with that in mind as a developer, then you really won’t to achieve it. So then it’s somebody else’s problem. my belief is that we actually have to reimagine a little bit of software development by bringing metrics to the forefront. 

The software trust algorithm is all about what I call RAVE: Resilience, Adoption. Velocity Errors. And having RAVEable software, cool name, because now we want to rave about our software, right?

 I really believe that software trust has those four major components and pillars to it If your software’s not resilient, you’re not going to be excited. If no one’s adopting that software, it’s unlikely you’re going to do so too. Because it’s probably not going to be maintained well over time because there isn’t really any adoption associated with it. Velocity, where somebody’s just not passionate. You can see in velocity metrics whether you’ve got passionate contributors or not. And then there’s errors, right? Over time with those errors that are coming up, if you look at escape rate as an example of poor security hygiene. 

As we really get those to be in the forefront of how we talk about software and how we label our software with measurement. The Software Bill of Materials is a great vehicle for that. 

Let’s just say that you bring in a component part that doesn’t have a great RAVE score like, “Hey, the velocity’s low for this particular component”, meaning features are not coming up very fast. It’s very highly likely that that’s not a highly adopted component part. 

 I do think this is going to give us the fuel of the future to make it so we can build better value, that we’re actually unifying our efforts less fractionalization because people are differentiating to start their own thing. 

In reality, Software Bill of Materials is going to really pull things back together. People will actually start to work more with each other. And that it is things like, being measurable first. That’s going to help us with trying to find each other. 

[00:14:01] DJ Schleen: 

One of the things you can infer from a Software Bill of Materials is how many versions you’re behind. You might be three or four major versions behind in the component that you’re using, and what that tells me, just looking at that difference, is that you’re going to have a longer response time to remediation of those vulnerabilities or of those errors. 

 I noticed that you’re not saying the word vulnerability, you’re saying error. I like that because security is an attribute of quality. And vulnerability, if you say that, developers are going to look at that and say, well, I got features I’ve got to develop. I don’t have time to fix a vulnerability. Is SBOM becoming a transparency vehicle for trust for your consumers. From a CISA perspective, or the government wants these Software Bill of Materials. FDA is asking for Bill of Materials for medical devices. Is that going to give them value instantly and establish a trust, or is it just something that they’re going to take put on the desk and move on?

[00:15:02] Shannon Lietz:

I do think that Software Bill of Materials is the beginning of a method for consumers to really digest what they’re leveraging and to value it differently. The equation of software is that yes, you’re fast at building something, but it’s not resilient. It’s not well adopted yet. Or it has high error rates if you really have an imbalanced RAVE calculation I do think that consumers are going to notice more often. I am hoping to see customers of software start to want to understand RAVE associated with their software. You really cannot have great software without transparency and metrics associated with it. It’s that transformation of nutrition facts that came out that really took that label of all the things that were in a donut that turned it into, am I going to eat 25 of these, or half of one. 

[00:15:57] DJ Schleen: 

That whole nutrition label, Alan Friedman holds up that bag of Twinkies when he talks. We don’t have as consumers that direct line of communication with the manufacturer of that Twinkie or the manufacturer of the car. But now we do with software. Is that going to open up a can of worms? 

[00:16:15] Shannon Lietz:  

You know, it’s a really good question actually. I do think that consumers will start to make different choices over time.

 When you really look at the next generation and the one after that, that we’re not imparting on ourselves, currently, something that’s going to totally revolutionize maybe our generation. But the generations to come, they are starting to care more. You can talk to them and they want to know what’s being put on their machines.

 I saw something on Reddit. They’re far less likely to pirate software. Because what they’re really looking for is that they can trust something that they can actually pay for the value that’s in that software. What’s going to come of the SBOM, changes that are happening is that this is going to create the transparency for customers to vote with the money they are using to buy software. That the projects that they work on are going to become more valuable. And I think that’s going to allow us to really see more of, those fewer, better suppliers. This is going to cause people to maybe work on things differently, that it is going to create transformational change in our industry, especially around software.

 There’s a lot of really great innovators out there, and they build amazing libraries and they do amazing things. Big amazing software projects take a lot of people and they take better handoffs and they take better, durability managers that we have to have. The way I think about it is, yeah, it’s absolutely going to have a resounding effect and impact consumers. Unless we actually make it easier for them, they may not pay attention to it as much as we’d like them to until we do.

[00:17:53] DJ Schleen: 

You’ve been talking about fewer suppliers, better components, higher quality in your Wardly maps for years. This is a concept that you’re seeing come to fruition. this comes back down into putting it in front of them and, and they’re going to see, again, the hygiene behind what you’re doing. 

[00:18:11] Shannon Lietz:

Software Bill of Materials and adoption are going to sort of come together in a way that we’re going to see that transformation. So as an example for all the really well-versed security practitioners out there, it’s very likely those SBOMs are going to be immediately useful. They’re going to be like, “What do you have in the software? It doesn’t look like you’re doing these things.” 

The more we boil down a Software Bill of Materials into something that allows us to digest it, this is going to be an incredible change within the software industry.

[00:18:39] DJ Schleen: 

How do you think we measure the transformation? If we’re looking at companies having better hygiene, how will we measure that? Or are there any ideas that you might have around that? 

[00:18:50] Shannon Lietz:

Yeah, I do. I think that adoption’s going to be the first metric where you see, change happen. It’s a very leading indicator of, “Let me look at what’s in the Software Bill of Materials”. It’ll be very much about looking at, as an example, what your third parties are, what the fourth parties are. 

There’s a big advancement that’s going to come into this space of sort of third party management. Because folks are talking about that being supplier management, vendor management, open source. But they really don’t think about it being supply chain management I could imagine that as companies get way more versed in it, that they’re going to get more particular about what component parts. Just like what happened with Toyota when they wanted to increase the quality of their cars and they had good supply chain management. You could see they were choosing certain suppliers over others because the quality of those parts were actually higher and more advanced and they could actually rely and create durability associated with it. 

 The tools right now are allowing us to create the SBOM and parse the SBOM and use the SBOM. But the mechanics of the cultural change in revolution that’s about to happen of fewer, better suppliers is something that we don’t have yet.

I don’t think I’ve seen something where I say, “Oh, I understand what we’re going to do with those SBOMs, and I see clearly that it’s going to allow us to make better choices about who we’re working with.” But I do think you’re going to see that. 

I ultimately think the adoption metric’s going to be a first, where we’re going to see, folks navigating away from component parts that are not being maintained properly because they add so much friction into that SBOM. 

As the government starts to push on maybe quality metrics around SBOMs, where you need to be within 1, 2, 10 versions of something, right? You can’t be 20 years behind any longer on a component part. The other thing we have to keep in mind too, DJ is pinned versions. There are software developers out there that pin versions and keep to those versions on purpose. 

That’s going to be an interesting conundrum is what do we do? It’s a religious debate. Yeah. It is a very religious debate. What do you do with forks and how is that going to play out with SBOMs because a forked component is still originated from a, library that in the SBOM is going to be interesting.

So, how do you deal with SBOM forking. How do you deal with license changes and some of those things. There’s a lot that goes on, that we have not seen the beginning of. There’s a lot of thought leadership that has to be played out. 

[00:21:24] DJ Schleen: 

Yeah. It’s a, it’s a strange one, right?

Creation of these Bill of Materials is almost a commodity, We have the creation of SBOMs. We have the storage issue, which is another huge problem. We’re getting better at developers thinking about producing them internally, but then they just sit in S3 bucket and they do nothing. Where do you think leadership needs to happen to change that mentality?

 There’s the things that we produce and the things that we consume. How do we go about even starting down that path? 

[00:21:53] Shannon Lietz:

Yeah. I’m going to come back to RAVE again. When component parts are not being adopted for fear of velocity problems or error problems or resilience problems, you’re going to start to see some of this, transformation take shape.

 Let’s just say that you’ve got a high error rate in something. In particular that is going to be interesting. It’s going to be, you know, some of the VEX work that’s happening right now is, quite interesting from my perspective because error rates have escape rates associated with them, and it’s those escape rates that really we’re concerned about most.

So if we kind of come back around to what are you going to do with them and why are you going to store ’em, and why are they important? My belief is it ultimately comes back to developer productivity and velocity, the balance of why are SBOMs interesting. What does a developer really need. 

SBOMs are interesting to security folks or they’re interested in like what’s there and how do I actually leverage it and work with it? A lot of tools will be built out of that side of the house. Developers get the benefit. ..this is what’s really interesting. If you start to understand the mechanics of an SBOM and what you could really do with it, a developer now has a way to really create an understanding, a community understanding, of a component part. 

That brings you closer together with your other folks that are developing software because now everyone has an interesting way of consuming that software. 

As a developer myself on occasion, I would say velocity is important. Trying to figure out how to get something done and to do it with security in mind isn’t easy. But with the Software Bill of Materials, it becomes better because now you know, “Hey, I’m keeping track of a component part I’m good at. I know how to deal with it. I know that I can trust the originator of it. I know that every three weeks they come out with a new update. I don’t need a ticket from somebody else because actually I can keep track of what my commitment was from the trust that’s going to originate from these things.” 

The future is all about what a developer can actually do with an SBOM. It’s their ability to be able to rave about their software that consumers are going to care about, that the value that they’re creating now has to be trusted value, not just value. Not just, I’m solving your problem and I’m leaving a whole bunch of things to the table. Quite often you see in all the tools that are out there for some of the developer security stuff that, the vendors are not able to get to everything. So there’s still a lot of glue code that has to take place between one part of the CICD pipeline and another. That glue code that’s being placed into this is where you might see debt or features couldn’t be created yet or whatever it was. But really, it’s because that particular use case hasn’t been fully solved. SBOMs are going to allow us to fully look at what it takes to solve a problem end-to-end in a process perspective, and to understand now who’s really helping to solve these problems and to be able to value that.

[00:24:51] DJ Schleen: 

Are we dealing with a inventory problem or a security problem. There’s different use cases for both. I’ve been been involved in projects lately that we’re looking at the inventory issue. Hey, we have Log4j. Where is it in our application? Where is it in our vendor software? What versions are we using? 

The other problem is identifying where these things are and specific layers. So it really helps pinpoint locations of things, and it’s a consolidated view. But you see this from a developer perspective as well, where you’re helping them make better choices of understanding where they’re coming from, what they’re doing.

[00:25:26] Shannon Lietz:

Yeah, definitely. The security side has their use cases. The developer side is still trying to figure it out. In fact, most don’t even know what an SBOM is or why they have to do it yet, because it’s coming and originating from the cybersecurity side. We’ve got to bridge that gap pretty quick and start to really have folks understand the benefits of those SBOM. The developer tools really have to start to create and bake in the, the use. 

[00:25:52] DJ Schleen: 

When it comes to these Software Bill of Materials too. It’s not just SCA. SCA vendors will generate a lot of, these SBOM components and they might try to generate like a BDR or a VEX…. 

[00:26:05] Shannon Lietz:

Yeah, they’re useful and incredibly useful. I think it’s just we don’t have the tools yet to fully consume and leverage. Again, like I said, how do you boil it down? I would say the one thing SBOMs do for us is it’s at the very detail level of the universe, if you will. The problem space is that the decision makers at the very top of that, decision space and we’ve got to find a way to actually allow for folks to get the detail and the granularity, but find a method for rolling it up so that we actually can get the trust associated with it out of these artifacts. 

[00:26:39] DJ Schleen: 

Cool. Well Shannon, thank you for joining us on the program today. I have a one final question for you. How do we get more information on RAVE? 

[00:26:49] Shannon Lietz:

You can go to rave.community and there’s a survey out right now that we’re taking information on what’s happening in your areas. If you want to share a little bit about your metrics and which ones you can, consider to be great.

Right now we have some, front runners in each one of the RAVE pillars and I think it’s going to be really neat to see how this continues to evolve over the next few months. 

[00:27:20] DJ Schleen: 

This episode of daBOM was created by me, DJ Schleen, with help from sound engineer Pokie Huang and Executive Producer Mark Miller. This show is recorded in Golden, Colorado, and is part of the Sourced Podcast Network. We use Captivate.fm as our distribution platform and Descript for spoken text editing.

You can subscribe to daBom on your favorite podcast platform. We’re going to be releasing a new episode every Tuesday at 9:00 AM. I’ll see you next week as we continue to diffuse daBOM.

CycloneDX Project
SPEX Project
Dependency Tracker
OWASP
Sonatype