While open-source software is an integral part of software development today, security continues to be an issue. A recently released report revealed a 71 percent increase in open-source security related breaches over the last five years. In addition, 25 percent of organizations reported a confirmed or suspected open-source software related breach. 

RELATED CONTENT: Open source at 20: The ubiquity of shared code

The fifth annual Sonatype State of the Software Supply Chain Report is based on patterns and cybersecurity hygiene practices of about 36,000 open-source projects and 3.7 million open-source component releases. 

According to Derek Weeks, VP at Sonatype, one of the reasons security is still such a problem with open-source projects is because developers treat open-source software as if they were created equal. “This year’s report definitely shows that we can’t do that, we can’t treat all open source projects as equal. It has long been believed that in the realm of open source development, ‘with more eyeballs, all bugs are shallow.’ In other words, the more popular open source components were, the fewer bugs or vulnerabilities they might have. That’s just not true – and it leads to a false sense of security,” he said.

When looking at behavior patterns and best practices the report looked at differences between how projects update dependencies and fix vulnerabilities; how components are used; and what advice can be offered from how those components are consumed. The report found only 5 percent of projects remediate security vulnerabilities within 21 days; “exemplary” projects such as Elasticsearch, Mulesoft, and SonarSource are 3.4 faster at remediating known vulnerabilities and secure development practices are 9.3 times more likely to remove troublesome dependencies. 

“Our research into popularity of components in this year’s report distinctly shows that developers should not select components based on popularity alone. While many of the best quality open source components are popular, not all popular open source projects release improvements or remediate vulnerabilities frequently.  Some of the most popular components may take 200 days or more, on average, to release new updates or remediate known security vulnerabilities,” said Weeks. 

In order to improve and ensure open-source security, Weeks suggests creating a Software Bill of Materials (SBOM) that will help enterprise developers better understand their software supply chains. The SBOM will give developers observability and insight into the open source software components their teams are using, known security vulnerabilities, license risks and architectural risks. “You cannot manage what you cannot see,” he said. 

In addition to a SBOM, development teams should use a repository manager, regularly update dependencies, use the most recent versions of components, and automate.