Steve Springett -- Dependency Check and Dependency Track

0:00Chris RomeoOn this episode of the Application Security Podcast, we talk OWASP Dependency Check and Track. You'll hear what is software composition analysis, what is OWASP Dependency Check, Dependency Track, how do these things work together, do they replace closed-source software composition analysis tools, and also how do you get started if you wanted to take these tools and roll them out in your organization. How could you use them, and what is some advice to be successful right from the beginning. And then at the end, we talk about what are the— what's the future of these different projects. So we hope you enjoy. The Application Security Podcast. Here we go. Hey, folks. Welcome to this episode of the Application Security Podcast. And on this episode, Robert and I are joined by Steve Springett, who is the project lead, amongst many other things, of Dependency Check and Dependency Track. And so, this is projects that have existed in the OWASP universe for a while, but there's been some some things that have recently changed and new stuff that's exciting. So that's why we wanted to bring Steve here. So Steve, we always jump in and start with what is your security origin story? How did you get into this world of application security?

1:41Steve SpringettThat is a very roundabout question, but as an early kid, I, like a lot of kids who are into computers that are my age, I started hacking on Commodore 64s and TRS-80s and whatnot. And started programming that way. And by the time I was in high school, I was a little mischievous and, you know, did a few hacks or whatnot. And I actually got into— when I was a little bit younger adult, I actually got into the physical security world. So I was doing access control and whatnot for banks and high-rises here in Chicago. And around that same time, few years doing that, I realized that, you know what, you can actually get paid a lot of money for programming, which is something I love to do. So enough of that. So I got into programming in the mid to early '90s when the web was just taking off. And eventually security became a thing because the web wasn't just a fad anymore. So I started doing some security stuff on and off. But at the time, early 2000s, it wasn't this full-time gig that that we have today. I kind of switched around 2008 and definitely full-time around 2012 or so where I was rolling out full continuous security programs to one of my former employers.

3:07Chris RomeoVery cool. It's great to hear somebody who has a lineage back to the good old Commodore 64s and the Trash '80s of the 1980s. It's good stuff. We had another guest recently who also was recounting the fond times of those computers. For those that never got a chance to use those, you really missed out. If you never had a tape drive that you could load software from, I mean, you're not going to get it. You don't understand.

3:39Steve SpringettAbsolutely. And then, of course, one of the Trash '80s, you had capitals only. No lowercase.

3:46Chris RomeoYeah, we had one of those, the gigantic 9.5-inch disk drives for the, for the TRS-80. And I mean, that was like, I mean, you know, at least we were going to lose that, that disk. You know, it was the size of a phone book, but, um, and it held how many kilobytes? Not many as well. So, uh, we've come a long way in the world of software. And, um, so Steve, I want to start talking about just by defining this whole idea of software composition analysis. I see this term thrown around now. It's the fancy term. I see Gartner using it. I see Forrester using it. And so I just want to unpack for our listeners a little bit. What is software composition analysis, or SCA?

4:29Steve SpringettYeah, so the concept of composition— what does it— what are the ingredients that it takes to actually build something? And applications, modern applications, are built on top of existing software components, many of which are open source. Because reinventing the wheel is very expensive, so we don't do it. I don't go out and reinvent an XML parser or persistence layer. I use readily available components for that. And the packaging and what components I'm actually putting together in various orders is really what software composition analysis is all about. It's a supply chain issue, and unfortunately the market researchers you mentioned, Gartner and Forrester, Unfortunately, they're coming to this problem at a very software-specific angle, and it's much more than that. It's actually a full supply chain risk management issue because, as we've recently discovered, hardware too can have vulnerabilities. So it's definitely a full supply chain issue. The types of issues that we see in the news and whatnot, it's primarily focused on software. You know, the big breaches and whatnot, these are all software problems. But it's not limited to just software.

5:56Chris RomeoOkay. And so I guess why do we care about these tools or why do we even need these type of tools to be included inside of our programs?

6:10Robert HurlbutAbsolutely.

