In the fast-paced realm of software development, managing and updating software dependencies is crucial. Important reasons to keep your dependencies updated include:
- Application Security: Regular updates protect against vulnerabilities and cyber threats
- Stability: Updates fix bugs and enhance the stability of applications
- Performance: Optimization updates improve application performance
- Innovation: Updated dependencies offer new features and capabilities
For obvious reasons, security vulnerabilities in the software supply chain are often the focus of dependency updates, with frequent alerts hitting developers’ queues. The constant state of dependency management is a source of considerable pain for developers. It’s a challenging and time-consuming process, particularly when breaking changes occur in the source code.
Myth: Dependency bumps fix the majority of security vulnerabilities
There’s a narrative in our industry that most open-source security vulnerabilities can be fixed by updating to the patch or minor version numbers of packages based on SemVer (Semantic Versioning). We’ve even heard claims that you can fix upwards of 90% of your security vulnerabilities by doing these dependency bumps alone.
If that were true, we’d be golden. But it’s inaccurate. We know that security vulnerabilities are outpacing remediation efforts and that developers are overwhelmed by the inability to keep up. DevSecOps teams are looking for faster and better ways to manage dependencies with security vulnerabilities.
This narrative is also an oversimplification because when you look at the complex web of dependencies in a codebase, the majority of security dependencies require either a minor or major version update, not just patch version bumps, as per SemVer guidelines. And many security dependencies don’t have the vulnerability fixed in them so you must recognize and treat this code as problematic until a patch is available (if ever).
How do we know all this? Because with the Moderne platform, we’re able to look at the data.
For this article, we’re analyzing real data behind the quantity, level of severity, and depth of security dependencies in a set of Java-based GitHub repositories to provide a better view of how vulnerabilities exist in modern codebases. We also shed light on the level of effort that it really takes to remediate them fully.
How dependency upgrades are automated today
Before we dig into the data, let’s refresh on how dependency upgrades happen today.
Organizations publishing in the open-source ecosystem generally follow the SemVer (semantic versioning) guidelines for versioning new software packages. This means that patch versions should include bug fixes that are backward compatible. Minor versions can add functionality but should also be backward compatible. Only major versions should include API changes that will break your code.
Typically, developers use SCA (software composition analysis) tools to find and bump the security dependencies to the minimum SemVer patch version and sometimes the minimum SemVer minor version that includes the fix. For patch and minor updates, if you assume these have no breaking changes, this bump is sufficient to remediate the vulnerability without further code changes.
However, blindly trusting that every software provider follows SemVer to the letter can lead to problems in your code. We’ve observed that many minor version updates, which by SemVer guidelines should not introduce breaking changes, in fact, do just that. We’ve even seen (to a much lesser extent) instances where patch versions introduced breaking changes. This is why testing remains important.
It's also why some tools that automate dependency bumps offer confidence scores. They know that any software update may not be as straightforward as updating a version number in a file. It can cause breaking changes that disrupt an application’s operation, requiring source code changes. Of course, major software updates almost always cause breaking changes, thus requiring source code updates.
Some of today’s popular tools can automate pull requests for patch and minor dependency version bumps. However, they don’t remediate outdated dependency updates that cause breaking changes to source code. Developers must still make these source code changes manually themselves. And when you’re talking about doing this across hundreds or thousands of repositories, this becomes an impossible task.
This puts developers in the position of making hard choices between which vulnerabilities get addressed immediately and which ones must wait, and in many cases, which ones never get fixed. So, finding faster ways of managing security vulnerabilities and doing it at scale is critical.
Moderne produces rich data on dependency vulnerabilities
Now, back to digging into the data using the Moderne platform.
The Moderne platform offers today’s most comprehensive view of your codebase. The platform is built on top of OpenRewrite—an open-source ecosystem that provides expert code transformation recipes supporting modern languages and technologies. Recipes are programs that can find issues at scale and automate fixes to the source code.
In addition, as a by-product of running a recipe, the Moderne platform has the unique ability to extract and aggregate structured data across a large set of code assets—millions of lines of code. It produces “data tables” that are expressed in tabular formats like CSV and Excel. These data tables enable you to deeply analyze and gain real-time insights into your code.
One key recipe that drives rich code analysis and updates for organizations is the “Find and Fix Vulnerable Dependencies” recipe, a software composition analysis (SCA) capability that detects publicly disclosed vulnerabilities in your dependencies.
The data table from this recipe provides real-time insights including:
- A summary of what the security vulnerability is
- The level of severity of each vulnerability (critical, high, moderate, or low)
- The number of direct (depth=0) or transitive (depth=1 to x) dependencies
- Whether a patch version update could address the vulnerability
The vulnerability information is based on the GitHub Security Advisory Database, which aggregates vulnerability data from several public databases, including the National Vulnerability Database maintained by the United States government.
The data: 70% of vulnerable dependencies require major or minor version updates
For the data-analysis exercise in this article, we have run this recipe on dozens of Java-based GitHub open-source repositories to assess the vulnerability situation. The recipe produced a data table, a portion of which is captured in Figure 1 below. We’ve also posted an Excel spreadsheet with the data table here so that you can explore it yourself in more detail.
The results show that this group of repositories have a total of 1,307 direct and transitive dependencies on libraries that are known to have security vulnerabilities. In this spreadsheet view, green cells are for security dependencies with patch releases that should be easier to adopt, yellow is for minor version updates that may or may not cause breaking changes, and red is for major version updates that are expected to cause breaking changes. Orange is for security dependencies that have no update to fix a vulnerability and should be treated as though they would be difficult to upgrade until a fix and its level is determined (if ever).
From these insights, you can determine how critical, disruptive and potentially time-consuming these security dependency updates are going to be to remediate. And how painful it’s going to be for your development team if you don’t have source code auto-remediation.
In Figure 2 below, you can see a detailed data breakdown of the state of vulnerabilities in the open-source repositories under analysis.
Of 1,307 direct and transitive dependencies with vulnerabilities:
- 392 require a patch version bump (30%)
- 649 require a minor version bump (50%)
- 135 require a major version bump (10%)
- 131 have no fixed version available (10%)
So immediately, you can see that 30% of vulnerabilities could likely be remediated by adopting the latest patch release. However, the majority of dependencies (70%) require either a minor or major version bump or have no fix available, any of which could involve source code changes.
Through this data analysis, you can see that the narrative about being able to fix the majority of security vulnerabilities with dependency bumps is at best a bit of an overstatement. At worst, it leaves a lot of exposed vulnerabilities in your codebase that require prioritization and manual fixes if you don’t have auto-remediation. Based on our work with other open-source repositories, the results would have similar trends as this analysis.
The security remediation problem is solvable, and a solution exists today
There’s a growing sense of discouragement around security in the software industry today, with the pace of security flaws surpassing our ability to address them.
At Moderne, we know that the problem is not insurmountable because we provide a way to fix it.
A paradigm shift: Software dependencies and vulnerabilities are everyone’s business
We firmly believe that our industry needs to undergo a paradigm shift when it comes to the work of securing and maintaining source code. Instead of reporting dependency problems, we should be automatically remediating them.
Moderne makes this possible because when you run OpenRewrite recipes, our platform searches, automates project dependency upgrades, and fixes the code simultaneously. Developers just have to commit the changes.
What does this shift mean for you?
- If you are a security practitioner, you can now help developers fix vulnerabilities in their wide and growing surface area of code. With new auto-remediation tools in hand, you can issue a recipe to automate the remediation of CVEs. This can help eradicate vulnerabilities across codebases industry-wide, greatly reducing business risk.
- If you’re a source code owner or development team drowning in technical debt, you can now redefine what that means to your organization and no longer accept changes from third-party providers as your debt. You can change perceptions and expectations with automated source code remediation.
- If you are a framework author or vendor making breaking API changes, you should help your users adapt to your changes by providing the fix for them rather than leaving it to every one of your users to deal with them. You can automate how users upgrade to your next version, enabling them to fix vulnerabilities and leverage new features more quickly. We believe users will begin migrating to frameworks that provide auto-remediation.
For more information about how you can dig deeper into your vulnerabilities and other dependencies and remediate them automatically, try Moderne for free or schedule a meeting with us.
