Key Takeaways From State of Software Security v11: Open Source Edition

by [email protected] (hgoslin) on June 25, 2021

We recently published a special open source edition of our annual State of Software Security (SOSS) report. The State of Software Security v11: Open Source Edition analyzed the data collected from 13 million scans of more than 86,000 repositories, containing more than 301,000 unique libraries. We also added some color and context to the data this year by surveying our customer base and adding the data from 1,744 responses to the report.
In last year’s open source report, we looked at a snapshot of library usage in applications. This year, we looked beyond the point-in-time snapshot to examine the dynamics of library development and how developers react to library changes, including the discovery of flaws.
Here are some of the key takeaways for security professionals:
The most popular libraries from last year are not the most popular libraries this year. And the most secure libraries from last year are not the most secure libraries this year.
Some languages saw little to no change in library popularity from 2019 to 2020, like Java. But other languages underwent significant changes in their library landscapes. For example, Swift’s top two libraries from 2019, Crashlytics and Fabric, did not even break the top 20 in 2020. This is due to the fact that Google (the parent company behind Firebase) acquired both companies and integrated the functionality into Firebase, leading to the meteoric rise in two Firebase libraries.

The most secure libraries have also changed. The Twisted library in Python was very secure last year, but this year it’s far from secure. This is likely attributable to the expanding capabilities of the built-in functionality in Python, with the built-in library asyncio receiving significant updates in 2016 and late 2018, and perhaps more importantly has only seen one CVE associated with it (CVE-2021-21330), in contrast to Twisted’s seven.

Security takeaway: What’s popular and what’s secure in your library landscape can change dramatically within the span of a year. Keeping an inventory of what’s in your application is important.
79 percent of developers never update third-party libraries after including them in a codebase.
Once developers pick a library or version, they tend to stick with it. 65 percent of libraries appear in the first scan of the repository and are never updated. An additional 14 percent of libraries are added at some point during development and are never updated to a new version.

The languages that are most likely to be “set and forgotten about” include Ruby, JavaScript, and Java.
Security takeaway: Most third-party libraries aren’t updated once added to a codebase. This is especially alarming considering that, in last year’s open source report, we found that almost one-third of applications have more security findings in third-party libraries than in the native codebase. And even if a library is secure when you add it to your codebase, we saw above that the security of libraries changes frequently. Open source libraries are not a set-it-and-forget-it activity, but rather one that requires maintenance.
When alerted to vulnerabilities, developers act quickly.
But that maintenance is not necessarily overly taxing. We found that once alerted to a vulnerability in a library, developers fix nearly 17 percent of vulnerable libraries within an hour and 25 percent within seven days.

Security takeaway: With the right information and prioritization, security vulnerabilities in open source libraries can be addressed quickly.
Without knowledge of how vulnerabilities relate to their applications, developers struggle to address them.
Vulnerabilities can be addressed quickly, but if developers don’t have the right contextual information, such as how a vulnerability impacts their application, it can take more than seven months to fix 50 percent of flaws. Those that have the information they need fix 50 percent of flaws in just three weeks.
Security takeaway: 92 percent of library flaws can be fixed with an update, and 69 percent of updates are a minor version change or less. But lack of information is a blocker. Make sure that developers have the contextual information they need to address flaws.
To learn more about our open source findings, check out the State of Software Security (SOSS) v11: Open Source Edition report.