6:11Steve SpringettThe usage of vulnerable— or the usage of components in general really drives a faster time to market for organizations. Organizations can quickly build applications using readily available components because, again, reinventing the components is really expensive and time-consuming. So just building on top of existing components that is out there really drives acceleration. And when you have a known vulnerability, at the point where it's known, the attackers are already weaponizing it. In fact, by the time it's known, the attackers probably already know about it because the definition of known means that it had to be analyzed by somebody. Somebody had to actually wait a certain period of time for responsible disclosure and whatnot. before the item is fixed and then eventually published. Well, in the open source world, GitHub repos are wide open, so the adversaries are constantly analyzing our code anyway, and the fact that it's not known at the time, well, the attackers might actually know about it well in advance. So it's a— the time to mitigate these issues becomes exceptionally critical. There's a very small window to actually mitigate these types of issues, especially when your adversaries nation-state actors and whatnot are weaponizing it en masse.

7:37Chris RomeoSo software composition analysis tools then are going to identify— they're going to help me to understand what are the ingredients or the components that have been included in one of my projects, but it's also going to help me then to know when there are known vulnerabilities that exist in the things that I've— that I'm including inside my project. Is that the real primary goal of SCA?

8:04Steve SpringettIt is, it is, because once you build on top of existing components, those vulnerabilities, those properties of those components become an inherent property of the overall application. So if you've got a vulnerability in a web framework, for example, like Struts, because we like to pick on Struts, those vulnerabilities are inherent in the application. So you could have something as simple as a Hello World application that has remote code execution possibilities.

8:31Chris RomeoYeah, wow. I mean, seems like Struts has been in the news in the last 12 months or so with everybody in the United States' information being disclosed through a particular monitoring firm. So yeah, popular vulnerability. So would SCA— I'm going to ask a crazy question here— would SCA have caught the Equifax breach earlier in the process if they were truly doing it at a high level?

8:59Steve SpringettAbsolutely. Well, first of all, it would have caught it, yes. In fact, we, the dependency check team, Jeremy Long, myself, a few others actually analyzed when the vulnerability appeared in the NVD versus when the issue was actually discovered by Equifax. And the open source stuff that we were working on at the time could have very easily identified the struts issue. It doesn't— that also brings up some other interesting problems why components and upgrading them can be challenging. But just being able to identify those components sometimes isn't enough. Because the components are an inherent thing of the overall application, if you don't constantly keep on updating the components, vulnerable or not, if you're not constantly in a place where you're always updating your components, if you wait, the problem is that if you wait until something has been published, you might have waited you might have introduced some issues where the underlying library that you're using has changed. The APIs have changed. And so simply dropping in a new version of that component, that doesn't work anymore because the APIs have now changed. So if you're not constantly updating your code to use new and newer versions of those components as just a best practice, it's very hard for organizations to respond when they absolutely have to do a 24-hour turnaround to mitigate something.

10:50Chris RomeoOkay, so more of the— so there is more— you're basically going to break stuff, it sounds like what you're saying. If you do try to do a forklift-style upgrade where you're just taking an old version of software that you know is vulnerable and replacing it with a more modern version, it's going to break all the API connections and other things that were happening there. And so basically what you're saying is you're not going to be able to do that in one day's time.

11:17Steve SpringettYeah, if you definitely— if you wait too long, that is clearly a risk. If the organization is really embracing security and doing a lot of the best practices, you're updating your components all the time. So when one of these 10.0 CVEs are published, it's really not a big deal for those types of organizations. But yeah, if you— wait until, you know, a vulnerability is published and there's been some API changes, there could be— not always, but there could be some delay because you might have to rewrite parts of your application to use the newer APIs. Yeah.

11:58Chris RomeoSo before we jump into the different projects, Dependency Check and Dependency Track, how long have you— I get the feeling you've been working with OWASP for quite a while. How long have you been involved in OWASP projects?

12:12Steve SpringettSo actually since 2012, so not terribly long, but I got involved through a kind of a roundabout way. So I was doing some early things with ThreadFix back at the time with Denim Group, and I saw some research on that Aspect Security was doing at the time and published that whole paper on vulnerable components.

12:35Robert HurlbutMm-hmm.

