Steve Springett — An insiders checklist for Software Composition Analysis

0:01Chris RomeoSteve Springett is a technologist, husband, father, entrepreneur, and tequila aficionado. He's the creator of the OWASP Dependency Track and CycloneDX spec. In this conversation, we begin with the problem of software supply chain risk and the failures of commercial software composition analysis tools. We then go through an extensive list of criteria for purchasing an SCA tool. I've never seen a list like this ever shared anywhere else in the industry. Steve's definitely an insider and in the know when it comes to these types of tools, and this is a detailed checklist of what he looks for when he purchases a software composition analysis tool. We end with a 60-second update on DependencyTrack.

0:45Robert HurlbutThis one's a little longer than normal, but I think you'll find it's worth it. We hope you enjoy.

0:49Chris RomeoSecurity Journey and the Application Security Podcast are attending Global AppSec DC. Stop by our booth to talk about the podcast or participate in our Battle of the Black Belts laptop sticker contest. We've created unique and amusing stickers, and every few hours we'll have a new battle going on. Just to give you some perspective, the first battle is Daniel versus Johnny from The Karate Kid with a bit of security humor thrown in. If you stop by, we'll even provide you a demo of our culture-influencing Security Belt Program that your developers will love. We look forward to connecting with you at the OWASP Global AppSec DC.

1:39Robert HurlbutThe Application Security Podcast. Here we go.

2:03Chris RomeoHey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey and co-host of said podcast. I'm also joined today by Robert.

2:14Robert HurlbutHey Robert, how's it going?

2:15Steve SpringettHey, Chris, really good to be here.

2:17Robert HurlbutAnd Robert, what is the title that you are going by these days?

2:22Steve SpringettOh yes, of course, Threat Modeling Architect.

2:25Robert HurlbutAll right, and today we are joined by a guest who has been on the podcast before, and if you are in the world of OWASP to any degree, then you know who Steve Springett is. And so we're excited to have Steve back, and right before we jump in and, and get into the conversation, I'll mention that Steve first appeared on the podcast in season 3, episode 13, where he described Dependency Check and Dependency Track. And so, if you want to get his backstory, that's where you can find it. Today, we're going to jump in. Hey, Steve, thanks for joining us again.

2:59Steve SpringettHey, thanks for having me. Glad to be here.

3:02Robert HurlbutSo, we want to dive right into the software supply chain deep end. And so, I thought, Steve, we could just start by level setting what is the problem that we're actually dealing with here when we talk about software supply chain risk? What does that even mean?

3:19Steve SpringettYeah, it could be a lot of different things, but if for organizations that are building their own software, software is no longer produced, you know, in a way where they're writing every single bit of code. Software is produced using building blocks, using open source and third-party components that already exist that you can leverage and build upon to create something new. So it allows organizations to get to the market faster by reusing a bunch of these components that already exist. And when we're talking about supply chain, incorporating all these third-party and open-source components into your application, you as an organization are essentially taking on risk for software that you didn't write. So that's— for organizations that are building their own applications, whether it's for internal use or cloud offerings, or maybe the application is delivered to somebody else. That's really what we're talking about when we're talking about supply chain. It can mean all kinds of other things as well, to the point where how is a developer actually producing that software, to all kinds of other things. But for the sake of this conversation, I think we're just going to stick with— Yeah.

4:40Robert HurlbutYeah, and it's important, I think, for folks to realize that while all the thinking and solutions and things for software supply chain are relatively new, meaning in the last 5, 7 years is when those solutions have come to the forefront, the general idea of supply chain has existed as long as we've been building products for anything, right? If you think about a car, a car has a very diverse supply chain where you get some pieces from the tire manufacturer and other pieces from the spark plug manufacturer. And the car builder actually just puts together all those component pieces to get you a car at the end. I think, Steve, what you're saying is in the world of software, that same process is happening. It's just, it's all technology. It's all bits and bytes and pieces and libraries and things that are being put together to give me that final product, that car that I can drive off the showroom floor.

5:36Steve SpringettYeah, absolutely. That's exactly what it is. We're not trying to discourage the use of using these reusable open-source third-party components. What we're trying to do really when we're talking about supply chain risk is really trying to address the elephant in the room in a lot of cases that organizations don't necessarily know that, you know, they assume open source is free. And it's, you know, to steal a line from Dan Cornell, Open source is free as in puppies, not in beer. There's certain maintenance and certain hygiene that you should probably do if you want your product that's using these components to be healthy.

