When a development team begins analyzing their third-party code for vulnerabilities, OWASP’s Dependency-Check is usually where they start. It’s a free software composition analysis tool that checks applications for vulnerabilities in their software supply chain.
Dependency-Check (D-C) has its strong points. It covers a wide variety of languages (even more than some commercial tools), and given its popularity, a good deal of other tools support D-C. Plus, D-C is well-known for erring on the side of vigilance—when their reports are accurate (more on that later), they’re pretty useful.
This makes Dependency-Check a cost-effective way to begin securing your software supply chain: your team can gain experience and build processes around scanning for vulnerabilities and patching them. However, as is the case with most free tools, a maturing DevSecOps team eventually outgrows D-C and moves on to a more advanced SCA solution.
So when is the smartest time to graduate from Dependency-Check to a premium SCA? In this guide, we outline four signs that it’s time for your organization to move on from D-C to a paid SCA solution—plus notes for building the business case for your leadership team.
4 signs your organization has outgrown OWASP Dependency-Check
It’s time to graduate from Dependency-Check when the cost of remaining on D-C outweighs the cost of using a premium SCA solution. Since D-C is free, its true cost often goes unnoticed—the “cost of free” is usually hidden in labor.
But a smart DecSecOps leader will watch for the signs that D-C is becoming more trouble than it’s worth. If you notice any of these four phenomena happening on your team, it’s probably a good time to seriously consider graduating to a paid SCA tool.
1. Developers are experiencing vulnerability fatigue from false positives
This is the number one reason people move to a premium tool: Dependency-Check is notorious for false positives. In our tests, we’ve found that D-C is liable to report 5–10 times as many false positives as the leading commercial SCA tools.
This is because Dependency-Check tends to take an overly-vigilant approach to flagging issues in your application. Whereas paid tools tend to use more advanced scanning practices to detect vulnerabilities, D-C is known to rely on blanket, imprecise indicators—for example, D-C has flagged all libraries that contain certain keywords in their name as vulnerable instead of actually checking their code.
This is not sustainable for a growing development team. If your people begin to view all vulnerability reports as potential wild goose chases, they’ll be less inclined to spend their time implementing fixes—which can allow actual vulnerabilities to linger in your applications. In our 2022 survey, 62% of respondents felt that false positives had an overall damaging effect on team morale, and 55% indicated that false positive reports damaged relationships between their team and other teams within the organization. Plus, more than half of respondents said that determining whether an alert is a false positive takes even more time than fixing a true positive.
If you find that your DevSecOps team is getting fatigued by all the false positives Dependency-Check generates, it’s probably time to upgrade to a more accurate solution.
2. You’re creating processes around Dependency-Check’s limitations
Because Dependency-Check is free, it’s common for new teams to work around its limitations in the early days. However, if you find that your entire approach to remediating and mitigating third-party vulnerabilities is built around Dependency-Check, you’re in a tenuous position.
Ideally, your security procedures should be built with your business’ needs at the forefront. But if your processes are built to first accommodate Dependency-Check and then address your business needs, you’ve hung your entire DevSecOps team on a free tool—and one that won’t provide you with the protection you need in the long run.
And if you’re spending valuable developer resources on making Dependency-Check work for you, it’s smart to consider whether or not that labor could be more effectively applied elsewhere. It’s common for organizations to build and maintain elaborate spreadsheets for correcting against D-C false positives—and we often see DevSecOps teams developing scripts strictly to navigate D-C’s limitations.
This is not a good position to be in, because you’re effectively homebrewing an SCA tool on a faulty foundation. Unless you’re a cybersecurity application company, you probably don’t want an ad-hoc house-made solution to be your primary line of defense against transitive vulnerabilities.
All this effort is usually more expensive than a premium SCA tool would be. Advanced solutions should pay for themselves by delivering accurate reports and performing advanced security capabilities that Dependency-Check can’t, freeing up your dev team to focus on value-generating activities.
For example, a premium SCA like MergeBase supports security governance: it can automatically block a build from going live if it contains vulnerabilities above your company’s accepted policy level. But Dependency-Check can’t do this—you would need to build this yourself if you wanted to automatically stop your team from publishing unacceptably vulnerable code.
3. Your DevSecOps team is spending excessive time researching patches
Finding vulnerabilities is only the first step. Once they’re flagged, and once you’ve finished the process of determining they’re not false positives, your developers need to research patches to see if the solutions are compatible with your existing application.
This can take a long time to do—and many companies never get around to it. In a 2021 IBM Security™ study, 59% of respondents cited delays associated with patching vulnerabilities as a reason their organizations hadn’t become more resilient to cyber threats. The vulnerabilities were known—the patches just weren’t applied. In fact, a 2023 Synopsis report on more than 1,700 codebases found that 84% of codebases contained at least one known vulnerability, and 48% contained at least one high-risk vulnerability.
Unfortunately, Dependency-Check doesn’t do your developers a lot of favors on this front. Unlike MergeBase and other premium SCAs, D-C does not provide insight into the dependency tree, so your developers often lack visibility as to where the vulnerabilities sit within your application. Furthermore, D-C doesn’t give your developers insight as to patch compatibility, and won’t let your team suppress vulnerabilities to keep your application running while you address security issues.
If you’re using D-C as your only SCA defense, then your developers are likely spending inordinate amounts of time researching new component versions, checking for issues in updates, validating patch effectiveness, and checking for compatibility. A premium tool gives your developers guidance in all of these areas—letting them quickly fix problems and get back to other valuable tasks.
4. Your dev team needs to build and maintain custom Dependency-Check integrations
Ideally, your SCA tool should feed alerts into your ticketing system (e.g., Jira) and communications platforms (e.g., Microsoft Teams and Slack). But Dependency-Check doesn’t do this.
Instead, teams who rely on Dependency-Check need to build their own custom integrations between D-C and their other tools. This is yet another time- and labor-intensive means of using a “free” tool—and it ends up being more costly than it would be to simply use a premium solution.
“But Dependency-Check is free!” How to build a business case for a premium SCA solution
If you’ve read this far, you probably already know that it’s time to graduate from Dependency-Check to a premium SCA tool. You probably also know that the immediate response to suggesting this upgrade will be, “Why should we pay for an SCA when we can use D-C for free?”
We’ve found that the following three arguments are especially helpful for teams making the case to upgrade to a paid SCA. Here’s how to build your own business case for moving to a paid option.
1. Calculate the current cost of time spent on false positives
False positives are the value killer for any SCA tool—especially for Dependency-Check. If your tool is sending your team on the hunt to solve problems that don’t really exist, it’s wasting your valuable time and resources. This is where your business case should start.
To build this case, first determine the average number of vulnerabilities that Dependency-Check flags per month. Then calculate the average amount of time spent addressing each vulnerability. Next, find the average percentage of alerts that turn out to be false positives. When you have these figures, you can multiply the cost of labor by the average number of hours spent addressing false positives each month to give management an idea of just how much this “free” tool is costing you.
(From here, you can start assessing other tools to see how they stack up on the false positives front—you might want to reference our analysis of the top premium SCAs for this.)
2. Articulate the soft costs of using Dependency-Check
While the hard costs are going to make the strongest argument, you can also bring up the wear and tear on your teams that Dependency-Check can bring. Like we mentioned before, the majority of respondents in our 2022 survey on the damages of false positives told us that false positives damage morale on their teams and damage interteam relations.
So while the monetary cost of false positives is high, you should also bring up the benefits that a stronger tool can bring to your workplace overall. Using a more accurate tool will reduce vulnerability fatigue, improve relationships between your security team and the rest of your organization, and give your team more time to focus on what matters: fixing the real problems.
3. Center your case on readiness for the future
If Dependency-Check is an uncomfortable solution now, it’s only going to get more uncomfortable as your application matures. As your application becomes more complex, the cost of false positives increases. Plus, as regulations around software supply chain security increase, the need for higher-caliber SCA solutions goes up too.
For example, anyone selling into critical sectors will need to generate a software bill of materials (SBOM)—which gives the buyer a laundry list of the components and subcomponents that make up your software. As of now, Dependency-Check can’t generate SBOMs, but the leading SCA solutions (like MergeBase) can.
But that’s only one shortfall of Dependency-Check. Given the increasing regulations around software supply chain security, you can’t rely on D-C as your sole SCA solution in the years ahead. Ideally, a mature organization will use an SCA that does many things D-C doesn’t, including:
- Providing insight into your dependency tree
- Scanning containers
- Integrating with workflow/ticketing systems like Jira
- Creating notifications in Slack, Teams, or SIEM tools
- Providing advanced developer guidance
- Providing support for security governance
- Reporting on licensing and technical debt
- Allowing your team to temporarily suppress security policies
- Providing runtime security insights
- Protecting your application in runtime (currently MergeBase is the only SCA that does this)
If you want to future-proof your DevSecOps processes, Dependency-Check is not the answer.
Try our premium SCA solution for free
We created MergeBase to fix the problems that software companies often face when dealing with SCAs. Our tool is known for low false positives, excellent developer guidance, and a forward-thinking approach to SBOM generation and compliance readiness.
If you’d like to see what a premium SCA solution can do for you, we encourage you to try MergeBase for free—join us for a free trial and see how easy it is to reduce false positives, increase your software supply chain security, and ready yourself for the cybersecurity environment of tomorrow.