12:37Steve SpringettI called up Dan Cornell over at Denim Group and said, hey, Dan, do you know anything that— is there any solution out there that solves this problem? Because if not, I'm going to go start a project to do this. He's like, you know what? I know a guy. Of course, he knew a guy. Jeremy Long, I contacted Jeremy and said, this is who I am. Turns out Jeremy had started this brand new project called Dependency Check. And it was exactly what I was looking for. It was a way for the automated identification of components and any inherent vulnerabilities in those components. And it was using, it was just Java at the time and it was just the NVD at the time.

13:22Chris RomeoYeah.

13:22Steve SpringettAnd so I reached out to Jeremy and I was collaborating with him since, I don't know, mid to late 2012 before he had the original Black Hat demo, and I think it was actually before it was a NoAuth project, because I vaguely remember us talking about that. But yeah, I started getting involved with Dependency Check project at that point. I was his first contributor. And some of the things I contributed was things that Dependency Check just didn't do at the time. So I created the Jenkins plugin for continuous integration. We were doing a ton of automation back in 2012 for continuous security. I created the SonarQube plugin. I really believe that visibility is one of the missing pieces to this puzzle. For example, as a developer, if I'm coding in my IDE, the IDE will tell me, hey, hey stupid, don't do this performance thing that is going to kill your application, or don't use this deprecated method because it's going to be gone next release. My IDE does not tell me that I've just introduced a vulnerable version of Spring Framework with these, you know, exploitable things, right? It doesn't tell me that. When I build and run all my unit tests, it doesn't tell me that I'm using all these vulnerable components. So visibility is one of these things where if you don't catch it early, you're going to be— it's going to be very challenging to fix it on the backend. So I thought visibility was very important. That's why I created the Jenkins plugin. I wanted to either break builds or put builds into a warning state when new vulnerabilities were discovered. So if a developer checks something in, I wanted to know about it. Likewise, vulnerable components is a quality issue, right? So I wanted to present that into the QA and to the, to the rest of the quality team as a quality issue. So I created the SonarQube plugin, and it's really just a chance to increase the visibility into, into this problem to just the wider team in general.

15:32Chris RomeoOkay, so Dependency Check then is a piece of software. It's fulfilling part of the software composition analysis kind of, I guess, role in that you can use it to scan a build and it'll determine if there's any types of vulnerabilities. So what types of— so what languages does Dependency Check work with today?

15:55Steve SpringettAbsolutely. So Dependency Check works with a dozen or so different languages today. It started out in Java, I think the second language we added was .NET through one of our contributors actually. Then it's gone on from there. It supports Node, it supports PHP, it supports Ruby. There's about a dozen or so languages that the tool supports today. Basically what it does is it analyzes the files that are used during build time. Sometimes these are actual dependencies themselves, Sometimes these are meta packages like a pom.xml, for example, or a package.json. It'll analyze those types of files and determine all the various components and any vulnerabilities inherent in them.

16:50Chris RomeoSo, okay. So dependency check came first then? Was it— or was dependency track and dependency check, were they both released at the same time or was there some type of hierarchy between them?

17:06Steve SpringettNo, there was— Dependency Check definitely came first. In fact, Dependency Check, like I said, it started out as a Java project. There were some use cases that I wanted to do that Dependency Check just didn't do. It wasn't Dependency Check's fault. It's just that I needed to analyze languages that didn't have a standardized way to apply metadata to them. I could not say, for example, that that C library, that who wrote this C library? What vendor did it? What version is it?

17:40Chris RomeoAnd that was primarily C? So when you're talking about these languages that generated this problem space for you, it was primarily C, or there are other languages that were causing you challenges?

17:51Steve SpringettOh, there were definitely other languages. If you use PHP and you're not using Composer, for example, it's the same thing. If you're using JavaScript without Node, same thing. So yeah, it was, it was a universal problem, um, uh, that, that affected a lot of different languages that didn't have that standardized way to apply metadata to them. And that was really the, the start of the Dependency Track project. I wanted a way to easily identify— I wanted a way to essentially provide the evidence to Dependency Check so that Dependency Check could then analyze and tell me what the vulnerabilities were. That was really the simple use case. Instead of Dependency check looking at the files for evidence. I was going to tell Dependency Check what the evidence is.