6:16Robert HurlbutYeah, definitely. That's a great quote as well. I had not heard that before, but free as in puppies, not as in beer. Okay, so there is a set of products then that have and I say products kind of loosely, meaning commercial and open source, that have risen to try to address this problem of supply chain risk. And in the industry, we refer to them as software composition analysis or SCA tools. Steve, what are some things you could tell us about this kind of category of application security tool?

6:53Steve SpringettFirst of all, the SCA, the software composition analysis acronym, is highly misleading. actually ignores a large and growing percentage of things that we're actually building today. So, in terms of supply chain, it's really not a good term to use, but that's kind of what the market research firms have given us. But in the space, there are a number of commercial vendors with certain capabilities. There's several open-source offerings in the space as well. I'm, you know, part of one project that does that. And essentially, it's kind of a mix between having a product or some kind of offering that actually does the analysis for you regarding, you know, what applications am I building and what components are in that application and actually performing that analysis. And then the other piece on top of that is really about the risk intelligence. How good is this project, how good is this vendor in actually producing some really valuable risk intelligence. So both of those things together really form the basis for a software composition analysis product.

8:13Chris RomeoNow, when you say risk intelligence, are you meaning how good is the component that I'm using, or how good is the final solution that I'm using based on all its component pieces?

8:24Steve SpringettNo, when we're talking about like risk intelligence, we're looking at Things like, yes, does it have any known vulnerabilities? These are the easy types of questions, right? Does it have any known vulnerabilities? What is the license? Is my organization okay with, you know, the license and its terms? Is the component out of date? How old is it in terms of age? Is it the latest version, but it's still 5 years old? That might be a red flag.

8:55Chris RomeoYeah.

8:55Steve SpringettWe're looking at project health. So is the project actively maintained? Do they have committers? Do they answer tickets when users of that project actually submit them? Do they answer them or just close them? There's all kinds of different types of intelligence that go into determining whether or not a component should or should not be used. The quality of that intelligence varies dramatically across the vendors and even into the open source world.

9:33Robert HurlbutOkay, so that helps us to get a perspective on SCA and kind of this type of tools. Now, I guess, what is the current state then of this SCA product sets across both commercial and open source? I mean, are we in a good place? Are these tools really helpful? Are they doing a good job and doing what they're supposed to do? Or are they just yet another tool with blinky lights and stuff like that?

10:00Steve SpringettYeah, that's a really interesting question. So as an open source person myself, and, you know, I was the— you know, Jeremy obviously created— Jeremy Long obviously created the Dependency Check project back in 2012. I was the first core contributor to that project, but I also had a need for something else but related, so I created the Dependency Track project, which we'll talk about later. But, you know, I've been doing the open source stuff for so long and it had really been a long time since I evaluated what was commercially available. Because when I started down this venture in 2012, there really wasn't anything commercially available. Now there is. Now there's all kinds of things to choose from. I recently literally just did a bake-off at my own organization. As kind of being in this field for a while, I had a certain expectation, and I knew that no vendor was going to meet my requirements. But I did have some interesting observations. When we think about some kinds of tools like static analysis tools like a Fortify or a Veracode or Checkmarx or something, typically organizations just use one. Right? They, they're a Fortify shop or they're a Veracode shop, and that's what they use to scan all of their code. When we think about dynamic analysis, we typically think of using multiple tools, right? You might use a Burp Suite, you might use a ZAP, you might use an Acunetix or AppScan or whatever it is. You might use multiple tools, maybe some manual techniques in there as well, to come up with your dynamic analysis results. Unfortunately, today the SCA market, you really need multiple tools. That's the current state that we're, that we're in. In terms of organizations actually being more versed, more knowledgeable of the problem, I think, I think the media has done a really good job of kind of highlighting supply chain is an issue. There's been a number of, you know, high-profile cases over the last couple of years where, you know, it was a supply chain issue that led to a massive breach of some sort. So I think the media has helped identify the seriousness of the problem. But the tools themselves have a long way to go before, in my opinion, they would be classified as leaders in the space. We're really not there yet. I look at the commercial SCA space as kind of a bucket of capabilities. I have a dozen or more capabilities that I need in my environment, and I might choose one vendor because they have half of those capabilities. I might choose another vendor because they have some overlapping but some unique capabilities. So I'm really looking at multiple vendors now in order to solve this problem. And even then, I'm not at a point where I have all my requirements met. So as an industry, first of all, I think dropping SCA would be a good start.

