Nearly all (95%) version upgrades of open source software contain at least one breaking change that causes other components to fail, with patches having a 75% chance of causing a break, according to Endor Labs.
The security vendor revealed the findings in its third annual Dependency Management Report, which is based on Endor Labs vulnerability and customer data, information in the Open Source Vulnerabilities (OSV) database and Java ARchives (JARs) related to the top 15 open source dependencies.
The challenge of breaking changes is compounded by the fact that a quarter (24%) of vulnerable components require a major version update, according to the findings.
However, there are ways to mitigate these challenges.
“Whole program call graphs and the analysis of type hierarchies can clarify whether breaking changes of library updates actually matter in a specific application context,” the report noted.
Documenting Delays
Endor Labs also identified another major challenge for end-users of buggy open source software – delays in the publication of vital information on vulnerabilities.
“The first potential delay happens between the fix of a vulnerability in a project’s source code repository and the publication of a corresponding security release in a public repository such as Maven or npm, which facilitates the consumption of the fix by downstream users,” the report explained.
“This delay matters, because attackers may be able to spot the fix commits, hence, know about technicalities of the vulnerability and how to exploit it, while users have no easy way to patch their systems.”
Endor Labs added that 69% of security advisories are published after the corresponding security release, with a median delay of 25 days.
Whether those advisories come in the form of blog posts, CVEs or GitHub Security Advisories (GHSA), they contain vital information about the presence of vulnerabilities and the availability of security releases.
A delay in their publication therefore provides threat actors with another window of opportunity to exploit vulnerable systems, Endor Labs warned.
The report added that further delays can come if the software composition analysis (SCA) tools vital to the remediation process have tardy or imprecise information sources.
The National Vulnerability Database (NVD) is suffering well-documented delays in processing CVEs, for example.
The report noted that, across six studied open source ecosystems, nearly half (47%) of advisories in public vulnerability databases didn’t contain any code-level vulnerability information at all, 51% contained one or more references to fix commits and just 2% contain information about affected functions.
Reducing Noise
Without this kind of information, it’s effectively impossible to establish whether known-vulnerable functions can be executed in the context of a downstream application, it warned.
All of which makes prioritizing vulnerabilities for patching increasingly challenging, although it’s vital to reduce costs and improve resilience.
Endor labs claimed less than 9.5% of vulnerabilities are exploitable at the function level. It argued that a code-scanning technique known as “function-level reachability analysis,” which determines if a vulnerability can be exploited in an application, is the most important prioritization technique.
Second is the data-driven Exploit Prediction Scoring System (EPSS), it said, noting that programs that combine this and reachability analysis see “noise reduction” of up to 98%.
Read more on open source vulnerabilities: Most Commercial Code Contains High-Risk Open Source Bugs