18:38Robert HurlbutOkay.

18:40Chris RomeoAnd so, but now it seems like Dependency Track has moved into— it seems like it's taken on a lot more capability and features and whatnot. So what is the— what's the primary reason why one of our listeners would want to use Dependency Track today?

18:56Steve SpringettYeah, absolutely. It has. It is completely different. It has It has definitely come of age, I'll say that. And Dependency Track is not a— I want to say this up front, it is not a replacement for Dependency Check. It is a complementary component of the entire ecosystem. And I think it's going to be a very valuable thing for many organizations to have. And it's really designed to be put in that continuous integration, continuous delivery space where you're constantly telling it, these are the components that I'm using and these are the applications that use those components. So that we have a centralized place where we have full bill of materials for all of our applications that we're either developing internally or we're consuming through, you know, COTS, commercial off-the-shelf type software. But it's a central point to track all the organization's applications and and software bill of materials for those. So all the components, etc. And it incorporates dependency check. Dependency check is definitely used for a lot of the analysis, so we actually embed dependency check in there. If you're already using dependency check and the Jenkins plugin, you can already today submit your dependency check reports automatically to DependencyTrack. We'll ingest those. We also support SPDX, which is a standardized bill of materials specification supported by the Linux Foundation. So we support that format as well as a few others. But it's really designed to be that central source of truth for all software bill of materials. There's a couple cases where I think a tool like this is valuable. So when that CVE is published that has the shiny logo and marketing website and makes all the headlines, right?

21:01Chris RomeoYeah.

21:02Steve SpringettBecause you have to have that in order to publish.

21:04Robert HurlbutYou do.

21:05Steve SpringettSo when, when that next thing comes about, it's really easy with a tool like DependencyTrack to say, oh hey, I've got this CVE, what other project, what other applications do I have in my environment that are also affected? So that's possible with DependencyTrack today. So if I've— if I know about this one issue, I can, I can just type it in and it will tell me a list of all the applications that are— that I have in my environment that are affected by that. Likewise, I can go into the component that I know is vulnerable, and it will tell me all the applications that have a dependency on that component. So you can come to it either way, but really the goal is, in this particular use case, is really about incident response, right? How can I, how can I determine what things in my organization are affected so that I can respond accordingly? The other use case— I have a lot of other use cases for this. One of my really good friends is a principal for a custom software development group. So they are a typical thing where they make custom software for organizations. And when they create this software, it's, here you go, Mr. Customer. Let us know if you have any problems. And that's it. Something like DependencyTrack could be used for these types of organizations so that they can actually monitor all the applications applications that they built for all of their customers so that they know that if they used a vulnerable version of Spring Framework, for example, they can call on those particular customers and say, hey, when we developed this for you, there was no vulnerabilities, but something was just published yesterday. We would really like to fix this for you. How great would it be for that type of consulting agency to have that kind of relationship with their customers? That would be incredible.

23:01Robert HurlbutYeah.

23:01Steve SpringettIt would go a long way to kind of solve these types of issues.

23:06Chris RomeoYeah, it definitely would position them as the top of the partner industry just because they have that amount of data that they can pull from and provide additional advice based on being able to know when there's vulnerabilities and tracking them in DT. So, okay, so let me make sure I got this straight here. I'm going to try to kind of bring together everything that I've heard so far. So dependency check, I'm using this. This is like a scanner, and it's integrated into my build pipeline. And so regardless of what language, many different languages that I could be building in, in my build pipeline, dependency check is going to run. It could potentially block the build for me and force me to then have to go and do some type of a library upgrade to remove a security vulnerability. On the flip side, dependency check is also going to be reporting back in a dependency track, which then gives me the enterprise dashboard, the console that allows me to query what components am I using across multiple applications across my whole enterprise, and allows me to use that from an incident response perspective to trace back when something big does hit the industry. I can very quickly use go in reverse and use Dependency Track to check and see what particular places I have that component loaded up. Is that a fair assessment for how these 2 things are fitting together?

