Patches deployed for dependency vulnerabilities cause breakages 75% of the time, a new report has revealed. Minor updates were found to break clients 94% of the time, and for version upgrades this was 95%.
Software dependencies — the external code or libraries that a project requires to function properly — are notoriously difficult to manage during application development. Remediating vulnerabilities in dependencies requires a major version update 24% of the time.
“Seemingly the most straight-forward solution is to upgrade to a non-vulnerable version of the dependency,” said the authors of the new 2024 Dependency Management Report from software supply chain security company Endor Labs.
“However, what sounds easy in principle — after all, you just need to update the version identifier to a non-vulnerable one, right? — can cause compatibility problems and regressions that break an application during development.”
Researchers at Endor Labs analysed vulnerability data from internal and external sources to gauge trends in software dependency management for the report.
SEE: Software Supply Chain Security Attacks Up 200%: New Sonatype Research
The report also found that there are several inherent issues with reporting and patching dependency vulnerabilities, as 69% of advisories are published on CVE, blogs, GitHub, and similar platforms after a patch has been released. The median delay between public patch availability and the publication of an advisory is 25 days.
These factors significantly widen the window of opportunity for attackers to exploit vulnerable systems via software dependencies.
Despite making programming easier, the increasingly popular artificial intelligence libraries are exacerbating the existing issues of dependency vulnerability management. More specifically, vulnerability reporting in AI libraries is inconsistent, with numbers varying by as much as 10% between public advisory databases, the report found.
Phantom dependencies — hidden, undeclared libraries in an application’s code — are also more common in AI and ML software projects, according to the report authors. AI projects tend to be written in Python, a language notorious for phantom dependencies because it allows dynamic or indirect package installations that bypass manifest files.
Phantom dependencies only formed a significant part of the dependency footprint for 27% of the businesses whose data was analysed for this report. But within that group, over 56% reported that library vulnerabilities were in their phantom dependencies.
A quarter of advisories contain either incorrect or incomplete data, according to the report, which can lead to false positives and false negatives.
Nearly half of those in public vulnerability databases across six common open-source ecosystems also do not contain any code-level vulnerability information, such as the names of affected functions or fix commits. In fact, only 2% contain any information about affected functions at all.
Identifying connections between apps and vulnerabilities within their dependencies is technically challenging. However, this information is essential for security professionals to know whether the vulnerabilities pose a risk to their applications.
Without it, they cannot quickly filter out irrelevant vulnerabilities, which many of them are. The Endor Labs team found that over 90.5% of open-source dependency vulnerabilities in Java, Python, Rust, Go, C#, .NET, Kotlin, and Scala are not actually exploitable at the function level — meaning, they do not have at least a call path from the application to the vulnerable function in that library.
SEE: Open source code for commercial software applications is ubiquitous, but so is the risk
Darren Meyer, staff research engineer at Endor Labs, said that organisations are “drowning in vulnerability alerts, many of which don’t represent relevant risk.”
“Researching the alerts is expensive for security teams (and software teams), and trying to fix everything is even more expensive,” he added.
Updating dependencies to non-vulnerable versions has a notable impact on the number of relevant vulnerabilities. For example, updating the top 20 Python components removes more than 75% of all vulnerability findings, including 60% for Java and 44% for npm.
Furthermore, filtering out dependency vulnerabilities that are not reachable — cannot be accessed and exploited — and that have an EPSS score of less than 1% can significantly reduce the number that security professionals need to monitor. Combining these with filters for vulnerabilities that don’t have an available fix and are not present in the test code leaves only 4% of Java and JavaScript vulnerabilities and less than 1% of Python vulnerabilities, slashing remediation costs.
The report’s authors wrote: “When combined with function-level reachability analysis data and other context-based scoping strategies, EPSS prioritization is often so effective that additional, higher-effort prioritization strategies (such as conducting Environmental and Temporal CVSS scoring exercises to determine severity in your environment) are often unneeded.
“This saves vulnerability analysis costs for your organization.”