13:27Robert HurlbutJust dropping the name, you mean?

13:29Steve SpringettExactly. Because it's really limiting in scope. And because of that, you know, I think the A lot of the companies are really just developing to that particular scope and not really truly understanding the breadth of the problem and developing solutions for the problem instead of the market research firms. But that's where we're really at today. It's unfortunate. We've come a long way, but we have a long way to go.

13:57Robert HurlbutSo, well, we could always just choose a new name here. You know, we could just have an industry discussion and decide what the new acronym is going to be. It'd have to be something funny. It would have to resolve to something funny when you took the first letter of each of the words. So, I guess I'm not witty enough to make it up on the fly. I'll have to think about it offline. But I'm curious though, when you're thinking about this bake-off and going through this process, what was that list of capabilities that you were considering across all the tools? Because I think that'll really help people who, let's be honest, right? most people who are going to do a bake-off don't have your perspective because you've really been inside of these type of tools and really know how they work. And so I think your list of capabilities would really help somebody else who's brand new to this space and has been given the task of, hey, choose an SCA tool that we're going to deploy for our enterprise.

14:50Steve SpringettYeah, absolutely. And I've been asked multiple, multiple, multiple times to kind of come up with that list of things that I actually care about. but between day job and wife and kids and open source commitments, I literally just haven't had a chance. So I'm glad we're having this conversation. But my list of the things that I care about, I didn't think were necessarily unreasonable. So one is just having an accurate inventory. That's first and foremost. And I was really surprised how hard that could actually be with a commercial SCA tool.

15:29Robert HurlbutAnd this is just so— just to make sure everyone understands, when you say have an accurate inventory, accurate inventory of the applications/products that exist in the enterprise and have that fed into the tool?

15:41Steve SpringettOh no, no. So, uh, accurate inventory in terms of— well, yes, I mean, you should have an accurate inventory of the applications and assets in your organizations, but no, I'm actually talking about the inventory of third-party and open-source components that are being used in an application or all of your applications. Actually, having an accurate inventory was surprisingly difficult among the various tools, and there's a couple of reasons why that was so. But there's a couple of different approaches that solutions use to address the inventory problem. There's the binary way. looking at this thing and I think it's this, or the manifest way where you're looking at POMs or package.json or something, and this is what you told me you have. Both of those are like, I think, and I think, and if you put them together, you have a maybe. But you're not to the point where you're actually stating what it is that you actually have. So that's where the software bill of materials that we can dive into in a little bit, that's where that is really, really important. But having an accurate inventory, being able to support all the ecosystems and build environments that you actually have, using package management. Organizations, even drudgingly, they need to adopt some package management. Managing your dependencies manually in 2019 is just a non-starter, it leads to incredible amounts of risk. If you are looking at inventory, I highly suggest that every organization adopt the Package URL specification. It wasn't created by me, but I'm part of the core working group that's defining what the specification is. It's a universal way to describe packages regardless of what ecosystem they're actually part of. So instead of specifying, you know, talking about Maven GAVs and all this other stuff that's very specific to various ecosystems. You just have a package URL and your supply, your inventory, everything references that, which it's a universal way to describe that. Outside of that, the things that I cared about initially were vulnerability analysis, license identification, whether the component was out of date or not, and whether the component was end of life, end of support. End of life, end of support was surprisingly difficult to do. Most vendors don't do it at all. So you could be using the latest version of a component and you think you are okay, but that version is so old, the project maybe moved on. Most solutions today don't actually offer that capability, which is really unfortunate. Being able to ingest bill of material formats. If you go to any of the commercial SCA websites, they're talking about bill of materials, yet most of them actually don't support them. So, there's a couple bill of material formats. It's really useful to be able to represent your inventory your components in a standardized format that is interchangeable between the various systems. And nothing really does that today. The open source world dependency track was the first and currently only solution that does it both ways. But I know Sonatype, for example, from Nexus IQ from Sonatype, they're actually in the process of of adopting CycloneDX, which we'll talk about in a little bit. Black Duck has partial support for SPDX, but for the most part, bill of materials, even though they're actually advertising them on their websites, the standardized formats aren't actually supported. And when you think about that, it's, it's really interesting, right? If I say I'm making a web browser, yet I don't actually support like HTML, CSS, and JavaScript, Can I really say that I have a web browser? Probably not. I think not. Basic things like that are really missing across the industry today. Pedigree and provenance is something I really care about. What this refers to is really the love-hate relationship that organizations have with open source. They love to consume the hell out of open source. and they really don't like to contribute back. What happens in a lot of organizations is that they'll use an open-source thing, it doesn't quite meet their needs, they'll fork it, they'll make some modifications to it, and now we have this new thing. Being able to track what that origin component was, being able to track what the differences are in my version that I'm using, and who made the commits, what those commits were, is really important. it. Depending on how you actually modify your open source components, depending on whether or not you're using the binary method of analysis or the manifest version of analysis, depending on how you modify those components, you may be blind to any license or security risk depending on how you modify that. For example, if you're using only manifest analysis and you change and you change the Maven gov, you change the group ID, for example, now none of my vulnerability information actually— if I'm using org.apache.tomcat and I change it to org.acme.tomcat, now my vulnerability intelligence stuff doesn't know what that is. Same thing for binary analysis. I might be able to identify that originated from Tomcat, but If I'm trying to keep my stuff constantly up to date using DependencyBot or something like that, Dependabot or something like that, now I can't because I've modified it. And if I update automatically, now I break my application. So pedigree and provenance are really, really important.