24:33Steve SpringettAbsolutely. And if you don't constantly update Dependency Track, it's not a big deal. Dependency Track will continue to scan regardless of whether or not Dependency Check— if you're feeding results to it or not. So once the data is actually in Dependency Track, it's going to continue to scan all your components every 24 hours anyway.

24:53Chris RomeoYeah. And just so you know, I've actually been a consumer of dependency check in a build pipeline for a cloud service that I run. And dependency check has saved my hide a few times. When I go to push out some code, it says, did you know you have a vulnerability in this component? And I say, no, I did not know that.

25:13Steve SpringettThank you very much.

25:14Chris RomeoAnd it breaks my build. So, it forces myself and my other developers to have to go back and fix it. And just so you know, I get asked all the time. I work with a lot of different companies that are building AppSec programs. And when someone says, what should we do first? I say, are you writing software? If they say yes, I say, install OWASP Dependency Check. That's the first— that's my first recommendation because it is— And the reason I feel good about telling people that is I know how big the third-party vulnerability problem is. And I also know how easy it is to actually because I've done it myself. I know how easy it is to take Dependency Check and add it to a build pipeline. And there's really not a lot of— so you guys have done a great job in— there's not a lot of overhead for me to try and figure out how am I going to make it work. And there's examples. Boom, I put it in. It breaks the build if there's a vulnerability found. So good job to you and the rest of the team in making a tool that I can recommend to people that they can do on their first step in building their program.

26:09Steve SpringettYeah, that's great to hear. I'm sure Jeremy would be glad to hear that as well. That's really the goal. I mean, we really want to provide something that would be useful, but at the end of the day, we really don't care what organizations use. If what we bring to the table with the OWASP project is just— if the only thing that we brought to the table is just elevating the level of knowledge on these types of problems, we're okay with that. We're hoping that this is something that's going to be useful to organizations, but at the end of the day, we just want the organizations to use something. Yeah.

26:46Chris RomeoYeah, and that's—

26:47Steve SpringettBecause this is a big problem.

26:48Chris RomeoThat transitions us nicely into another question here. So there's a number of what I'll call closed-source software composition analysis tools. I'm not going to name any names at this point, but there are a few very well-established tools in the marketplace. And when I'm listening to what you're doing with Dependency Check and Dependency Track, and I'm thinking about what I know about the capabilities of those tools, I'm thinking these things are relatively close to each other. So what's your take on the closed source? And we don't need to talk about specific companies at this point, but what is your take on the feature parity or the differences between what you're providing in your OWASP projects and what I could get if I went and spent $100,000 with one of these other companies out there?

27:32Steve SpringettYeah, that's a really great question. So there's definitely a handful of players in the commercial SCA space, and most of those players have good or at least decent solutions. There is— I would definitely recommend to anybody listening that they do their research because Gartner doesn't always, you know, evaluate things the way that the security industry would.

28:00Chris RomeoYep.

28:00Steve SpringettI'll just leave it at that. But most of the players in the space are doing some really great things. So, independency check— independency track, for that matter— we are currently relying on a couple different sources of vulnerability intelligence. We're relying on the National Vulnerability Database. We are relying on Node Security Platform, and we are currently in the process of integrating RetiredJS, which is a manually curated list of JavaScript libraries.

28:31Chris RomeoYep.

28:32Steve SpringettAnd then we also have plans— I'm actually talking to the folks at Risk-Based Security with VulnDB. That will be yet in the another source of vulnerability intelligence. It's a commercial source though, whereas the other ones are mostly free.

28:50Chris RomeoYep.

28:50Steve SpringettI know you can definitely pay for NSP, but they do have the free service as well. So the National Vulnerability Database is a great thing to have. I mean, it's just a tremendous resource, but it is largely inadequate. If a commercial vendor only supported the NVD, I would be very skeptical. There are items in the NVD that are essentially in a quote-unquote reserved state, meaning that the CVE has been published but no details are yet known. Some of these CVEs, and it's really up to the person who created the CVE to populate that data, and if they don't, guess what? It continues to be in a reserved state, sometimes for years.

29:36Robert HurlbutHmm.

