Jeremy Long — It’s dependency check, not checker

0:00Chris RomeoJeremy Long is a principal engineer specializing in securing the SDLC. Jeremy is the founder and project lead for the OWASP Dependency Check project, a software composition analysis tool that identifies known vulnerable third-party libraries. Jeremy joins us to share the origin story of Dependency Check.

0:17Robert HurlbutHe'll cover the problems that Dependency Check solves, how many organizations actually use it, and how you can integrate it into your own company.

0:26Chris RomeoPlus, he'll get into what the future holds for Dependency Check.

0:28Robert HurlbutWe hope you enjoy this conversation with Jeremy Long. You cannot hack yourself secure. Everyone wants to focus on the offensive side of the equation. The challenge is that developers get bored with hacking broken pieces of code after a while. Sure, it's a shiny, cool new thing in the beginning, but how about one year later? At Security Journey, we focus on long-term sustainable security culture with the developers as defenders. Our approach integrates experimentation, together with learning. We believe that developers need hands-on experience, but not at the expense of fundamental knowledge.

1:05Chris RomeoVisit www.securityjourney.com to sign up for a free trial of the Security Dojo or schedule a demo. Jeremy Long is a principal engineer specializing in securing the SDLC. Jeremy is the founder and project lead for the OWASP Dependency Check project, a software composition analysis tool that identifies known vulnerable third-party libraries. Jeremy joins us to share the origin story of Dependency Check.

1:41Robert HurlbutHe'll cover the problems that Dependency Check solves, how many organizations actually use it, and how you can integrate it into your own company.

1:49Chris RomeoPlus, he'll get into what the future holds for Dependency Check.

1:52Robert HurlbutWe hope you enjoy this conversation with Jeremy Long. Hey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey and also co-host of this podcast.

2:08Chris RomeoAnd I'm also joined by Robert. Hey, Robert. Hey, Chris.

2:10Robert HurlbutYeah, good to be here. Robert Hurlbut, threat modeling architect.

2:13Chris RomeoAll right.

2:14Robert HurlbutWell, the topic we have for today is something I feel like we've talked about quite a bit, but we're going to get very specialized in understanding and OWASP project that plays in this whole software composition analysis space. We're joined today by Jeremy Long. Jeremy, we're going to dive right in as our listeners expect and have you tell us your security origin story.

2:41Jeremy LongExcellent. I started in security probably back in about 2000, 2001 timeframe. I was out in Seattle. I was working for a company that completely folded, went out of business. And at the time, I was a fairly junior programmer and could not find a job because this was right during the dot-com bust out in Seattle and senior programmers were taking all the junior-level programming jobs. So I was lucky enough that my brother was actually working for a company in Minneapolis. They called me up and said, hey, we have to do a security code review of a 2 million line C/C++ application, and we just need to find bodies that we can throw at this. And I was like, well, I can totally read C/C++, no big deal, but I don't really know a whole lot about security. And he's like, don't worry, we'll send you a white paper to read on the plane. So they flew me out to Minneapolis, and there were 10 guys in a room. doing at the time a manual code review of this application because there weren't really a lot of security audit tools out there. And that's really where I got my start in on this. And what's funny is at the end of that 10 days, we had the— or 2 weeks, we had the 10 guys reviewing code. I was one of 2 people that actually found something. And I found the reason the developers had to reboot the server every 3 days because they had an inconsistent view of what 1K meant. So, you know, one developer's copying between buffers at 1,000 bytes and the other one's copying at 1,024. And so they're getting these little memory corruption every once in a while for large strings. That was like one of the only 2 things that was identified. And again, that's a trivial fix for the company that we identified that for. It's a sed inline replace, 1,000 to 1,024. I mean, it's not quite that simple. You had to do a lot of regression testing, but to fix it, it's not that—

4:37Chris RomeoYeah.

4:38Robert Hurlbutdifficult.

4:38Jeremy LongBut that was kind of my intro to security. And then I got hired onto a team to do manual code review. And I know it sounds exciting to do manual code review. I did that for about 9 years. You would be amazed at what you learn reading other people's code. The first couple of years, yes, it was all manual. But then we built, bought tools, etc. And it was really a fun and interesting to be one of those guys that I'm like, hey, I'm solving this problem manually by reading the code. How do I never have to read the code again for this vulnerability? And you'd write a tool, write a rule, do something to automate it so that you never had to find it again. And so that's been a lot of my career in security is figuring out how to automate things.