22:15Robert HurlbutAnd is that something that's missing from the commercial tools in our modern day? versions?

22:22Steve SpringettAll application— all modern SCA tools, none of them did that today. A couple of them had it on the roadmap. Most of the vendors weren't even thinking about it, which is really, really unfortunate because that is the essence of what open source is about. That is the essence of the supply chain problem, and it's completely missing in the SCA space today. There's really— if you look at the— I encourage everybody to look at the Gartner and Forrester reports and maybe look at the footnotes in some of these and see who is actually talking about supply chain versus just SCA. Because the folks who are really understanding this from a supply chain perspective and a holistic supply chain approach, I think those are the organizations that organizations should essentially partner with, right? I know we're not in a good state in SCA today. But I think part of the roadmap that consumers of SCA should pursue is knowing that SCA is not perfect and choosing a vendor that truly understands that supply chain is where it's at. This is the problem and this is our roadmap to get there.

23:42Robert HurlbutYeah, you've really opened my eyes here, Steve, to— I did not realize that the SCA market was as immature as it actually is. And so I would have— if you would have asked me at the beginning before you said anything, hey, how mature is this as a market? I would have said, ah, you know, it's not brand new. It's somewhere making its way towards the middle of the road. And it sounds like a lot of these tools still have a long way to go.

24:07Steve SpringettThey do. I mean, that's why I was— I had some— I had a lot of requirements because I have a lot of expectations because where I'm currently at, that's kind of the reality. And, you know, I went in there knowing that not a single solution was going to meet my requirements, but I came away with— I came away realizing that, you know, we've come a long way in the last 5, 6 years, whatever it's been, but we've got a tremendous amount of road to get ahead. And putting vendors in a leaders category isn't helping. It's really not. I do— I would encourage any organization that is looking for SCA solutions to really do a due diligence, to really do their own bake-off in their own environment, and to really ask themselves the questions about what they actually care about, right? Some organizations may not care about pedigree and provenance because they use the open source components as is. Maybe they have a policy that they actually allow their developers to contribute back. That is phenomenal, but most organizations, that's not reality. So asking yourselves, getting with the security team, the legal team, maybe the compliance teams, the audit teams, asking them what is it that we as an organization care about and coming up with a list of requirements and capabilities that you're looking for, and you'll probably come down a similar path to what I did in realizing that you kind of need multiple solutions today.