29:38Steve SpringettSo we're really relying on the data in the NVD to be accurate. And I know I have, and I know Jeremy has on multiple occasions, corrected data in the NVD because it's just wrong. The versions are wrong. The identification of the vendor sometimes is wrong. And when you're dealing with these types of issues, it's really important that your source of vulnerability intelligence is not only accurate, But it comes from multiple sources.

30:12Chris RomeoOkay.

30:12Steve SpringettSo what a lot of the commercial vendors do, and I have a tremendous amount of respect for the ones that do this, is they filter a lot of the noise, right? So if you are an organization that has security as part of your development culture, your developers are not— your developers will be accustomed to triaging static analysis results and all these types of things. that's the type of thing that dependency check would also be required, right? It's essentially kind of a static analysis tool. You will definitely have some false positives that your team would have to triage. Some of the commercial— and for organizations that have that type of culture where this is just a normal part of development, that's okay. But for the organizations that don't, that really need spoon-fed developers, for example, that have developers spoon-fed the the security knowledge because of some kind of knowledge gap or organizational structure or whatnot, then it becomes really more important for that knowledge, that vulnerability intelligence, to be curated. So a lot of the commercial vendors in this space will take that extra step and correct all the data in the NVD, for example, in their own feeds. They will monitor Twitter feeds. They'll monitor commit report— commits logs. They'll monitor other types of social media. Or changelogs, so they're monitoring other sources. So the quote unquote public disclosure of something in in the real world doesn't just mean some kind of vulnerability intelligence service like the NVD. It could be as simple as a tweet from a project leader. Hey, I found this vuln in this particular library and pushed out a pushed out a fix. that could be the only public notification that, that's out there. And some of the commercial vendors actually pick up on that and, and will flag issues that are not in the NVD. In fact, I think it was Risk-Based Security, I don't know the exact statistic, but it was over 7,000 vulns last year alone that were not— that were publicly known but were not published in the NVD.

32:28Robert HurlbutHmm.

32:29Steve SpringettSo it's a great source of vulnerability intelligence, but it can't be your only source. And we at Dependable Dependency Check know that. That's why we support multiple sources now, and that's why we're going to be expanding into multiple sources in the future. But what you do get with some of the commercial offerings is really that curated set of actionable results, where in Dependency Check, the developers have to triage some false positives, which I think is actually a good thing because it's just part of the security culture in an organization. Other organizations might want that, that all the vulnerability feeds to have actionable things that developers can do. Right.

33:08Chris RomeoOkay, that makes sense. So let's say, let's change gears a little bit here. And, and, uh, from our— we know from our listeners that we have folks who are involved in the AppSec program side. We also know we have some folks who are developers, maybe in smaller companies. And so if somebody— say somebody came to you, Steve, and they said, hey, uh, we're new to this whole application security thing, but we like this idea. We heard about Dependency Check and Dependency Track, and, and we want to use it. What do you tell them to do as a starting point? Where does someone begin their journey into Dependency Check and Dependency Track?

33:47Steve SpringettGreat question. So the first thing I would recommend is integrating it with their build environment. So if they're a Java shop, use the Maven plugin, use the Gradle plugin, use the Ant plugin. If they're a Node shop or non-Java platform, you know, use the command line plugin. It's, it's, it's, it, it does everything that the others do with the same type of results. You, if you use continuous integration, definitely use the Jenkins plugin if you, if you're a Jenkins shop. It has a tremendous amount of value. Some organizations use SonarQube. I would definitely recommend it to organizations that already have a SonarQube installation. If you're not already a SonarQube, maybe that's a little bit overkill, but really visibility is, I think, in my opinion, a key factor for success in mitigating these types of issues at an organizational level. I think dependency check is probably a really good tool to introduce development teams to security. It's, it's not necessarily overwhelming like static analysis results were, uh, can be. It's not necessarily, um, vague sometimes like pen test results could be, right? This is something— this is a problem that I think most developers can easily understand with very, uh, little security knowledge whatsoever and be able to really make a positive impact across their team. So I think the dependency check would be, you know, starting as early as possible with build time and really just getting into the flow of looking at the vulnerable components that is in your application, getting into the practice of updating them. And as soon as you start to make practice— make that just a normal part of your day, then start creating backlog items to update your components on every release. regardless of whether or not there's any vulnerabilities in them or not. Just make them part of the development lifecycle.

