Open source software projects – the foundations of the global software ecosystem – are improving to update vulnerable dependencies faster, but at the same time, they face more cyber attacks and a significant volume of critical vulnerabilities.
The security of open source software projects overall has improved over the past decade, with the average time to update vulnerable code falling to 28 days in 2021 from 371 days a decade ago, according to the “2021 State of the Software Supply Chain” report released by software security company Sonatype last week. Still, attackers are focusing heavily on open source projects as a means of attacking developers and companies that use software components, with the number of attacks documented by the company increasing by more than 650% in the past year. year.
Developers will need to continue improving their management of open source projects as attackers see the supply chain as an opportunity to compromise targets, says Stephen Magill, vice president of product innovation at Sonatype.
“These attacks … boil 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] which results in events that people are not always aware of and opportunities to make mistakes [code] drawn.”
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 company WhiteSource.
“Open source should be treated with the seriousness of a critical infrastructure but should not be directly regulated, as that would be impractical from an international point of view,” he said. “Regulate the use of open source in critical business or government projects by taking steps to identify the open source components in use and making sure those projects are funded and secure is a better idea.
Different projects, different levels of risk
The research also looked at how quickly open source maintainers updated their dependencies, as expressed by Mean Time to Update (MTTU), finding that they load the latest components more than 13 times faster than the average update time (MTTU). ‘ten years ago.
“It’s really encouraging,” says Magill of Sonatype. “We found that MTTU a few years ago was an extremely valuable metric and associated with a lot of good results in terms of safety, quality and uninterrupted change, so it’s great to see the community as a whole move forward. ”
However, most developers just automatically update to the latest version of a dependency, which is not the most optimal way. In fact, to avoid disruptive changes, unforeseen issues and additional vulnerabilities, updating to the most recent updated third version is on average the best, says Matt Howard, Executive Vice President of Sonatype.
“Don’t be the first to update to the brand new version of the dependency that’s just released,” he advises. “You want to let it breathe a bit in nature. You want to live near the edge. Living on the edge is sub-optimal; living near the edge is better.”
Avoid malicious updates
Updating with some caution could also help avoid an increasingly common attack: dependency confusion. In this diagram, an attacker determines the internal name of some components used by commercial developers, and then creates a package with the same name in a public repository. Since the default behavior of some software development tools is to search for the public version first, the attacker’s code will be downloaded rather than the internal library.
Companies should lock down their dependencies and download only known components, says WhiteSource’s Arkins.
“By locking down dependency trees and upgrading deliberately, you increase the chances that malicious updates will be detected and removed before you accidentally install them,” he says.