5:30Chris RomeoAll right.

5:31Robert HurlbutSo you said you did manual code review for 9 years. What is the funniest thing you've ever seen in a comment?

5:38Jeremy LongOh, in a comment, swearing in French. But, you know, you just see some really ridiculous things, sometimes not even in comments, you know. You'd find code where it said, you know, encrypt password, something like that, and, you know, return a string. take a string, return a string. You look at the body of the method and it was just return string. What are you doing? We're encrypting, you know, ROT26, it decrypts pretty quick.

6:18Robert HurlbutWell, it's good for performance.

6:20Chris RomeoExactly.

6:22Robert HurlbutAutomation being something that you've seen the real use for, makes sense for where you've landed in the OWASP universe here. You're one of— you're the project lead, right, for Dependency Check?

6:37Jeremy LongCorrect, yes.

6:38Robert HurlbutOkay, so we're gonna go, go off the script a little bit here. And normally we just, you know, we're talking about your security origin story. I'm curious about Dependency Check's origin story. When did this project start? Why did it start? Tell us kind of the, the backstory behind Dependency Check.

6:57Jeremy LongAh, so this is something again At my day job. It was something that I was doing manually back in probably 2009, 2010, 2011, where we'd go out and search for things at the NVD, Secunia, etc., all of the places that you could go online and search for vulnerabilities in struts and things like that. There were no tools on this at all, but these were issues that we had been citing. And sometime in 2011, I kind of came up with a harebrained idea that I could automate this. And I actually started, you know, writing the code for it. And I, you know, took it to my management chain and said, this kind of seems to be working. I mean, I'm not saying it's perfect, but it's better than what we're doing. Right now because if it finds something, we don't even have to do any more manual searching. And I want to open source it because I don't think it's something that we wanted to keep internal just to us because I thought it was a solution that would benefit from contributions from other people and it absolutely has. Had we kept it internal, it probably would not be even close to where it is today.

8:21Robert HurlbutOkay.

8:21Jeremy LongSo, I took it to my management chain, had to talk to a whole lot of people to get agreement to open-source this. And in 2012, I was able to release the first version of Dependency Check. And I'm sorry to people who used it, that first version was a little rough. But we have improved a ton over the years. I still remember, like, one of my first meetings where I actually demoed this to people. And man, it is a tough crowd when you're introducing something brand new to the industry. Because when I open-sourced this, there was one, I believe there was one commercial product on the market from Codenomicon, who I believe is now owned, I believe, by Synopsys. And the first paper by Jeff Williams and Arshan, came out called The Unfortunate Realities of Insecure Libraries. That was a paper they did in conjunction with Sonatype to kind of highlight this problem. And my tool came out shortly after their paper. So, it was kind of, like, really good timing on that. And then the market exploded over the next, you know, 5, 6— it's still going with the amount of people trying to deal with the software composition analysis problem and keeping things up to date.

9:43Robert HurlbutSo, when we think about dependency check, what is it actually doing under the hood?

