The average software application depends on more than 500 open source libraries and components, up 77% from 298 dependencies in two years, highlighting the difficulty of tracking the vulnerabilities in every software component, according to a new report from software management firm Synopsys. 

In its "Open Source Security and Risk Analysis" (OSSRA) report, the company states it found that 98% of applications used open source and that open source libraries and components made up more than 75% of the code in the average software application. Most applications, 84%, had at least one vulnerability — the typical application had 158 vulnerabilities — and 60% of applications had at least one high-severity issue.

The data underscores that modern software applications have a dependency problem, says Tim Mackey, principal security strategist with Synopsys.

"We need to find a way to get [unpatched vulnerabilities] under control because we are headed in the wrong direction," he says. "This sort of complexity breeds fragility because complexity means that the developer teams don't necessarily have an understanding of the way that code is behaving today, and whenever that happens, then there might be corner cases where they might get bit."

Open source dependencies have become an increasing problem, especially for JavaScript application frameworks, which — because of the language's approach to software architecture — tend to rely on an order of magnitude more components. In an analysis of more than 45,000 active repositories last year, for example, GitHub found that while the average JavaScript application has 10 direct dependencies, those components rely on other libraries, which results in a tree of dependencies that grows to a massive 683 separate codebases. PHP applications typically have 70 dependencies and Ruby has 68, according to the GitHub report.

Synopsys found a similar number of dependencies. While the company did not break out the numbers by language or platform, the average application audited by the firm had 528 dependencies, according to Mackey. 

"To fix an open source vulnerability, you first have to know the vulnerability is there," the company states in the OSSRA report. "Pinpointing vulnerable open source depends on identifying and inventorying all open source you're using."

The data, which comes from the nearly 1,548 applications scanned by Synopsys in 2020, also shows that older vulnerabilities continue to be a problem. Of the top-10 high-risk vulnerabilities found in open source components, only two are from 2020 — one is from 2019, three were disclosed in 2018, and the rest were disclosed more than three years ago.

The problem is that most companies don't have visibility into the long chains of dependencies that many of the applications have, Mackey says.

"When people scan for vulnerabilities, they may only be seeing that top-level dependency version, and not realizing all the other libraries that are getting imported in," he says.

In addition, many of the open source projects in use have not been updated — or patched — in some time. More than 90% of the applications had at least one open source component that had not been updated in the last two years, according the report.

Overall, the company found that 84% of applications have at least one vulnerability, up from 60% two years ago. Applications in the marketing-technology sector were most likely to have a vulnerability, with more than 95% of audited applications having a vulnerability in their open source components. The energy sector, retail and e-commerce sector, healthcare, and Internet of Things manufacturers all had vulnerability likelihoods between 65% and 80%.

The solution to the problem of extended chains of open source dependencies is not simple. Companies could try to track the dependencies, either manually — which will have scale issues — or through an automated service. However, much of the issue will depend on the maintainers of the particular open source projects included in the application code. For that reason, generating and analyzing the software bill of materials as soon as possible has become increasingly important.

"I think it really boils down to, as people are adopting open source components, that they need to make certain that they have the processes in place to keep them up to date," Mackey says. "They have to make the adoption phase more rigorous than just a developer going onto the Internet and downloading the component."