25:46Robert HurlbutThat's kind of a scary proposition to say that you're going to have to go with multiple just because enterprise tools are never cheap. And if you have to 2x or 3x, but ultimately, it comes down to how do you make sure you have the best intelligence and you're able to make the best decisions based on your third-party software? So, I think this problem is big enough to merit whatever it takes because we've seen, like you started with this conversation about how prevalent these libraries and components and things are. I mean, the number I've seen, I don't know if you've heard this, you probably have even maybe a more updated number, but the number I've seen thrown around is somewhere around 90% of code in a product or in an application is actually coming from the components that sit underneath it. And you're lucky if you're writing 10% of your own custom code.

26:37Steve SpringettYeah, yeah. And that's really largely dependent on the type of application and the ecosystem. NPM is notorious for that. Java's not quite as bad. But it's definitely ecosystem-specific too. But yeah, I've heard 85% to 90% as well. So that's kind of— the norm, I think. And that's kind of why we're talking about this. And thanks for having me on again after a year and a half. But it's one of these security issues that is on the surface, it's an elementary problem to solve. But when you actually dive deep and try to figure out exactly why this is a problem and looking at the capabilities, it becomes a lot more complex. And you are often in a situation where you're looking for a solution to a problem and there isn't one.

27:39Chris RomeoYeah.

27:40Steve SpringettSo—

27:41Robert HurlbutI mean, the enterprise complexity of this really does lead to making this a lot harder problem to solve. And I'll give you an example from my company's perspective here. So, we write code on one framework and everything we do is in that framework, in that ecosystem. And so, we have a pretty good system to break the build multiple ways if we end up with some type of vulnerable third-party library or component that's in it. And so, I feel like we've got a pretty good solution. I think we've got a pretty good answer to it. But it's only— we can only say that because we have a very simple single-threaded ecosystem here. Like, we don't have— like, the average enterprise has everything.

28:26Chris RomeoRight.

28:26Robert HurlbutAnd so, you're trying to build a solution that solves Java, C#, maybe C and C++. I mean, they still use libraries in those, maybe PHP. You know, I mean, there's 20 other things we could add on that list. And so, yeah, definitely a complex problem.

28:43Steve SpringettYeah. And let me just go through the list of other things just real quickly because I know we wanted to talk about a few other things. But, you know, having a security policy, and being able to enforce that policy was important to me. Being able to reprioritize the risk of some of the findings, like if something was marked as critical, but that method may not necessarily be used, or maybe it's used, but it's used in a safe way, being able to classify that. One thing that I will caution in this space, and It's on the marketing websites of a few of the commercial vendors, is the data flow exploitability, right? Being able to identify that method and whether or not it's actually used in your application. Be very, very cautious with that. Use it as a risk prioritization tool, not as a way to, to not fix something, because I will tell you from experience that it doesn't work. It will tell you when something is confirmed exploitable, but the lack of a confirmed data flow does not indicate a safe component usage, especially when an application has multiple languages, when it's a polyglot application. And guess what? Static analysis doesn't work that well across languages. Even something like Fortify that's been, you know, doing this for years, and this is their sole job, Mm-hmm. It's really difficult. So having SCA solutions do this, use it for risk prioritization and that's all.

30:27Robert HurlbutYeah.

30:29Steve SpringettComponent onboarding, right? Having that golden repository or blessed set of components was really important. Reporting integrations and really looking then at the effectiveness. how effective is the tool in terms of the integrations with how your organization actually produces and consumes software? Then is it effective in actually identifying the vulnerabilities that you care about? What we did in my bake-off is we took 5 different applications that represented a realistic view of our entire enterprise and we put them through the We analyzed each of those 5 applications. Then we took all that raw data and using some Python and some data science wizardry, we were able to determine which solutions were providing the better intelligence. This was actually the first time that DependencyTrack, my open-source project, was actually evaluated against anything else commercially, at least to my knowledge anyway, and it did really well. I was really surprised. I was very happy about that. It did surprisingly well. But there were a few commercial vendors that had really good data science teams, one in particular. Look at how effective that intelligence, what your results actually are. Let's see, what were some of the other things that I cared about? the age of the component, right? How old is it? Open source policies should probably have, you know, somewhere in there where, you know, you accept components that are maybe 3, maybe 5 at the most years old, and anything less than that or anything more than that should just, you know, flat out be denied in case of, you know, maybe make exceptions on rare occasions. But, you know, the age of the components security researchers aren't looking at these old things anymore. They're looking at the newer things. They're looking at the popular things. Just because something is old and may not necessarily be new findings attributed to it doesn't mean it's not exploitable. And because they're open source, the people who are looking at this would be your adversaries, not necessarily the security researchers. So it's— You know, there's a lot more adversaries than researchers, in my opinion.