9:50Jeremy LongFuzzy matching. In all honesty, that's under the hood what it's doing. And I've talked about this in some of the talks I've given about dependency check. One of the problems that we have in security, or the differences between developers and security, is developers will call a library you know, by their Maven coordinates or something along those lines. So, like, dependency check would be— have a group of org.owasp, and the artifact ID would be dependency-check-core, and then there would be a version number. You know, I just released 5.3.0. Actually, yesterday, I just released a new version of dependency check with a lot of improvements. But when you get into security, security is a lot about pointing fingers and blaming the vendor. And so we might have a vendor name in there instead of a group ID. And sometimes the vendor name is in the group ID. So like the Maven coordinates, it lines up pretty well. And in other cases, not even remotely close. SpringSource, the Spring Framework, is currently owned by Pivotal. There is no mention of Pivotal in the group artifact designation for the Spring Framework. And yet if you go out into the NVD, you'll actually find Pivotal, Pivotal Software, Spring Framework, VMware Spring Framework, and Spring Framework all are identifiers for different vulnerabilities that have occurred in the Spring Framework. over the years. So, how do we match what the developer coordinates are to what security is saying about this? And so, I built a tool to do what I call evidence-based identification of these libraries to get to figure out what that— what security is calling this library because all I have are the developer coordinates. And the developer coordinates, and I also grab as much textual information as I can from the dependencies, from the build system, from the dependencies, any information that I can gather, be it package names, entries from a manifest. If we're doing .NET, we actually look at the extended property files of the DLLs or assemblies. We collect all this information, we put it into vendor, product, and version number evidence collections. And that's kind of ranked on high confidence to low confidence evidence depending on where we got the information from. And we use that information to query a Lucene index. I use Lucene in a very interesting way. Lucene is one of those projects where you can index the Library of Congress and do very fast searches against this. I'm using the Lucene engine to index 2 fields, vendor and product, from the common platform enumerations that are used within the NVD data. Common platform enumeration is how security identifies a piece of software. And so I have a Lucene index with some— it's got some specialized things that we've done to make the searches work out really well. But we use all this evidence that we collected and we search against the Lucene index. That's why I just say it's, you know, we're basically just doing some fuzzy matching to, you know, match between these 2 identifiers. And this works out— what we found is this works out really, really well. And that's why dependency check is— I've been able to maintain it and keep it going, because I'm okay maintaining code. I like code. If I had to maintain a database of developer Gav to CPEs, I wouldn't be doing that job very long. That's boring. So I built a tool to help do that matching for me. The other thing that that does is, as products change owners over time, which we've seen with, again, like I always point out, Spring, it was SpringSource, then VMware SpringSource, and now Pivotal. My tool actually does the fuzzy matching, and it actually has been able to track that over time on some of these products.

14:14Robert HurlbutSo after the tool runs, it gathers this evidence, puts it all together into an index that it can search at a very high rate of speed, and then if it finds a vulnerability, it basically reports on that to say, hey, you've got a vulnerable component that's included inside of your build.

14:33Jeremy LongExactly, yeah. We do the identification layer to map from the library to the Common Platform Enumeration, and then we use that Common Platform Enumeration to look up all of the data all of the vulnerabilities within the National Vulnerability Database. In, in some recent versions, we've actually done more than just the NVD. We've actually had contributions from Sonatype. They've donated an OSS Index client and helped build that integration out. So we're not solely relying on the NVD anymore. We now have the OSS Index. We've got the NVD, of course. We're also using wrapping some other tools such as Retire.js. And we also, for Node projects, we are also going out to the Node audit APIs and pulling down Node vulnerabilities. But at its core, the original was this mapping within the NVD and looking up these vulnerabilities. We've expanded that to wrap other tools for other technologies. We also do bundler— wrap bundler audit and get the results from that. And what this allows is us to get consolidated format for a lot of tools into just a single dependency check format. And it really helps for some of the multi-language projects that you might have, where, you know, there might be information from Retire.js and Bundler Audit. And so, if you've got a Ruby application with JavaScript, you know, your Bundler Audit may not see some of the JavaScript vulnerabilities, and you'd have to run multiple tools. Dependency Check has been— we've been kind of consolidating things, and we're even looking at a couple other ways that we might be able to bring in other tools because these very specialized language tools are awesome. They're doing great work, but, you know, sometimes you need a common format for a lot to be able to use and build reporting, etc., off of.

16:31Robert HurlbutWhere does this— where does Dependency Check break down, and what would you say is the accuracy of this tool, percentage-wise?