36:01Chris RomeoYeah, and then so how would you recommend somebody that's new, once they've got this integrated in the build environment, how would you recommend that they say they deal with that, those first few times doing triage, for example? Any tips or any tricks you would offer them as far as things to do to set themselves up for success? in the short term and in the long term?

36:24Steve SpringettYeah, absolutely. If the organization has a security champions program, which most mature organizations will, I would definitely recommend that the developers sit down with the champion in that organization and actually go through what the process is. A lot of organizations aren't quite that mature, so what I would recommend is Jeremy's put together some really good information on GitHub in the documentation for dependency check that really shows you how dependency check works, how the evidence-based analysis works, and why triage is, is, is a necessary evil. Not all of the dependency check findings are going to be accurate, right? There will be, because it uses evidence-based analysis, there will be false positives. So just because the tool says that you know, this thing has a vulnerability in it, it may or may not be true. Pay attention to the confidence of the findings. A lot of, especially newcomers to the tool because it's evidence-based analysis, ignore that there's actually a confidence there. There's a confidence rating for every single finding, and if it's low confidence, there's probably a very low likelihood that that vulnerability is real for this particular component. Now, medium, there's a 50/50 chance or so, but if the confidence is high, there's a really good likelihood that that vulnerability should be actionable by the development team. So if I was brand new to dependency check, I would look at those, my initial reports, I would focus on the findings that have a very high or very high confidence.

38:12Chris RomeoOkay. Robert, I know you have been a developer for a long time, almost your entire career, as well as being an application security expert and involved in a lot of different things. From your perspective here, what do you think is the— what do you think is the excuse we're going to hear from developers as far as why they can't use software composition analysis or why they can't use dependency check or they can't dependency track. Any thoughts about what do you think, I guess, putting— I know you wouldn't ever say this because you're deeply involved in development and security side both, but what do you think you— what would you expect to hear as far as excuses for why this won't work from developers who are trying to push back against security?

39:01Robert HurlbutYeah, that's a tough one to answer for the same reasons you mentioned. I remember using dependency check a number of years ago, a little after it came out, and trying it out and thought, hey, this is great. But at the time, I think the barrier maybe was it wasn't quite automated yet. We were still just, at least where I was, trying to figure out how to automate these kinds of things in the build process, still getting up to speed on that. And so I think probably one barrier may be, especially for teams that are still trying to figure this out, is how do we integrate it? How do we make it part of the build process? And so maybe the one argument could be is, hey, it just takes time. That's one more thing I have to do. Geez, you want me to do threat modeling, you want me to do code review, and now you want me to run some other tool to check my code. So they may come back and say something like that as to why they may not want to do it if it's some other thing that they have to do on top of all the other things that they feel like they have to do. But I think to the point that Steve was making in terms of how today can you integrate these things, some things that are there and available and make this a little easier to integrate, I think will go a long way towards maybe dispelling those kinds of arguments.

40:29Chris RomeoYeah, so Steve, based on that, how would you respond if you heard a developer say that? to you, hey, you know, you're asking us to do all this other stuff and it just looks like dependency check is going to make— it's just going to take more time in my already busy schedule. How would you respond to that developer?

40:46Steve SpringettI think the approach in a lot of these particular cases actually is more of an organizational type issue. Security really needs to be part of the culture. If component analysis, which in my opinion is one of the easiest forms of security analysis that any development team can do, if that is a problem, then we have a larger organizational problem. In my experience, a lot of these public exploits, the Equifax, the Targets, the you name it, this is great for selling the importance of security to organizations because they don't want to end up in the paper next. So I've actually used this to get teams and management motivated to making sure that security is definitely one of the priorities, strategic priorities going forward.

41:44Chris RomeoYeah, and I think Robert and I both agree with you as far as the importance of security as part of culture, and that's a great point there that if they're pushing back on something as simple as component analysis, they're probably in a lot bigger trouble in a lot of other types of areas. And so that's— it definitely signifies a culture problem. So I guess as our— as my final question before we wrap up here, what do you see as the future of OWASP Dependency Check and Dependency Track? Where's this project going?