33:07Chris RomeoMm-hmm.

33:08Steve SpringettThe health of the project, you know, we talked about that briefly. You know, are they accepting pull requests? Are they, you know, are they— here's a good one. What types of issues are— does the project seem to be notorious for producing? Like if we were talking about CWEs, what kind of weaknesses does the project, have over time. If it's the same weaknesses, well then maybe they have an architectural problem with that project. So looking at the project health is really important to me and looking at what the component does. Is it an XML parser? Is it a persistence layer? Because if I'm adding yet another XML parser to my code, I already have 2.

33:58Chris RomeoYeah.

33:59Steve SpringettI don't need another one. Why would I increase my attack surface unnecessarily when doing that? That goes into just the amount of components, choosing the best component from fewer suppliers because as applications grow over time and your component usage expands over time, if you have a development team, that it has time-box constraints, their ability to maintain component hygiene over the course of that application's lifecycle will diminish as more and more components are introduced into that application. So choose the fewer components, choose the best quality components, and look at the function of the component and try not to duplicate when necessary.

34:49Robert HurlbutWow. This is a great list of potential things. And so, what I'm going to do here is I'm going to read them back to you and see— I'll give you kind of— because we went off on a couple of tangents, which was great, in the middle of this. I was responsible for a couple of them, so that's why I said they were great. But just, I'm going to kind of re-summarize your list and make sure I've got it correct. And so, the first one on your list was have an accurate inventory of third-party code in an application. Whether they're using the binary approach or the manifest approach, it still gets you to a maybe. And so that's a question you need to ask. Second one was build environment support. Make sure they have support for the environments that your build process is relying upon. The tools you're using should work with this SCA tool. Make sure they use some type of package management, and you as an organization have to Do you have a package management approach? But also make sure the tool supports that. Vulnerability analysis of the individual components, license analysis, determining whether the component's out of date, is it an end-of-life or end-of-sale status, ingesting the BOM formats, whether that is CycloneDX or SPDX or one of the other standards out there, make sure the tool actually does that. See if it— or consider whether that tool can determine or read out on the pedigree or provenance of the component. So, if a developer forks an existing component, are you going to lose all traceability at that point, or are you able to keep tracking that based on the original component? Security policy. Does it have the ability to enforce a security policy? Do you have the ability— does it give you the ability to reprioritize the risk ratings? Because we know that there always are going to be errors. It's never going to be— your organization may have different risk tolerances or different interpretations of particular things. You gave a caution about data flow exploitability as a feature. So just be on the lookout for what they say about that and take a really close look to see if it actually does what you say. The component onboarding process, how does the tool handle that? How does it measure effectiveness and reporting? What's the effectiveness of the intelligence they have about those components? Do they have a big team who's tracing down all the new information about components, or are they relying on some public source? And then the tool should be able to determine the age of the component, the health of the project, even what the component does. Is it duplicating some other existing capability that is somewhere else inside the application? That was 19 things on my list here, Steve.

37:39Steve SpringettOkay, that was my initial requirements.

37:43Robert HurlbutThat was the initial—

37:44Steve Springettwow, that was the initial requirements. If you talk to some organizations, I mean, they're going to want, you know, what the developer's IDE was, what the compiler flags were, and all kinds of other things that, uh, are also part of the supply chain, you know, conversation. But yeah, those were basically my initial requirements.

38:03Robert HurlbutYeah, that's a great, uh, it's a great list, and hopefully it'll help those that are looking to purchase SCA solutions, and maybe a vendor or two will listen in here and pull out a list of requirements from it.

38:14Steve SpringettBut yeah, I encourage, uh, because of my lack of time, if anybody wants to go forth and start documenting this, uh, I, I highly encourage you to do so. Um, yeah.

38:27Robert HurlbutAll right, well, I wanted to quickly touch on this Cyclone and Cyclone DX and this whole idea of SBOM. And so now that we have a good idea as far as the things we should be looking at in an SCA solution, let's just talk for a minute or two about SBOM. And first of all, what is SBOM?