16:39Jeremy LongPercentage-wise, I don't— honestly, this is one that I think a lot of people are going to be shocked at. I haven't used Dependency Check professionally for many, many, many years. Probably, yeah, it's been 5, 6 years at least since I haven't used the thing professionally. And I've continued to maintain it because I get such positive feedback from people on this. I know it does really well on Java, especially if you integrate it into the build and you're using the Maven plugin or the Gradle plugin or even the SBT plugin, which is being maintained by another individual. It does really well on Java. Probably the next best one it does an okay job on is .NET assemblies. Then when we get into things like Bundler audit for Ruby. It's, well, it's just wrapping Bundler audit. So it's on par there with Bundler audit. Where Dependency Check right now falls down that I— the one that I know that it falls down on is mobile. It does not do a very good job with mobile. Well, especially on the iOS side, probably does a little bit better on the Android side. But that's one that I have had reports back from peers in the industry have said, have kind of let me know that it doesn't work very well on mobile. And that may be one of the opportunities that we have in the future to try and work to improve it. Because for each different technology stack that we have been trying to support, I need to get a lot of projects to kind of help tune the analysis and make it better. I said recently the 5.3.0 that I released yesterday actually has a lot of improvements for Node at the moment. We actually did a lot of things to fix a lot of the bugs that people were having, but also the combination of the OSS index and the Node Audit API. We also introduced just straight looking up vulnerabilities from the NVD. And what I found doing that is we actually got higher fidelity results than— like, we were finding vulnerabilities that weren't necessarily reported by npm audit. We had a couple that were reported by the OSS Index, and we were able to get even for the ones that were reported by npm audit. One of the things that they have is they have some what they call unscored vulnerabilities where they might have like a 0 as the score because generally those are like on low-type findings from npm audit. Whereas if you went out to the NVD, you actually have the CVSS version 3 score, and so it might be like a 2.3. So, we're able to combine the data sources to improve the analysis. So, I mean, that's really key there. So, I just need time and energy on all of these things to improve each language or each technology stack language. And I think mobile is probably on the roadmap of things that I'm going to try and help out with in the near future.

19:49Robert HurlbutYeah. And this is a good reminder of kind of how OWASP works for those people that don't realize. I mean, Jeremy is not getting paid or there's no real benefit, financial benefits. You're doing this, right, because you want to just make the world a better place, a more secure place?

20:07Jeremy Long100%. Yeah, it's, uh, I've been, you know, people who find out like how much of my time I spend coding this thing just to try and promote and, and help the industry, uh, there's been many years where between 5 AM and 7 AM I'm at Starbucks coding, and that's just because If I'm putting something out there like Dependency Check for people to use, I want it to be the best product I can make it. It's not just something I'm posting some code out on GitHub, doing a talk on it, and going home. If anybody wants to use that code, good luck. I'm really trying to make it the best that we can.

20:44Robert HurlbutWhen we interviewed Steve Springett, one of the project leads from Dependency Track, I told him the same thing I'm going to say right now. Between you and Jeremy, you guys have a couple of projects here that rival what a lot of commercial products are providing. And yet both of you have put those projects forth into open source and you're not making any money or anything on something that you really could have. And so I think that's just such a cool thing that you're doing though, is that you want to make the world a better place, a more secure place. And you're folks that are really putting your money where your mouth is, even though there's no money really behind this.

21:25Jeremy LongWhat I've told so many people during talks, I mean, Dependency Check, it's free. Use it. If you're not doing anything else, use it. And you know what? When you're using it, you can use it to make the case to buy a commercial tool because not every organization really wants to put something like this into the pipeline, or I mean, depending on size, culture, everything else. they're going to want commercial support. I don't know of any company providing commercial support for dependency check. I know I'm not. So, I don't know of anything out there like that. And so, that's one of the reasons a lot of companies go to some of these other vendors. And the other key is most of the other vendors in, you know, the commercial vendors in this space have private databases of vulnerabilities. They know that PrimeFaces had a, you know, a deserial— I believe it was a remote code execution. I believe it was something like a deserialization. And they knew about this for a long time in their private databases. Actually, I love the story about PrimeFaces. It's one of my absolute favorite vulnerabilities that came out. It was early 2018, I believe this came out. There was a deserialization attack. It was published into the NVD, like I said, early 2018. It was critical. People, like a month later, you were seeing blog posts about, hey, my website just got popped and I have a coin miner on my site now. What's up? It was all due to this vulnerability. Guess when the patch came out?

23:07Robert HurlbutI'm going to guess middle to late 2018.

23:11Jeremy LongActually, I think it was 2 years prior to the CVE being reported. It was clearly spelled out in a GitHub issue on the PrimeFaces repo. And nobody upgraded. And this goes back to one of the— I always forget, is it called SNCC or SNEAK?

23:28Robert HurlbutI still don't know how to pronounce it. I just, I just say it quickly so that people think I, I know.

