Key Takeaways for Developers From SOSS v11: Open Source Edition
Our latest State of Software Security: Open Source Edition report just dropped, and developers will want to take note of the findings. After studying 13 million scans of over 86,000 repositories, the report sheds light on the state of security around open source libraries – and what you can do to improve it.
The key takeaway? Open source libraries are a part of pretty much all software today, enabling developers to work faster and smarter, but they’re not static. Library popularity and usage changes and evolves with trends in software development, and if developers don’t keep up with these movements, the organizations they’re building innovative applications for are at greater risk of damaging data leaks and cyberattacks.
Let’s dive into the data.
Just over half of developers have a process for selecting third-party libraries
As part of this year’s report, we ran a survey that asked customers some critical questions about how they interact with third-party libraries. We weren’t surprised to see that the customers who put effort into purchasing scanning software have a formal process in place for library evaluation; over half, 52 percent, said yes.
The bad news is that a pretty big fraction of respondents (29 percent) are unsure of whether or not they have a formal process in place, while 19 percent said no. While a number of factors might contribute to this problem from company to company, a likely cause is the lack of a developed, shared, and followed policy – something that can be tricky for larger, dispersed teams to manage without all of the DevSecOps puzzle pieces in place.
Developers can act fast if they’re given the right information, early
We know that most developers don’t go out of their way to ignore security, so where’s the disconnect between how quickly flawed libraries are fixed? The data shows us that when developers have the right information in hand sooner rather than later – for example, contextual information about how a vulnerable library relates to an app – they’re able to fix those flawed libraries quickly. In fact, we found that 17 percent of flawed libraries are fixed within an hour of the security scan, while 25 percent are fixed within seven days.
There was little change in popularity for Java, but big changes in Swift
You’ll see above in figure 1 that while some languages like Java didn’t change much year over year, others like Swift had quite the shakeup. Swift’s top two libraries from 2019, Crashlytics and Fabric, didn’t even make it into the top 20 last year. But we know why that happened – Google is the parent company behind Firebase, which acquired Crashlytics and Fabric, giving those two libraries both a boost in popularity.
Jackson-databind is popular and vulnerable, while Twisted saw a drop
When we looked at the top vulnerable libraries from 2019 and 2020, something jumped out at us for Java. The popular jackson-databind library was both popular and vulnerable, holding steady year over year.
However, the Twisted library in Python tells a different story. Note how it dropped dramatically in popularity from 2019 to 2020 in figure 2. We can likely attribute this to the expanding capabilities of functionality within Python as well as the fact that Twisted has had seven CVEs associated with it over the course of its lifetime.
The majority of library vulnerabilities are fixable with minor updates
It might surprise you that most vulnerabilities in third-party libraries are easy to fix with a minor update. When we dug into the data we found that a whopping 92 percent of flaws can be fixed with a simple update, while 69 percent of updates are a minor version change or less. This means that, having the right contextual information about the flawed libraries and the apps they impact in hand sooner rather than later, developers should be able to update libraries quickly and efficiently. But…
…Most libraries are never updated at all
Here’s where developers seem to run into a wall when it comes to fixing flawed third-party libraries. Figure 7 shows us that 79 percent of the time developers never update third-party libraries once they’re in a codebase, which leaves the libraries wide open to an attack if they carry dangerous vulnerabilities.
Equally as concerning, we see in figure 8 that 73 percent of libraries are added and then never updated over time. Even after we restricted our data to repositories with relatively long lifespans and a lot of scans, we still came to that daunting 73 percent. While this is likely because developers tend to stick with a library and then never check for updates, it still highlights a glaring gap in security that you should take note of.
Almost 17 percent of vulnerable libraries are fixed in one hour
So, what about libraries with vulnerabilities that are indeed fixed? As previously mentioned, we found that once a developer is alerted to a vulnerability after a scan, nearly 17 percent of vulnerable libraries are fixed within one hour of that scan. Even more promising, 25 percent are fixed within a week.
When everything seems like a priority, having that valuable scan information in hand sooner means you’re able to make smarter decisions about flaws and prioritize the library updates that are most important.
A lack of information and resources also greatly impacts fix time
It’s not all about the flaws and how tricky they are to prioritize. If you’re left without the right information, as a developer, it can feel like your hands are tied. In our survey, we asked how certain factors impact a respondent’s ability to address flaws in third-party code and were pleasantly surprised to find that most feel they rarely lack the skills needed. Instead, it often comes down to missing contextual information about how vulnerable libraries relate to their applications and the resources you need to fix them: when developers like you don’t have the critical data and tools, it takes 13.7 times longer to fix half of the vulnerabilities.
We weren’t surprised to see that developers are running into such roadblocks, but the scale is troublesome. Figure 19 makes it clear: when developers lack the proper resources to prioritize and fix these flaws, time drags on and so can the risk these libraries carry.
It’s important to pay attention to update chains in open source libraries
As an experienced developer, you know that updating libraries to the latest versions isn’t always everything you need to do to keep your third-party libraries secure. There are chains of events that can occur, such as new vulnerabilities popping up after an update, or extra updates that are critical to consider.
As shown in the graphic above, there are situations that can cause an upgrade chain to actually downgrade a library to a version you’ve already updated to. Or, there may not even be an update at all as is the case with number four.
But one surprising (and positive) finding was that longer chains are less likely to dead-end on you. Our research showed us that chains with more than two steps will end in a clean fix, which means that carefully and thoughtfully picking through each dependency will result in a more secure application.
Read the full report for even more data and guidance
While library popularity is dynamic and shifts year to year, it’s obvious many developers simply find what they need and stick with it. In the fast-paced world of software development that’s with good reason, but it’s a habit that developers should try to break.
Although your favorite and most-used library might have seemed fine last year, it could be totally different and riddled with vulnerabilities today. Staying on top of these trends and working with security counterparts to get the information you need can help you fix these third-party library flaws faster so that you’re producing more secure applications down the road.
To get all the data and details, download the full report here.
Related Posts