38:49Steve SpringettSo just software bill of material. It's a, it's a statement fact. It's a document that, you know, typically machine-readable document that tells you exactly what's in it. It's a list of ingredients, back of a food label type of thing. It does not talk about the health of those components, only what's in it. So if you are allergic to Apache struts, well, you will know, right? So—

39:20Robert HurlbutI was just— I was seeing that on a t-shirt.

39:23Steve SpringettI am allergic to Apache struts.

39:24Robert Hurlbutshe stressed.

39:25Steve SpringettExactly. But that's really what we're talking about. You know, the US federal government has actually done a phenomenal job kind of highlighting the need for SBOMs in general. Alan Friedman, who's got part of NTIA, the National Telecommunications and Infrastructure Administration, there's multiple working groups. Myself and others are on these groups, and we're trying to come up with, you know, what is an SBOM and what things it should be— what should be in it, what are the use cases, that sort of thing, and trying to come up with some documentation to sell to others. But it's really just, at the end of the day, it's just a list of ingredients, and the federal government has done a phenomenal job kind of marketing that as such. Likewise, the Dependency Track Project actually has been an SBOM-first approach since the project actually started, but more formally in 2017, even before the NTIA initiative was actually happening. But it's literally a— so CycloneDX is literally just one of the many. There's a couple different formats. SPDX started out doing license and intellectual property type of compliance, copyright compliance. There is the SWID or Software ID Spec. For whatever reason, it's being pushed by NIST, the NBD folks quite heavily. But that actually came from a— that also came from a license perspective, but it was more of an entitlement. Both of those specifications are bolting on security and other types of capabilities into their specifications. CycloneDX actually started out just doing a security-only approach.

41:25Chris RomeoOkay.

41:26Steve SpringettI looked at SPDX and I didn't even know about SWID because it's behind an ISO paywall, but I looked at SPDX in 2017 and just, it wasn't there. And it was also a very slow-moving, it's not necessarily like a, It's run actually more like a standard, like an actual standard rather than like an open-source project. I needed a solution like yesterday. I couldn't wait necessarily for a standard to eventually in several years actually morph into something that I could use. I needed something in 2017. That's why CycloneDX actually became a thing. I did it as a non-OWASP project for a reason. I wanted to separate that away from Dependency Track as much as possible. Today, it's really interesting. There's literally thousands of organizations using CycloneDX today, some of which are using it without Dependency Track at all. They've got their own things that they're doing and they're using CycloneDX because it's lightweight and it's security first. So as a specification, I'm actually really happily, you know, surprised at how well it's doing. But CycloneDX is really the basis for, you know, what dependency track is all about.

42:50Robert HurlbutAnd so if I was just to summarize then what an SBOM and the CycloneDX being an instance of an SBOM, the benefit that this provides to the industry is we just get a common format to describe an individual component that we can all agree on, we can all implement it, and then your intelligence that you— if you provide me with some information about a component and I can ingest it in a standard format, I don't have to— it's just an easy way for us all to talk to each other.

43:22Steve SpringettYeah. So, 2 really simple use cases for this, right? I am an organization, I'm looking to acquire a piece of software, procure a piece of software, and I'm going to ask that vendor for their software bill of materials. If they can produce that to me, I know that there's a certain level of maturity in their organization because they were able to produce that in a machine-readable format. Hopefully, it's SPDX. Hopefully, it's CycloneDX and not some PDF or something. If it's a PDF or Excel spreadsheet, we've got other problems to worry about.

43:55Chris RomeoYeah.

43:55Steve SpringettBecause unfortunately, that represents a lack of maturity in that other organization. So that's one for due diligence. But coming back to that modified Tomcat example, if you're looking at it from a binaries perspective, well, you think it is this one thing even though it's this modified version of Tomcat. If you're looking at it from the manifest, you're blind because now you don't know what it is. But the development team, they know what it is. So if they're actually producing a bill of material in their build, and they can correct it during the build so that if you're using Apache— I'm sorry, the Maven Assembly plugin, for example, to do your packaging, you could, for example, very easily create your bill of material in your Maven lifecycle and then simply correct whatever things that you already know in advance to be true and produce an accurate bill of material.