23:33Jeremy LongYeah. That's where, like, when we're saying why some of the people might want to go with a commercial solution is they have the private databases that actually had that vulnerability in it prior to it being in the NVD. There's a huge gap between what's in the NVD and what's actually known in, you know, open-source repos like GitHub. And that actually gets to one of my talks that I'd given at LocoMocoSec I believe in 2017, I lose track of this exactly. But it was called the Automated— or the Application Patching Manifesto, where I basically am saying that a lot of the stuff that we're doing in software composition analysis today is compliance. It's a checkbox. There have been a lot of massive breaches because of failures in the software composition analysis where we aren't patching. When we do patch, or when we are requiring our app teams to patch, it is generally a nightmare because this is not something that is part of most teams' day-to-day jobs. I mean, you put a library in there, and, you know, it may be there 5 years later, same library, because it's not broken, we're not seeing any regressions. And that's actually quite common, where you see very old libraries. And Where I've been trying to get people to move is that we just need to do continual patching of our libraries, make it part of the SDLC. There's amazing tools out there. Actually, GitHub bought my favorite tool in the market. It's called Dependabot. So, GitHub actually bought this and has actually been incorporating the technology into the GitHub platform itself. But basically, what Dependabot does is if a new version of a library comes out, you get a pull request, your CI kicks off, light is green, you can merge the pull request. Now, of course, that all depends on if you have a good CI suite, test suite. So, you really have to have, you know, quality test cases, etc., to really ensure that you're not gonna have a regression from upgrading. But if you make upgrading just part of your lifecycle like that, you're not gonna have a problem because you know how to patch. It's part of what you do as your day job. Anything that fails in your CI goes on your backlog, and you can work it in to upgrade that library. And if you do things like this, you won't run into issues like we saw with PrimeFaces because the upgrade had been out for 2 years already. The patch was available, you could have upgraded. And had you been keeping everything up to date instead of incurring technical debt— well, that's why I say a lot of what we're doing right now is compliance work as opposed to real security. And I think what GitHub and some of the other vendors in this space are doing is really going to be driving the industry forward a lot to make us more secure.

26:28Robert HurlbutSo, do you think that's the future of SCA then, that we're going to end up with, you know, Dependabot just doing these upgrades for us behind the scenes without us ever having to do anything? Or is there still a market for a dependency check with Dependabot?

26:45Jeremy LongI think there is still a market. Because one of the things like the landscape, it's always complicated. And there will be times where you can't upgrade a library because of technical reasons. You're depending on a feature that went away or something like that. You still need to know that the vulnerability is there. Also, when with some of these automated solutions, this is only working on your primary dependencies. When you look at a real application, it actually has a hierarchy of transitive dependencies, which are dependencies of your dependencies. And that's why you can get a very large set of dependencies for any application is because you might use one dependency and that uses 10 more. Depending on what you're using, that can fork out fairly large, and depending on how much you have. And so things like Dependabot aren't really focusing on your transitive dependencies. At least not yet. There is opportunity there. But the other issue is, and I did recognize this when I did my talk, and I do always try to point this out, keeping up to date to be the latest and greatest also introduces a supply chain risk. We've seen this in the Node.js space, and the npm team has been doing a really great job trying to close some of these holes that have occurred in the past. You know, like ESLint, if you know what happened there. A— I believe it was a dependency, like way down in the chain of ESLint got compromised. And ESLint, when you downloaded the latest version, had malware, I believe, was being distributed. I believe that's what happened with ESLint.

28:34Robert HurlbutYeah.

28:35Jeremy Longwhere you just ended up with getting malware on your build systems, just because you brought in the latest version of something. So, there's been a lot of interesting work in how do you know your build system is secure? How do you know your supply chain is secure? I know Mark Kerfe has been doing a lot of work there. He's built some tools to do, you know, sandboxing of your build system, you know, sandbox your, you know, your Jenkins and monitor what files have changed, monitor what URLs people have been connecting out to. So just while, while it's great to be keeping up to date, you do have to recognize that there might be a risk that if your supply chain is compromised in any way, shape, or form, and you're dealing with open source, you do have— you do run the risk of bringing in something that somebody had maliciously brought in. And that's why I know some people actually talk about bring your own binaries, you know, pull the version from the version of the source code from GitHub, build it yourself, use the one that you built. Because even with everything else going on out there, there's no guarantee that what's in the public repos was actually built from the source code that is published.

