---
title: "Steve Springett -- Software and System Transparency"
url: https://appsecpodcast.com/steve-springett-software-and-system-transparency/
date: 2024-08-29
duration_seconds: 2893
season: 11
episode: 21
guests: ["Steve Springett"]
topics: ["Threat Modeling", "OWASP Projects", "Software Supply Chain"]
audio: https://www.buzzsprout.com/1730684/episodes/15658049-steve-springett-software-and-system-transparency.mp3
video: https://www.youtube.com/watch?v=-GKKpRIoRsI
transcript: true
---

# Steve Springett -- Software and System Transparency

*August 29, 2024 · 48 min · Season 11, episode 21*

with [Steve Springett](https://appsecpodcast.com/guests/steve-springett/)

on [Threat Modeling](https://appsecpodcast.com/topics/threat-modeling/), [OWASP Projects](https://appsecpodcast.com/topics/owasp-projects/), [Software Supply Chain](https://appsecpodcast.com/topics/supply-chain/)

[Audio](https://www.buzzsprout.com/1730684/episodes/15658049-steve-springett-software-and-system-transparency.mp3) · [Video](https://www.youtube.com/watch?v=-GKKpRIoRsI)

## Show notes

Steve Springett, an expert in secure software development and a key figure in several OWASP projects is back. Steve unpacks CycloneDX and the value proposition of various BOMs. He gives us a rundown of the BOM landscape and unveils some new BOM projects that will continue to unify the security industry. Steve is a seasoned guest of the show so we learn a bit more about Steve's hobbies, providing a personal glimpse into his life outside of technology. Steve Springett educates teams on the strategy and specifics of developing secure software. He practices security at every development lifecycle stage by leading sessions on threat modeling, secure architecture and design, static dynamic component analysis, offensive research, and defensive programming techniques.

Today's episode is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Our education platform teaches valuable secure coding skills based on real-world vulnerabilities and threats, including OWASP Top 10.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Steve Springett:  
→ [CycloneDX](https://cyclonedx.org/)  
→ [Software Transparency: Supply Chain Security in an Era of a Software-Driven Society](https://www.wiley.com/en-us/Software+Transparency%3A+Supply+Chain+Security+in+an+Era+of+a+Software-Driven+Society-p-9781394158492)

Mentioned in this episode:  
→ [CycloneDX](https://cyclonedx.org/)  
→ [Software Transparency: Supply Chain Security in an Era of a Software-Driven Society](https://www.wiley.com/en-us/Software+Transparency%3A+Supply+Chain+Security+in+an+Era+of+a+Software-Driven+Society-p-9781394158492)  
→ [JC Herz and Steve Springett -- SBOMs and software supply chain assurance](https://youtu.be/mc7_nTEX2h8)  
→ [OWASP Dependency-Track](https://dependencytrack.org/)  
→ [CycloneDX](https://owasp.org/www-project-cyclonedx/)  
→ [OWASP Foundation](https://owasp.org/)  
→ [Log4j](https://logging.apache.org/log4j/2.x/)  
→ [Apache Struts](https://struts.apache.org/)  
→ [Open Threat Model (OTM)](https://github.com/iriusrisk/OpenThreatModel)  
→ [OWASP Threat Dragon Project](https://owasp.org/www-project-threat-dragon/)  
→ [LINDDUN](https://linddun.org/)  
→ [PCI Security Standards Council](https://www.pcisecuritystandards.org/)  
→ [Software Transparency: Supply Chain Security in an Era of a Software-Driven Society by Chris Hughes, Tony Turner](https://www.wiley.com/en-us/Software+Transparency%3A+Supply+Chain+Security+in+an+Era+of+a+Software+Driven+Society-p-9781394158492)  
→ [OWASP Dependency-Check](https://owasp.org/www-project-dependency-check/)

Chapters:  
00:00 Meet Steve Springett: Software and System Transparency  
02:04 It's, uh, well, the City of Brotherly Love, isn't that what  
06:05 That's just, it's just another reminder that we all gotta find  
07:44 Um, Robert, where are we, where are we going with Steve  
11:00 And I think a lot of people in AppSec are going  
12:21 Right  
14:26 I'd love to get you kind of on the record giving  
19:08 Based on the Log4j, Log4Shell example, let's have it, let's, let's  
23:03 We've talked about some of the use cases, but are there  
24:52 We think about All of these different capabilities and different, I  
30:18 Let's say in relation to that transparency, but also, uh, commonalities  
33:19 I know you've been doing some work, Steve, on this idea  
36:32 I mean, it, it, I think if I, if I kind  
42:47 Okay. Yeah. So we have 3 questions. Do we, have we  
45:19 Last question, uh, what's your top book recommendation and why do

## Transcript

*7,863 words · assemblyai*

**0:00 Chris Romeo:** Steve Springett educates teams on the strategy and specifics of developing secure software. He practices security at every development lifecycle stage by leading sessions on threat modeling, secure architecture and design, static dynamic component analysis, offensive research, and defensive programming techniques. Steve is passionate about helping organizations identify and reduce risk in the software supply chain. He's an open source advocate who leads the OWASP Dependency Track project. the OWASP Software Component Verification Standard, and chairs the OWASP CycloneDX Core Working Group and ECMA International TC54. Steve also serves on the OWASP Foundation's Board of Directors, where he helps drive the foundation's continued growth in pursuit of its mission to make secure software a reality through open collaboration, education, and innovation. Steve joins us in unpacking CycloneDX and the value proposition of various He gives us a rundown of the BOM landscape and unveils some new projects that will continue unifying the security industry.

**1:05 Steve Springett:** Today's episode is brought to you by Security Journey. Our education platform teaches valuable secure coding skills based on real-world vulnerabilities and threats, including OWASP Top 10. Learn more at securityjourney.com.

**1:29 Chris Romeo:** Hey folks, welcome to another episode of the Application Security Podcast. My name is Chris Romeo. I'm the CEO of DaVinci, and as always, joined by my good friend, Robert Hurlbut. Hey, Robert.

**1:42 Robert Hurlbut:** Hey, Chris. Yeah, Robert Hurlbut. I'm a principal application security architect and threat modeling lead at Acquia. And as you said, always glad to be here to talk with you, as well as any guests that we have on our podcast.

**1:56 Chris Romeo:** Yeah. And I, uh, I hear you're stuck in Philadelphia.

**1:59 Robert Hurlbut:** I am.

**2:00 Chris Romeo:** Which is a great city. It is a great city.

**2:03 Robert Hurlbut:** It's, uh, well, the City of Brotherly Love, isn't that what they say?

**2:06 Steve Springett:** Yeah.

**2:06 Robert Hurlbut:** Or something like that way back when. Um, yeah, just on my way to Las Vegas for the conferences, uh, that they usually happen in the summer, uh, in the desert and, uh, got stuck here waiting for some flights. And so hopefully it'll be all Resolve, and I'll be out there.

**2:23 Chris Romeo:** The nature of travel. Yeah. This is why, like John Madden, I only travel by bus. For those people, most people, most of our listeners won't even get that, but if you get it, you get it. Okay, cool. Well, uh, we're joined by Steve Springett, who has been a, uh, a guest of the podcast a number of times, and I'm just gonna, just gonna rattle off the previous episodes so that folks can go back and check these out. Uh, his, Steve's first appearance was April 2018. We talked about dependency check and dependency track. And then August 2019, we did an insider's checklist for software composition analysis. And then January 2021, SBOMs and software supply chain assurance with JC Hurst, uh, and Steve as well. So, uh, that puts Steve in, I was telling him before we started recording, rarefied air. for Steve here because a 4th appearance on the show puts him in the same category with Jim Manico, Tanya Jenka, and I think maybe Adam. I have to go back and double Adam's show stuff.

**3:27 Robert Hurlbut:** I think so.

**3:27 Chris Romeo:** I think Adam as well.

**3:28 Robert Hurlbut:** Yeah.

**3:29 Chris Romeo:** So Steve, you're in, you're in with a rare group there of professionals. So, I mean, I'd love to be on that list with those folks.

**3:38 Steve Springett:** That'd be awesome. I am truly honored. So thank you, Chris. Thank you for Albert for for having me on. Uh, yeah, it's, uh, it's humbling to, uh, to be invited, uh, now the 4th time. So thank you.

**3:50 Chris Romeo:** So yeah, sure, sure. So we have a re— what we're calling our returning guest question because we can't ask your security origin story because we already know it. We want people to go back and listen to the April 2018 episode to, uh, to get a perspective on that. So, uh, my favorite question to ask people right now is what hobbies take you away from technology?

**4:10 Steve Springett:** I love this question because like a lot of AppSec or, you know, computer science folks, we, we sit in front of the computer for 8, 12 hours a day. Um, the things that I like to do, um, one of which involves a little bit of technology, I, I like to, I like to tweak my cars. So I'm big into cars. Uh, I'm big into F1. Um, you know, if I'm tweaking my own personal ride, um, You know, some modifications to the ECU might be necessary, but most of the modifications are gonna be mechanical, which I love. Um, I also love mechanical watches, right? Not because they are, you know, the most accurate ways of telling time, right? The technology is, is obsolete. But I, I have a, an immense appreciation for, you know, the craftsmanship that goes into designing something. polishing something, 200, 300 different small, tiny little parts come together and, um, and use basic laws of physics to semi-accurately tell the time. It's, it's an amazing thing, um, that, that I just love to, uh, to sink my time into and my wallet, unfortunately.

**5:21 Chris Romeo:** Uh, very cool. Very cool. So what is your, uh, what, what is your ride right now that you're super—

**5:28 Steve Springett:** I have an Alfa Romeo Giulia that I'm, uh, that I have. I love it. It's, uh, it's a great car. Um, I've, uh, I've done a lot of, um, both, um, you know, uh, electronic and, um, you know, mechanical things to it. Um, you know, new intake, new exhaust, new ECU, um, uh, a bunch of other stuff. I'm, I'm currently going to be working on an, uh, on an upgraded turbo. And, uh, a, a new downpipe for, for the ride. So, um, yeah, I love doing that sort of thing.

**6:02 Chris Romeo:** Very cool.

**6:04 Robert Hurlbut:** No, that's great.

**6:04 Chris Romeo:** That's just, it's just another reminder that we all gotta find something to do away from the keyboard to free our minds up and, and make us more creative. Uh, which, which Formula 1 team are you a fan of?

**6:18 Steve Springett:** Well, you know, I, I've been a big fan of Lewis Hamilton. 'Cause he, um, you know, he had underdog kind of upbringings and he, um, conquered those. And I can't remember how many world champions he's won. Uh, so yeah, I've been, uh, I've been following him, uh, through his journey through, uh, Mercedes, uh, Benz, uh, Petronas AMG, and, uh, now next year going to Ferrari. So it's, uh, it's gonna be, uh, it's gonna be interesting to kind of watch that transition and all the dynamics that, uh, on and off the court. Or on and off the, uh, the track and how that pans out. But yeah, looking forward to next season.

**6:55 Chris Romeo:** Cool. No, and I, I'm just, he's the, he's who I've been rooting for too since I got into F1. Uh, just because, yeah, I liked, I just thought he was a, he was an interesting character. And, uh, you know, I, I kind of, like a lot of Americans got into F1 through the Drive to Survive show on Netflix. I started watching, I'm like, this is pretty cool. These guys are just Incredible. And there's just all this fun stuff happening behind the scenes that you would never know unless you got there. So yeah, it's, uh, yeah, I can't wait for him to be, uh, see what he can do at Ferrari as well. So, all right, we should probably talk about security as much as we could probably talk about F1 for the rest of the time. Sounds like we're, Robert was nodding his head too. So, you know, uh, maybe that'll be a future podcast, the Nerd's Guide to F1 or something like that. That's a working title. Figured it out yet.

**7:43 Steve Springett:** So there you go.

**7:44 Chris Romeo:** Um, Robert, where are we, where are we going with Steve here today?

**7:46 Robert Hurlbut:** Well, yeah, we're going to talk about a few things here. Uh, so first off, uh, Steve, you know, one of the projects that you worked on is, uh, with is the, and on is the CycloneDX. And so for our listeners, what is CycloneDX?

**8:00 Steve Springett:** Uh, CycloneDX is a bill of materials standard. Um, that's basically what it is. If you want to inventory something, uh, typically software, hardware, services, Um, you know, you, you can, uh, do that with, with CycloneDX. Um, a lot of the, um, uh, unsexy, I guess, things in application security, it always comes down to inventory. What do you have? What do you want to protect type of thing? Um, if you don't know what you have, then it's kind of hard to, to, to do any kind of risk analysis on that. So CycloneDX really just helps you identify what is it that you have and do so in a standardized way.

**8:41 Chris Romeo:** So Steve, you were, you worked on Dependency Track first, right? Before CycloneDX. So was Dependency Track and the work that you did there, is that what kind of opened your eyes to the need to do CycloneDX? I'd love to get some of that background because I realized I've never asked you that question. I'm actually really curious how this came together.

**9:00 Steve Springett:** Yeah. Yeah. So, uh, back in around 2012 or so. I actually had a need to, uh, inventory the full stack of, of these server appliances that were my employer were, were selling into customer data centers, right? So I had to inventory the hardware, firmware, soft, you know, operating system, applications, libraries, et cetera, uh, all in, you know, a single application. Um, there wasn't really anything that was available that, that did what I needed. So, uh, I basically. Grabbed an intern and, uh, and we started building it and that eventually became the Dependency Track project. Um, but yeah, I had full stack requirements, um, dating back 12 years now. Um, and a lot of what we did with Dependency Track, the, the, the resulting data model essentially is what CycloneDX, um, originated from. So a lot of the ideas from CycloneDX originated from that. But even prior to Dependency Track, I was working, uh, back in 2008, um, on the ePedigree standard and the implementations of that. ePedigree was a, um, was, uh, it's, it's now defunct and nobody uses it. But at the time there was a, um, a, a, a need to both inventory and track the raw materials of everything that would go into the manufacturing and distribution of pharmaceuticals. And, uh, so a lot of what I learned about supply chain, uh, in terms of what to do and, and even what not to do in a specification, um, I learned a great deal from, uh, from that project. In fact, the project basically failed because it was too complicated to, uh, to implement. So, uh, you know, I, I learned a great deal in what not to do from standards development.

**10:59 Robert Hurlbut:** Yeah.

**10:59 Chris Romeo:** And, and I think a lot of people in AppSec are going to think that BOMs are a relatively new concept. And I remember being at Cisco back in around 2005, 2006, when I was doing government certification work. And BOMs were just a part of how Cisco built a product. Like you didn't manufacture a new product until the BOM was completely dialed in and it was this, this was a data structure, but it was really a document, I guess, in those days, or a series of data points. So it seems like, I guess, maybe, do you think BOMs kind of like what caused the, the twist in people taking something that probably has probably been around a lot longer than I can even imagine? It's probably a concept of manufacturing that's been around for a long time. Like what got people to make the twist and say, This is something that can make security better.

**11:54 Steve Springett:** Yeah, I, you know, manufacturing has used it. I know instances of formal BOM usage dating back to the '60s and '70s. Uh, I'm sure it's gone well beyond that though. Um, if you think about some of the early, uh, mechanical devices, I was actually watching a video on YouTube about some of, um, Lamborghini's very first tractors that they used to make.

**12:20 Robert Hurlbut:** Right?

**12:20 Steve Springett:** Because they started out doing farm equipment, right? And I guarantee you, if they, if they were building one after the next, after the next, they had some kind of inventory of what it is that they needed in order to build that thing, right? Uh, whether it was a formal document or not is kind of irrelevant, right? You, you had to have, you had to know what it is that you needed in order to build that resulting, uh, thing. Um, but yeah, they are, they are not new, right? Uh, other industries have been doing this for a very long time. Uh, the software industry is, is over the last couple of years, just getting around to, to doing some of these best practices. Um, there's some resistance because, you know, change is scary. Um, but, um, you know, I think in my opinion, it was a lot of the breaches that, uh, you know, were caused from some of the open source software. I mean, we all lived through Log4j, for example, Log4Shell.

**13:18 Robert Hurlbut:** Mm-hmm.

**13:19 Steve Springett:** Um, there were, you know, 10 years prior to that, there was the, you know, lots of vulnerabilities in Apache Struts, right? So it's, it's been a long time coming. And if I had to guess, it was kind of as a result of breach fatigue, really. I mean, we're constantly in, in whack-a-mole. Whack-a-mole is not a strategy, but if you know what it is that you have, right, at least you can kind of predict predict where you might actually have problems in the future, right? If I'm using Apache Struts today, uh, there may not necessarily be a vulnerability in it today, but based on past behavior, I guarantee you there's going to be one, you know, in the future, right? So you can kind of use that information to kind of predict, um, all the unplanned work that typically results from, from a lot of these things.

**14:08 Chris Romeo:** So I guess One of the things I've struggled with, with all of the BOM activity over the last number of years has really been understanding the value proposition. And I know I, I bumped into you at a conference 6, 9 months ago, and we had a conversation in the hallway about this topic too.

**14:26 Robert Hurlbut:** Yeah.

**14:26 Chris Romeo:** I'd love to get you kind of on the record giving, uh, breaking down the value proposition because I think you're the, you're one of the people who's in the center of this world that could probably best describe what it is. And so I'd love if you could just lay it out for me, like what's, what is the real value proposition of doing this thing and who gets the value from using BOMs?

**14:50 Steve Springett:** Yeah, that's, that's really interesting. I can put on multiple hats, right? I can put on my, my CycloneDX hat, my Dependency Track hat, my ServiceNow hat, all the hats, right? And it's really interesting because the value prop of bills of materials, first and foremost, is typically for the development organizations. You know, a lot of organizations use SCA tools, which is great. You know, unfortunately, SCA tools, they're really designed to identify risk. They're not really designed to identify an accurate inventory. If, if they, if the SCA tool is close enough, it's typically going to be good enough. But is that really good enough for a bill of material, right? Uh, when, when details matter, and as we all know in security, details actually do matter. Um, so number one benefit is, is absolutely for security teams because they get to not only assert what they have, But they get to correct it over time. I don't, I don't view generating bills of materials as a one-time thing. I actually view it as a, as a process, right? And, um, you know, you might generate a bill of material, but, you know, you might know a little bit more about this particular library, or maybe you've made some modifications to it and backported some security fixes, whatever the case is, right? You can actually, you can add that information to the bill of materials so that it's more accurate than what your SCA tool could ever ever generate. Um, so there's definitely value there. There's also value on the procurement side, right? If you are going to buy software, um, as part of the purchasing process, you might want to ask your vendor, hey, you know, give me a, give me your SBOM. And that will tell you a great deal about that organization and some of the security practices that that organization maybe does or does not do. Um, that's without even really analyzing the BOM, you know, in that much detail, right? Uh, that's not even really looking about all the vulnerabilities and stuff like that. So right off the bat, developers and procurement, but, you know, if you've ever gone to a lot of the OWASP conferences, right, for whatever reason, and I disagree with this notion, um, In, in a very big way. But, you know, most of the conferences and even the projects themselves are segmented into builders, breakers, defenders.

**17:27 Chris Romeo:** Mm-hmm.

**17:28 Steve Springett:** And, um, again, I, I hate boxing them up and it, it, it'll, it, that categorization eliminates so many stakeholders. It's, it's unbelievable. But builders, breakers, and defenders and Bills of materials have not been overly useful to defenders ever. Right. Um, and some of the stuff that we're trying to do in future versions of CycloneDX will hopefully change that. Uh, 'cause we want it to be more useful to defenders in their organization because, you know, again, we, uh, we've, we've all lived through Log4Shell and all these other things. If there are mechanisms that we can do that would make that kind of, uh, emergency exercise a little bit more tolerable, a little bit more, um, easy on the resources that you need to, to do that sort of thing, then I think that value will, will, will speak for itself. So I don't know, initially it's, it's, uh, again, developer and procurement. Um, I use it, uh, in my day job for M&A, right? So, uh, our legal teams use it for M&A as well, uh, getting licensed and that sort of thing. Um, and then of course, if they, if they could generate a bill of material, that, that tells you something. Um, also if they can generate one and, you know, you got dependencies that are 5, 6, 7, 8 years old, that also tells you something. Right? So, um, and that's without analyzing the vulnerabilities.

**19:07 Chris Romeo:** So based on the Log4j, Log4Shell example, let's have it, let's, let's play a little, a little, uh, kind of futuristic game for a second. Mm-hmm. And say, if, what would be different 2 to 3 years from now About dealing with an issue like Log4j, Log4Shell, if CycloneDX, all these different BOM standards that are kind of part of it were just massively used across our industry? Like what would the, what would the, and as I'm somebody who's did instant response for a number of years, so I know the pain of and hardship of you get the call at 2 o'clock in the morning and the whole world's falling apart and then you don't sleep for 48 hours because you're chasing things down. But, but in your mind, what, what, how would that be better? How, how would that be less painful for dealing with an issue like Log4j?

**20:06 Steve Springett:** Uh, I'll give you 2 answers. The first is probably the most obvious, and that's, you know, in the next couple of years, there's going to be more adoption. So a lot of the Log4Shell things that happened a few years ago, um, teams were just, you know, scrambling to find out where they were affected. Right? So just knowing where is a really good start. Um, CycloneDX, uh, is moving, you know, it started out as a bill of materials format, but if you look at all the capabilities of what it actually does, only about 35 to 40% is actually bill of material related. Everything else is more about software and system transparency. So it's, It's kind of evolving to, from a BOM standard to this, this transparency expression language. And one of the things that we are trying to work on in the next version, I think would be immensely helpful to defense teams. Uh, you mentioned, you know, scrambling, um, you know, at 2 AM, uh, 48 hours. Uh, and if you could represent, for example, for the defenders what the application does. And we're working on this thing called blueprints. And blueprints is a combination of 2 different things. One, it's architectural bill of materials. It's basically how is the thing architected at an abstract level, right? We're not trying to invent UML or anything like that. That's not what we're doing. But just knowing how something is architected, could be useful. The other part of blueprints is BOB, or bill of behaviors. What is the application supposed to do, right? And then you could also, um, uh, you could also represent, um, what it actually does and, and determine whether or not there's a, there's a delta there. So in the case of like Log4Shell, uh, Log4Shell, so you might have in the future, you might have a bill of material, you know, a CycloneDX BOM that you know, list all your components, but maybe it lists all the architecture and behaviors. And you know that maybe this is a microservice and that, uh, maybe it's got a vulnerable version of Log4j and, um, the application grabs user input from a REST API. It processes that input and persists it to a database, right? That's what it does. Uh, and maybe, maybe, uh, because that you've recognized that there's no input validation. in that step, now you dynamically put a WAF in front of that microservice as a temporary mitigating control while the development team actually patches that microservice, right? So that would be something that theoretically you could do in a future version of CycloneDX that would be beneficial to the defenders. That's our hope.

**23:03 Robert Hurlbut:** We've talked about some of the use cases, but are there other potential use cases for BOMs that, uh, we haven't covered?

**23:14 Steve Springett:** Oh, there's a ton. There's a ton. And we could, you know, we could spend hours just talking about those. But, um, you know, it's, it's really interesting. Um, you know, bills of materials are kind of a, a just one way to be transparent. And it really depends on what kind of role you have in your organization. Uh, do you care about, uh, licensing and intellectual property? Do you care about procurement use cases? Do you care about, you know, AppSec? Or do you care about operational security, right? You know, for operational security, I mean, it's really interesting because you talk about license management, but for operational security, you know, license management is actually a critical thing, right? So being able to represent like, Uh, not just open source licenses, right? Any BOM format can do that, but being able to represent the commercial licenses, right? Uh, what type of license is it? Is it a subscription? Is it perpetual? What happens to that thing when, when that license expires? Does it behave different? Is it a denial of service? Is it, you know, is it a lack of availability?

**24:24 Chris Romeo:** Right?

**24:25 Steve Springett:** These things actually matter. So, um, for operational security to We've got, you know, use cases for, what do you call it, for, you know, provenance in terms of like export control, right? There's all different kinds of use cases for bills of materials. And it, again, it really just depends on what hat you have in your respective organization.

**24:52 Chris Romeo:** When we think about All of these different capabilities and different, I want to call them BOM types, but I don't know if that's the right word, but we have things like SaaS BOM, CBOM for crypto, hardware BOM for hardware, MBOM, that might've been the machine learning one. I don't even remember what BOV stood for. You've got all of these different BOM types under CycloneDX. Why are, why does, why does that, why do we need so many different types of BOMs? Yeah.

**25:27 Steve Springett:** Yeah, that's, that's kind of an unfortunate reality. Um, you know, the rest of the world uses just the term BOM. And for whatever reason, the software industry, I don't know where it started, uh, and I'm not pointing fingers, but for whatever reason, the software industry says, well, we're going to use BOM, but we're going to call it SBOM. And, you know, NTIA and now CISA, they have really restricted um, conversations of bills of material mostly toward just the software components themselves. Right. And I think that's really unfortunate, right? When I designed Dependency Track 12 years ago, um, I had full stack requirements in mind, right? I was doing full stack stuff 12 years ago, um, using bills of materials essentially. Um, so it never really occurred to me that, you know, we should only limit it to maybe just software components, right? Um, but that's kind of the way the software industry has, has kind of moved, which is again, really unfortunate. We actually had to change the entire CycloneDX website, uh, to SBOM instead of BOM, uh, just for, uh, search engine optimization purposes, right? Just so we could be found by Google. Um, we had to move everything to SBOM and we have a bunch of data that tells us that our That our number, the amount of traffic went up significantly when we did that. Um, likewise, when people are searching for things like services to be able to represent in the BOM, they're calling those things these, these terms, right? Because it's, it's not software, it's services. Um, the reality is that software hasn't lived in a bubble in 2 decades or more, right? It relies on services from the internet. It relies on services from the environment. GPS, et cetera, right? Um, software is more than just the, the libraries and stuff that we depend on. It's the services, it's the runtime environment in which it's, it's executed. It's, um, it's the cryptography algorithms that are part of that. Um, so it's, it's the whole enchilada really. And, um, The interesting thing about, you know, all these different things, uh, SaaS BOM and CBOM and all these different things is that inside an organization, you actually do have people that wear these very specific hats. Um, so you might have, for example, you know, your DevOps team and maybe they care about the software. Maybe you have more of a product integration team that actually takes that software Uh, puts it on in some kind of firmware on a device and ships that device, right? You might actually have, um, you know, another team that does, um, you know, post-quantum cryptography readiness, right? So there's a lot of different teams that might care about different types of data. So we've kind of, um, kept with that type of BOM terminology. Uh, as unfortunate as it is, because these different roles in these different organizations are in fact searching for these things. In fact, uh, there is a draft of the NIST. Let's see if I can remember this, uh, 1838B, which is, again, it's in draft, but it's a, um, it's basically a document from NIST that talks about post-quantum cryptography readiness. And, um, you know, it mentions CBOM in there multiple times. And maps CBOM to, to SBOM for SSDF. Um, but it also mentions CycloneDX as one implementation of that, um, in the NIST documentation. And the roles that might be responsible for, uh, caring about cryptographic algorithms might, but not always, be different than the, the, the roles that might care about the software inventory. Um, but yeah, it does a lot of different things. Uh, you know, I think one of the things that we will probably end up doing as, as CycloneDX, again, it's kind of evolving from this bill of materials format to more of a transparency expression language, is, um, trying to, trying to get Google and some of the search engine optimization stuff, if we can take care of that while also kind of shifting the narrative from SBOM to software and system transparency, then I think that would be a huge win, right? That's, that's really what people are really interested in. Uh, SBOM is just one way to do that, but there's, there's a lot of different ways to be transparent.

**30:17 Robert Hurlbut:** And let's say in relation to that transparency, but also, uh, commonalities between these, all these BOM standards? I mean, how are, how are those expressed? How are those tracked and so forth? Uh, typically?

**30:34 Steve Springett:** Yeah, it's actually just one standard. So CycloneDX is the standard, right? Um, and these are, these are just basically capabilities, right? Um, and if you have, for example, if you have a CycloneDX BOM that only contains services, well, we call that a SaaS BOM. Or if you have a CycloneDX BOM that only contains cryptographic assets, you know, we call that a CBOM. Now, obviously you can have a CycloneDX BOM that has, you know, software and hardware and cryptography, right? You might actually want to represent maybe a crypto key, right? So you got the hardware, you got the software, you got the cryptographic algorithms, right? All on a little device. And you can represent everything, that full stack in, in CycloneDX in, in one document if you so choose. Um, but yeah, it has all these different capabilities. I think it's just a matter of. getting the messaging right while also appeasing the SEO gods. Um, because you can't do both, right? I can't, you know, switch the conversation to software transparency, um, and drop bills of materials or just focus on SBOM because all these other things would unfortunately just go by the wayside. So I think it's going to be an evolution of, of the narrative.

**31:45 Chris Romeo:** So software and system transparency. That's, I like that better than SBOM as a kind of a category.

**31:54 Steve Springett:** There's a, uh, yeah, there's actually a, um, that, that's what we called it when we, uh, we recently formed ECMA TC54, uh, last year. And, uh, so TC54 is basically the home of software and system transparency. CycloneDX is the very first Uh, international standard to come out of that effort, right? So it's, it's an ECMA standard, uh, that's, you know, elevated to the same level as like JavaScript or JSON. Um, so, which is, which is amazing, right? It's, it's, it's great. Um, and, um, but, uh, but yeah, that's, that's really the focus of that group is software and system transparency. CycloneDX is one of the things that we're working on, but we're working on other things, right? We're going to be working on package URL. That's going to be an international standard. Uh, VERS, which is the, uh, um, version range specification. That's going to be an international standard. We're working on a transparency exchange API or Project Koala, which is a way to share a lot of this information between different parties in the supply chain. That will eventually be an international standard. So yeah, I mean, the group itself is really focused on software and system transparency. CycloneDX is just one of, of many standards that will eventually come out of that group. But all these things are going to be designed essentially to work flawlessly with one another.

**33:19 Chris Romeo:** So I know you've been doing some work, Steve, on this idea of a threat model BOM. And so as I started digging into this idea, it just, I just got caught up in thinking, what's the difference between a BOM standard or a standard definition and then a file format? Yeah.

**33:39 Steve Springett:** format.

**33:40 Chris Romeo:** In the case of Threat Model Bomb specifically, close to my heart, you know, DaVinci's a threat modeling company. So as I'm trying to think about how this Threat Model Bomb would fit into something that seems like it could just be a file format, but I wanted to get your take on this about what, what I'm missing. I gotta be missing something here.

**33:58 Steve Springett:** Yeah, I, you know, I think this is one of the, um, areas of Maybe a little bit of confusion amongst, uh, amongst the community who may not necessarily be too like, uh, aware of how international standards are created. Uh, but a standard really is just a document. It is a human-readable document. They're boring as hell. Uh, the CycloneDX specification standard is like 600 pages. If you want to read it till your eyes bleed. You know, makes people freak out. Um, but then you have, you know, then you have like schemas in this case, right? Well, we have like a JSON schema, et cetera. And those are electronic interpretations of the standard, right? So you got the standard and then you got schemas that are the electronic interpretation of that standard. And then you have the implementations, which is like the libraries and whatnot. that actually support it. And, um, and then of course, if you output a file, well, that is, you know, that was produced by an implementation that was, you know, used the schema, which is the interpretation of that standard. So it's, the standard is a little bit more abstract. Um, the schema is a little less so the actual document and a valid document. Uh, thus file format is, um, is, is kind of more of the concrete implementation, if you will. Um, that's kind of a, an interesting concept to a lot of folks, especially the ones that are not necessarily involved too much in, in standards development, right? Um, but it's, um, it's something that's, it's, it's one of those, it's one of those things that's really important, especially when we're communicating like, um, Uh, you know, CycloneDX is a community developed project, right? It's part of the OWASP community. Anybody can do it. But then we have TC54, right? Which is ECMA. And that's, you have to be an ECMA member. And, you know, trying to clarify, well, this is really just for the standards geeks, right? If you care, if you care about that sort of thing, then, you know, TC54 is, is where you want to be. If you want to care about more of the schema and the, more of the less abstract way of, of, uh, you know, doing it, then, you know, work with the community. That's what the community does. Um, so yeah, I guess, I don't know. Does that answer your question, Chris?

**36:30 Robert Hurlbut:** Yeah, it's helpful.

**36:32 Chris Romeo:** I mean, it, it, I think if I, if I kind of read back what, what I took away from it, you've got a standard, you've got a schema, and you've got an ending file format. And they're all different levels of abstraction making their way down to where the rubber meets the road in the file format. So they're not, they're not opposed to each other. They're in fact supporting of each other. The file format represents the schema, which represents what the standard asks for. So am I on the right track?

**37:03 Steve Springett:** You got it. That is, uh, that is exactly right. And yeah, we, we did start on the threat modeling bill of material. It became, um, it became evident to me when we were working on the cryptography stuff. Now, the cryptography work, uh, was mostly led by, uh, the research, uh, team at IBM in Zurich. Um, and they actually forked CycloneDX version 1.4 several years ago. And we reached out to them and we eventually worked with them and kind of upstreamed streamed most of their changes with, with a bunch of other additions and whatnot into the proper, you know, CycloneDX 1, uh, what was it? 1.5 it went into or 1.6. I think it's 1.6. Um, anyway, um, a lot of that work came from there, but what was really interesting at that time was, well, we can represent vulnerabilities in CycloneDX, but most algorithms aren't vulnerable. Right? There's one or two, and there are records in the NVD for those. Uh, but most algorithms are just weak, right? And their use might surface various threats, right? So it became evident a couple of years ago that we really needed to kind of standardize how a lot of this information is captured. Um, we also simultaneously, we, uh, also in 1.6, we also delivered, um, the ability to represent standards and requirements. Again, in a, you know, we, we couldn't believe that there was really no general purpose electronic way of, of doing it, right? There's very industry specific ways. And then of course there's Word documents and PDFs and, and that sort of thing, right? If you go back to the PCI Security Standards Council, right, most of their stuff is all PDFs or Word documents. Um, and there was really no general, uh, machine-readable way to represent standards and requirements. So you put together, hey, we need to represent threats. We also need to represent standards and requirements because of all these other use cases that we have. And then it kind of made sense to start, you know, working on threat modeling because really when you start the threat model, you are essentially capturing inventory first. What is it that we're working on, right? Including, you know, maybe the systems and services, what kinds of information do we need to protect, what kind of data, data classifications, data stewards, et cetera. And if you can represent those threats and weaknesses, like we already need to do for cryptography, and if you can represent the behaviors, which we also need to represent for the defenders, and if you could also represent any kind of standards and requirements for each one of those things that are in your model, well, then you basically have the workings of a threat modeling bill of material, right? You're almost all the way there. There was some work from Irius Risk a while back called OTM, Open Threat Modeling Format. In fact, my employer, ServiceNow, we actually contributed OTM support back to the OWASP Threat Dragon project because we think OTM is fairly decent for what it does. But, you know, for mature threat modeling practices that may, you know, have multiple data flow diagrams, or maybe they have attack trees or some of these other kinds of things, well, those can't be represented in OTM, and it would take a lot of rework to be able to do it. So there was some, uh, some outreach from some of the vendors and open source projects, uh, to me personally about, hey, instead of maybe, you know, instead of improving upon OTM, maybe let's, let's put all this stuff in CycloneDX because you guys, you already have a lot of the stuff there and you're an international standard, or at the time we were becoming one. So it kind of made sense to you know, build upon a lot of the stuff that was already there. So we've been trying to get the threat modeling community together. And this is not just the security community, right? AI has really, I think, clarified to me the importance of privacy threat modeling. In fact, when we were at an onsite for my team in San Diego a few weeks ago, We actually did a, uh, an exercise with the Linden, uh, Go threat modeling cards. And it was fascinating because as security people, right, we started doing, uh, privacy-based threat modeling. It opened a lot of our eyes to some of the things that, you know, we, we, we saw things through a different lens and it was, it was a really great learning experience. But yeah, we're trying to align the entire threat modeling industry on, uh, on using a standardized format. We, we hope interoperability will be the first of many. great benefits to the threat modeling space. But, you know, we also hope that because this is a machine-readable format, we hope that with enough tools, some of the things that we typically do as human beings, because threat modeling is a manual process, hopefully some of this stuff can be automated in, you know, at some level, right? Not human thought, obviously, but What is it that we're working on? Yeah, that can absolutely be automated.

**42:35 Chris Romeo:** Cool. Yeah. And I think we, uh, we touched on the future, uh, in some previous questions. So I think, Robert, let's go right to the lightning round, put Steve in the hot seat, as we like to say.

**42:46 Robert Hurlbut:** Okay. Yeah. So we have 3 questions. Do we, have we asked you these before? I'm not, I can't remember in the other times. Okay. Well then, uh, if we have, we have, if not, we're going to do it. Uh, again, let's do it. Uh, so what's your most controversial opinion on application security and why do you hold this view?

**43:06 Steve Springett:** Oh, I don't know. I have a lot of controversial opinions. Uh, let's see. Um, you know, I, application security in my mind is, is, is nice, but what is an application, right? What's the boundary of an application? Uh, I don't know anymore. Um, what's, you know, I know it's about a label, but I'm, I'm a big fan of product security because at the end of the day, we're, we're shipping products to customers. Um, I don't know what an application is anymore, um, because the lines are too bloody fuzzy. And in some organizations, uh, they actually still delineate, you know, very clearly where the lines are. And, uh, that's, that's, that's, You know, that's basically just feeding into the anti-patterns in my, in my view. Okay.

**43:58 Robert Hurlbut:** Uh, the second one's definitely, uh, very relevant. I'm trying to get to one of these. Um, what would it say if you could display a single message on a billboard at the RSA or Black Hat conference?

**44:09 Steve Springett:** Oh, on a billboard. Uh, let's see. Uh, maybe escape your bubble, go to where your, your, your stakeholders are at. Right. I mean, Black Hat is, it's nothing but security, right? I mean, yeah, and you can learn some stuff there and same with RSA. Yeah, you can learn some stuff there, but you know, there's hundreds of conferences, uh, every single year. And it's amazing to me how most of these conferences have zero security, you know, folks actually attending them. I'll give you a really good example is, um, You know, you look at like SBOM, we were talking about SBOM all, all hour, right? And SBOM, if you go to any like, um, uh, CMDB, ITAM type conference, right? That's not really going to be a thing, right? And yet it's very, very relevant to what it is that they do, right? My employer does some of this, but as an industry, if the industry isn't aware of what the security folks are doing, What kind of impact are you going to have? So I guess my, my, my message to the bill on a billboard would be escape your bubble, go to where your stakeholders are at.

**45:18 Robert Hurlbut:** And last question, uh, what's your top book recommendation and why do you find it valuable?

**45:26 Steve Springett:** Oh, I don't know. Um, I might actually do a plug for Chris Hughes and Tony Turner's book. Um, not because I had part of it, I just think that it's a, It's a really excellent read for somebody who is, um, uh, getting into software supply chain security. It's an excellent read. It's, um, it's, it's very topical, obviously. And, uh, I think there's some, unlike a lot of other books, I think there's some really good nuggets that you can take away and practice at your respective organization after, after reading it.

**46:04 Robert Hurlbut:** Nice.

**46:05 Chris Romeo:** And both, uh, Tony and Chris are previous guests of the Application Security Podcast. Steve, we're coming to the end of our time here. What's a key takeaway or a call to action that you'd like to leave our audience with?

**46:18 Steve Springett:** Get involved, right? If, um, if you're into a project, if you're into an open source project, uh, if you're into a standard, uh, get involved with that thing. Um, if it's important to your organization, Um, you know, pay it forward, right? Get involved. A lot of the, um, you know, there's a lot of concern right now about open source sustainability. And if you find that your organization is really dependent on certain libraries or certain projects that produce these libraries, um, get involved with that, whether it's pull requests, documentation, financial contributions, whatever the case is, right? Uh, open source is, is a really interesting thing that kind of affects us all and we all kind of benefit from it. But, um, ultimately at the end of the day, most open source is contributed by people volunteering, uh, their free time for the, you know, for the goodness of their heart. So, um, get involved in these projects if they're important to you.

**47:18 Chris Romeo:** Very cool. Well, Steve, thanks for your 4th visit to the podcast. I look forward to the 5th. In the future. I'm not sure what it'll be we'll talk about, but there'll always be something that, uh, that we can discuss. And, and thank you to all you do, uh, for OWASP, both behind the scenes and as a member of board of directors. Appreciate, we know that, uh, there's a lot of hours that go in behind the scenes that people don't know about. And, uh, so we just appreciate all of your efforts to move our industry forward, whether that's, uh, software and system transparency, which is my new thing I'm going to use now. I'm never going to say the other 4-letter acronym again. I'm just gonna say, oh, I don't use that. It's, it's this new thing. But, um, yeah, always great to have you on the show to share your wisdom. You always have so much to share with us. So thank you for educating us and, and your wisdom, and we look forward to visit number 5.

**48:08 Steve Springett:** Chris, Robert, always a pleasure, man. Thank you so much.

---

Source: https://appsecpodcast.com/steve-springett-software-and-system-transparency/