44:55Robert HurlbutYeah.

44:56Steve SpringettSo instead of guessing with current SCA solutions, you could actually have the development team actually tell you what they're using and then use that as your source of what you're going to analyze. It's a much cleaner approach in my opinion.

45:11Robert HurlbutYeah, because it's coming from those who know what's actually in the software solution versus a machine trying to take its best guess based on what could be faulty data. that it's looking at.

45:24Steve SpringettYeah. So it's just another way of looking at the problem. And I look at this space as, you know, I don't think necessarily one approach is better than the other. There is a tremendous amount of value for binary analysis. There's a tremendous amount of value for manifest analysis. Binary is really good for, you know, identifying those things that may be even copied and pasted from other things, right? Whereas manifest really lends itself to being able to test early and often. Think, you know, GitHub pull requests and these sorts of things. And SBOMs is also a really good way to analyze. So yeah, I see 3 different complementary ways that organizations should approach the, you know, how they analyze their components, because each of these 3 ways has value.

46:17Robert HurlbutYeah, definitely. I see that as well. And that's hopefully the way the industry will go here is these tools will support multiple— they'll do binary, they'll do manifest, they'll do SBOM, and then they'll be able to give you close to 100%. We're never going to say that you're at 100%, but they'll get as close to 100% as they can to say, hey, here are the actual vulnerabilities based on all of these types of information we've looked at to determine what this component actually is.

46:43Steve SpringettRight, right, right. Now, even though we talked about the SCA space as, you know, having a a long way to go. I did have a couple of conversations with a few vendors, 2 vendors specifically, that had really impressive roadmaps. So, they definitely know, you know, more about the problem space than what they're developing for, and they do have roadmap items to address a lot of what we just talked about. So, there is, you know, hope along the horizon. It's just not going to get there overnight. You know, that's why when I say, you know, go in with these requirements, go in looking at a capabilities-based approach knowing that you're not going to get them right away because you need to choose that vendor, that solution that you're going to partner with that knows supply chain and actually has a roadmap item to address all your capability concerns. Yeah.

47:45Robert HurlbutYeah, that's great. This has given us a lot to think about here, and I know we wanted to talk about Dependency Track updates and things like that. Give us a 60-second version of what's happened in the world of Dependency Track lately.

47:58Steve SpringettYeah, it's great. It's kind of taken off. It's a life of its own. It's got its own website, dependencytrack.org. It passed 150,000 Docker polls recently, so it's being used by thousands of orgs. I did the bake-off between dependency track because if I'm spending hundreds of thousands of dollars on commercial SCA things, I need to be able to justify the cost. Surprisingly, it actually performed identical, nearly identical to one of the commercial SCA offerings. So yay. That's why do your research. But the project is going really, really well, used by thousands of orgs. Some really interesting roadmap items coming along, some project health, some other types of analysis that we're doing. And, you know, if you're into this space, if you're into security, you know, we're always looking for contributors. So if you've got some spare cycles and you know some Java, you know, definitely give our project some consideration.

49:01Robert HurlbutYeah, and I can definitely say that I mentioned dependency check and dependency track all the time. When folks ask me about SCA, I always tell them to start there. I said, start there and see, because from what I've seen and in my own testing, Dependency Check and Dependency Track kind of working in tandem are as good as anything that's out there from my perspective. And so, I want to thank both you and Jeremy, Steve, for all the effort you put into this. And people, we should have said this at the beginning, but Dependency Check, Dependency Track, these are OWASP open-source projects. Jeremy and Steve are not buying yachts and things as a result of these awesome tools they've created. They're doing it for the good of the industry, the good of the community. And so we'll never be able to thank you enough, but I just want to say it anyway because you're making a huge sacrifice to do it, and we really appreciate what you do.

49:55Steve SpringettYeah, I mean, hopefully we can push, you know, have something just good enough where we're actually pushing the commercial SCA vendors to innovate just a little bit more and to address some of these other capability concerns. But, but yeah, we do it because we love it. And, you know, we don't have big yachts, but we, we do have generous employers.

50:14Chris RomeoThanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Born and TJ, and our outro music is Southern Delight by Stefan Kartenberg. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @roberthurlbut. Remember, security is a journey, not a destination.