29:53Robert HurlbutAnd that only gets you halfway though, right, in the supply chain problem.

29:56Jeremy LongRight.

29:57Robert HurlbutIf somebody introduces a vulnerability on purpose into the library source itself. You know, I think a supply chain risk is really 2 different—

30:06Jeremy LongThere's a lot of risks involved in the supply chain with this, but one of the bigger— I mean, that gets the targeted attacks. Unfortunately, we have to deal with almost the script kiddie level attacks because that's where, you know, The Struts CVE comes out, deserialization attack, everybody better patch and upgrade Struts because you're gonna have bots spamming the internet with that exploit. That's another— that actually brings up another question. I mean, like, do all application— are all application vulnerabilities equal? Not in the slightest. I mean, yeah, you can look at the CVE score, and that's only part of the picture. If you got to ExploitDB and there's a script there, you better elevate your risk around that because it's now script kiddie. It's not just somebody, hey, published a vulnerability, maybe they have a private exploit that they've used. If it's out on like ExploitDB, even some of your lower-risk findings might become a little bit more concerning because it's script kiddie-level attack at that point.

31:17Chris RomeoYeah.

31:17Robert HurlbutSo I want to just come back around to the integration question, but I guess first, how many organizations that you're aware of, or from a download count perspective, how popular is Dependency Check?

31:29Jeremy LongWell, actually, I just pulled up my Maven statistics on this. Let's see, it looks like last month, the core Dependency Check library was downloaded 187,000 times. I know the Docker container has about over 100,000 pulls. They don't really count above that, at least I haven't seen. And the Gradle plugin accounts for a large swath of that. It used to be more on the Maven side, but Gradle has really been taking over on the downloads from Central.

32:04Robert HurlbutAre you able to keep track of organizations or .com .edu and so forth?

32:11Jeremy LongNo, no data actually comes back to dependency check from the use of it.

32:17Robert HurlbutOkay.

32:18Jeremy LongThe only thing that happens is that we— is that the tool itself pulls data down from the NVD. It may reach out to the OSS index. It pulls data file down from GitHub. And it uses the npm audit APIs. So, no data actually comes back to us about the actual usage. I mean, anecdotally, I know some very large companies have been using this tool. You can find this in people, like, when some of their security teams do talks, you're like, wow, you're talking about that, and you use my tool. And I'm not actually gonna name anybody myself, but I do know that that some very large companies have been using it.

33:08Robert HurlbutOn the integration side, what are some of the use cases that someone who's new to dependency check can put in place? And, you know, when I think of this, I think like, is there an opportunity for my devs to run this themselves on their, you know, development machines? Do we run this in the build pipeline? Like, where do you see people fitting this thing in?

