Open Source Software Projects Up Their Security Game but Face More Attacks

Open source software projects - the underpinnings of the global software ecosystem - are getting better at more quickly updating vulnerable dependencies, but at the same time they face more cyberattacks and a significant volume of critical vulns.

The security of open source software projects overall has improved over the past decade, with the average time to update vulnerable code dropping to 28 days in 2021 compared with 371 days a decade ago, according to the "2021 State of the Software Supply Chain" report published by software security firm Sonatype last week. Yet attackers are heavily focused on open source projects as a way to attack the developers and companies that use the software components, with the number of attacks documented by the firm increasing by more than 650% over the past year.

Developers will have to continue to improve their management of open source projects because attackers see the supply chain as an opportunity to compromise targets, says Stephen Magill, vice president of product innovation at Sonatype.

"These attacks ... come down to the complexity of modern software-development processes and the automation surrounding the supply chain," he says. "Attackers are starting to take advantage of some of the automation, [and] that results in things happening that people are not always aware of and opportunities to get the wrong [code] pulled in."

Open source projects and components continue to grow as a foundational pillar of software development. The top four ecosystems — Java, JavaScript, .NET, and Python — grew by a combined 20%, churning out 6.3 million new versions and adding almost 724,000 brand new projects, according to Sonatype's report. Overall, the four most popular software ecosystems grew to 37 million downloadable package versions, the company's researchers found.

The growth underscores the critical nature of the open source ecosystem, while at the same time relying on volunteers and uncertain funding. That's a mixed blessing, says Rhys Arkins, director of product management at software security firm WhiteSource.

"Open source should be treated with the seriousness of critical infrastructure but should not be directly regulated, since that would be impractical from an international perspective," he says. "Regulating the use of open source in critical commercial or government projects by taking steps to identify the open source components used and ensuring that those projects are funded and secure is a better idea."

Different Projects, Different Risk Levels
Of course, not all open source projects are the same. The different software ecosystems tend to have different risk profiles, according to Sonatype. Only 0.5% of Python packages had a known security vulnerability, while about 2% of .NET and JavaScript packages had a vulnerability, and 8.4% of Java packages had a security issues. The severity of the vulnerabilities also differed with only 0.5% or less of Python and .NET packages having a critical vulnerability, compared with 1.2% of JavaScript packages and 4.9% of Java packages.

The research also studied how quickly open source maintainers updated their dependencies, as expressed by the mean time to update (MTTU), finding they load the latest components more than 13 times faster than a decade ago.

"That is really encouraging," Sonatype's Magill says. "We found MTTU a few years ago to be a hugely valuable metric and associated with a lot of good outcomes with security, quality, and nonbreaking changes, so it is great to see the community as a whole progressing."

However, most developers just automatically update to the latest version of a dependency, which is not the most optimal way. In fact, to avoid breaking changes, unforeseen issues, and additional vulnerabilities, updating to the third-most recent updated version is the best, on average, says Matt Howard, executive vice president at Sonatype.

"Don't be the first to update to the brand new version of the dependency that just got published," he advises. "You want to let it breathe in the wild for a bit. You want to live near the edge. Living on the edge is suboptimal; living near the edge is better."

Avoiding Malicious Updates
Updating with some caution could also help avoid an increasingly common attack: dependency confusion. In this scheme, an attacker determines the internal name of certain components used by commercial developers and then creates a package with the same name in a public repository. Because the default behavior for some software development tools is to look for the public version first, the attacker's code will be downloaded rather than the internal library.

Companies should lock their dependencies and only download known components, says WhiteSource's Arkins.

"By locking dependency trees and upgrading in a deliberate way, you increase the chance that malicious updates are detected and removed before you might accidentally install them," he says.