42:14Steve SpringettThat's a great question. So, um, we— as big as Dependency Check project is, uh, Jeremy and I have only had like one so far, meeting in terms of project updates and stuff like that. I can't really comment on dependency check. I know that I am going to be adding the VulnDB support for that. For organizations that have purchased a subscription to that, I'm going to be adding that as a data feed. I started doing the Retire.js and we need to wrap that up as soon as we get over a few hurdles with that. Additional feeds will definitely be coming. Dependency Track, I use the GitHub milestones. There's some really great stuff coming for Dependency Track, the ability to perform analysis on all the findings, for example. There's other types of data feeds that we're going to be doing. So I'm using the GitHub milestones for that. If people are interested, I highly recommend checking out the GitHub site. You can get to the website at dependencytrack.org or just find it on the owasp.org website.

43:27Robert HurlbutOK.

43:28Steve SpringettBut there's a lot of interesting things coming from dependency track this year and into next. Then for the future, this is really interesting to me. I don't know if I'll write a talk on this or not, but it seems to me that regardless of OWASP or regardless of SCA vendor, We're essentially playing whack-a-mole, right? Vulnerable component, oh, okay, identified, upgrade. And in my opinion, whack-a-mole is not a strategy. That's what you do when you don't have a strategy. And we're in 2018 now, and I can define APIs, and I can automatically provision servers and clients, and they can automatically start talking to one another. I hope somebody smarter than me is working on something really great that will make software self-evolve. We constantly talk about software is eating the world, and I agree. We're framing it in this biological metaphor, and yet we treat software like an assembly line. It's not. It's always evolving. I think our library and component usage needs to automatically evolve with it. Like I said, I hope somebody smarter than me is working on this problem, but whack-a-mole, in my opinion, is not a strategy. That is unfortunately what we have to do in the foreseeable future though.

45:03Chris RomeoAnd that's even— so you're even talking about something that's bigger than— it's almost a replacement for this idea of SCA. If your software is self-evolving and it can upgrade to new versions as new versions are available And so that your patch readiness or your patch— you're always patched to the latest revisions and things through the actual operation of the software. And yeah, that sounds like a great thing, and I also hope somebody's working on that. I guess I just start to wonder where does that end, right? I mean, that Terminator, that Skynet thing, like, is that a— Is our software going to eventually take over and start running the podcast for us here?

45:46Steve SpringettYeah, I saw a tweet, I think it was last week, and it was a joke, but it was based on reality in the fact that, like, the Node— they were talking about the Node ecosystem, the fact that I think a component, the average component lifecycle, I think is 11 days or something like that. And they were talking about how next year or whatnot, it's going to be a matter of hours. And in the not-so-distant future, by the time you start building to the time you you end building, your components are already outdated, right? That was the, you know, that was kind of the premise of the tweet. And but the problem with that is that I think there's a lot of truth to that. I really do. So the whack-a-mole at that point, it's, it's not a winning strategy. We need something better than this.

46:35Chris RomeoYeah, and that's— we leave that to lots of smart people in the industry that are probably hidden behind closed doors right now building the next generation of whatever's next after SCA. But I look forward to seeing that as well. And I think you're onto something here, at least defining the problem space about where this technology needs to go in the future.

46:58Robert HurlbutRight.

46:58Chris RomeoSo, Steve, we thank you for your time today introducing us to Dependency Check and Dependency Track. And also, thank you to all the hundreds, if not thousands of hours you've dedicated to the OWASP organization in building these tools and making them better. As somebody who's a consumer of this and also a recommender, I just want to say thank you for, for making awesome tools that we can use. We appreciate it.

47:22Steve SpringettYeah, awesome. Thanks, Chris. Thanks, Robert. Appreciate your time today. Thanks for listening to the Application Security Podcast. If you enjoy the podcast, please do us a favor and visit the iTunes Store and give us a 5-star star rating. Our intro music is 8-Bit Kung Fu by Born and TJ, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @AppSecPodcast or on the web at www.appsecpodcast.org.