33:29Jeremy Long100%. I want people to, you know, I want developers to run this locally. I want to integrate it into the build pipeline. There are some challenges, and we've been working on this with just integrating it into a build pipeline or running it, because it does download the entire NVD database, which, you know, to download and process that, I've seen it take 10 minutes. Right now on my machine, it generally takes maybe 2.5, 3 minutes to do this because we've done some performance tweaks on that. And the NVD has changed their schema, which makes it a little bit better for us. And they've even got some stuff in the works that may help out even more on the performance of that. So the first time you run it, it has to pull this down. So it's going to put a rather large delay on this. But as long as you run it at least once every 7 days to keep things up to date, it just has to download a very small file. If you run it multiple times within, like, 4 hours, it's not even gonna do any downloads. It's gonna wait because it knows that there's really probably been no updates. And so, somebody who runs it locally, they're gonna be like, oh, this is gonna add, like, you know, 3 minutes to my build time, and that really sucks. But if you plan out your implementation correctly, when you're putting this into your pipeline, you know, don't just throw the data directory away or use an internal— we support internal, you know, databases. So you could set up an Oracle or MySQL, SQL Server, whatever. We have a couple of different databases that we support. So you can use a centralized database as opposed to using a local H2 database. And there are even strategies around using a local H2 database within like a Jenkins farm, where you're not necessarily having to rebuild it every single time. And that's one of the things that I've seen some people do incorrectly initially when they're rolling it out. And, you know, they'll throw the entire thing away every single time, and then they're going to incur 2 to 3 minutes of build time. I've seen people actually do this in a you know, cloud build pipeline, where I was talking to people about this, and they're actually spinning up AWS servers to do their build, and they've got dependency check in there. And while it doesn't seem like a lot, if you're talking 2 to 3 minutes, and, you know, network bandwidth, and 2 to 3 minutes of processing in your AWS build, and you're throwing it away every single time, you're just incurring cost that you don't need to. So, And especially depending on how many times you're building, etc., there are caching strategies that you can use to improve this. That's one of the things, the longstanding issues that I haven't actually spent the time to fully flesh out is a lot of these tips and tricks are either in closed issues in GitHub or closed questions in GitHub, or they're in the documentation, but it's like, 2 or 3 sentences, you know, spread out over a lot of places. I haven't yet had the time to go in and put, like, here's an enterprise deployment guide or a real deployment guide, this is how you should use it. We're just, at the moment, that's something that's really sorely lacking at this point. But for the most part, developers, you know, bring it into your tool, put it in Maven, put it in Gradle, run it just to see what it finds. Because if you've never used software composition analysis, you're probably gonna be surprised at what it finds. And from there, you're gonna be able to evaluate, you know, do you wanna go take this to your managers? Do you wanna possibly put the idea out there of going out and looking at some of the commercial vendors? There are, like I said, there's a lot of benefits to using them. They do really great things. I mean, there's a reason they cost what they do. But for, you know, lots of technology stacks like Java, this is doing a pretty decent job. I will say the other thing that I haven't mentioned, because of the way dependency check works, I did say it was fuzzy matching. That means it does have false positives. However, if you open up the HTML report anytime, and I've got a, like, a how to read the report and suppressing false positives, all documented on the documentation site. It's really simple to identify when a false positive happens because it's usually something like, hey, I'm using, you know, net time or some library, and the CPE is like against like Linux kernel time module or something like that. And you're like, yeah, that's nothing to do with anything. And it's really easy. There's just a suppress button. It's a little XML file that gets generated, and you can just drop that right into your build and— or into how you're doing your scanning within your build. And you never have to look at that again. And so it's really easy. The first time you run it on a large application, you know, you might spend 30 minutes, you know, creating a couple of suppression rules, reviewing the results, you know, putting a few tickets on your backlog to do some upgrades, things like that. And, you know, that's the first time you might spend a little bit more time, but after that, your next app, it'll go much quicker.

38:54Robert HurlbutYeah, as you look at the different deltas and stuff there. All right, well, my final question is a statement. Well, it might end in a question mark, and that is, it's dependency check, not dependency checker, right?

39:09Jeremy LongAbsolutely.

39:11Robert HurlbutOh my gosh.

39:13Jeremy LongThere are so many times where, you know, I'll be in the audience on a talk, and like I said, you know, from some vendors or, you know, large corporations, their security team getting up there using it, and they're like, and we have dependency checker in the build pipeline, and I just cringe. Yeah, I know, I could have come up with a better name, but I'm not very innovative with, you know, with some of my naming. And so, I kind of called it what it did. It was a dependency check. That's the It's checking the dependencies for vulnerabilities, and it just drives me up the wall when somebody says dependency checker.

39:46Robert HurlbutWe're going to work to eradicate the use of dependency checker from across our industry. I'm taking this on as a personal challenge now. If I hear it at a conference, I'll just stand up and holler or something.

39:59Jeremy LongI don't know.

40:00Robert HurlbutJeremy, what are your kind of final thoughts, I guess, you would leave our audience with when we're thinking thinking about Dependency Check?

40:05Jeremy LongOh, try it out. Seriously, software composition analysis is one of the large issues facing the security industry. It's been one of the causes of some massive breaches. And if you're not doing anything in this space, this tool is free, covers a lot of technology stacks. Java, it handles Java the best, and it kind of goes down down from there, but we do have a lot of support and it will help out identifying some of the risks that you may have and you may not know about.

40:38Robert HurlbutJeremy, thanks for taking the time to share your origin story and the origin story of DependencyCheck, and keep up the good work.

40:47Jeremy LongThanks.

40:49Chris RomeoThanks for listening to the Application Security Podcast. 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.