Vulnerabilities Declining in Open Source, but Slow Patching Still a Problem

Driven by growth in the JavaScript, Java, and Python ecosystems, the number of open source software packages more than doubled in 2019, but the number of vulnerabilities fell by 20%, suggesting that developers are weeding out simple vulnerabilities, a new report shows. 

While the decrease is undoubtedly good news, most development teams still fail to adequately inventory their software dependencies — a point of concern because indirect dependencies, meaning libraries used by imported code — can account for the majority of vulnerabilities. More than 70% of vulnerabilities in Node.js, Ruby, and Java, for example, occur in indirect dependencies, not in the original imported open source library, according to the "State of Open Source Security 2020" report, published today by software security firm Snyk.

In one case, a Java application comprised 80 lines of code with seven dependencies, but when all of the code was imported, the code base expanded to 59 sub-dependencies and more than 700,000 lines of code, says Alyssa Miller, application security advocate at Snyk.

"You don't even necessarily know that all those dependencies are there, but they are undermining your security," she says.

As open source software components have become arguably the most important part of software development, managing the vulnerabilities posed by those components has become a major task for companies. Almost every software program uses open source software, with the average application using 445 open source components, according to a recent study by Synopsys.

Acknowledging this, the Internet Security Forum (ISF) released its "Deploying Open Source Software: Challenges and Rewards" report today, highlighting best practices for companies using open source software in development.

"Many organizations are adopting agile and DevOps methodologies, which is driving an increased uptake of OSS [open source software] and, in turn, the creation of new mixed-source applications," stated Paul Holland, principal research analyst at the ISF. "The growing prevalence of OSS needs to be balanced by a concerted effort to manage its use appropriately and effectively."

Different programming languages and their associate application frameworks have different considerations when it comes to securing the software. PHP applications tend to use a relatively low number of open source libraries — 34, on average — but have a higher number of vulnerabilities, according to data analyzed by application security firm Veracode.

In the latest report by Snyk, the company found that the popularity of JavaScript-based web-application frameworks continued to grow as more developers relied on JavaScript and Node.js. The survey component of the study found 73% of developers used JavaScript-based platforms. The popularity drove Node.js applications managed by the NPM platform to more than double to 13 million packages. 

The wide reliance of JavaScript programs on imported code — the average applications has 377 dependencies, according to Veracode — means more indirect dependencies. In its analysis, Snyk found 86% of JavaScript vulnerabilities occurred in indirect dependencies. 

"There is a lot of factors that can come into play here. NPM has a pretty significant drop in the number of vulnerabilities, but they also have a solid backlog of vulnerabilities that they are investigating, which is causing delayed fixes," Miller says.

Two classes of vulnerability demonstrate the unique nature of open source software and dependencies, where vulnerability types tend to result in a lot of reported issues or are widespread, but generally not both.

A significant number of open source software project suffered attacks in the form of malicious changes to the project, according to the report. A malicious change typically happens when a rogue developer — often an agent of a nation-state or cybercriminal gang — joins a project to introduce a vulnerability. Yet, while critical in severity, such malicious changes did not impact very many projects.  

On the other hand, with a class of JavaScript vulnerabilities known as prototype pollution, thousands of packages can be affected by a single vulnerability. Two prototype pollution vulnerabilities affected the security of more than 25% of scanned projects, Snyk said in its report. Prototype pollution can allow code in a malicious object to overwrite the prototype class behavior, polluting all other classes that rely on that behavior. The vulnerability class is not well-known, but a single issue can often have widespread impact.

"They are difficult to find," Miller says. "I think that is the reason we see a low number of them. It is not a well-understood vulnerability at this point."

Finally, software container images — Docker being the most popular example — often pool together vulnerable software and should be investigated, Snyk said. The most recent version of the Node server, at the time of the report, had more than 642 known vulnerabilities in the software contained in the image, including 17 high vulnerabilities, the company said.

"Companies need to try to minimize the software footprint of these images," Miller says. "If you pull Node-Slim [the stripped down version of the Node server], then you lose 95% of the vulnerabilities. So if you don't need the full-blown image, choose the minimal version."

Related Content:

Learn from industry experts in a setting that is conducive to interaction and conversation about how to prepare for that "really bad day" in cybersecurity. Click for more information and to register for this On-Demand event.