Open source code is ubiquitous in modern software. While its convenience supports the demand for faster application development, it is also at risk of being insecure. In fact, more than 70% of open source libraries contain security flaws. The question is whether developers are aware of these flaws and, if so, are they doing anything about them?
Veracode’s State of Software Security: Open Source Edition v11 found 79% of the time, developers never update third-party libraries after including them in a codebase. What’s preventing developers from fixing flawed libraries? Complexity, resources, or staff?
While those are all factors, Veracode’s research found that the lack of accurate information is the biggest issue. According to the data, when developers have the correct information, they can fix flaws far quicker.
The majority of library vulnerabilities are fixable with minor updates
Interestingly, our research found that most vulnerabilities in third-party libraries are easy to fix with a minor update. In fact, the data revealed that 92% of flaws could be fixed with a library update, and 69 percent of updates are a minor version change or less.
It’s not all about the flaws and how tricky they are to prioritize. The research also found that multiple factors impact a developer’s ability to address flaws in third-party code. The good news is that most developers feel they do have the skills needed. However, it often comes down to missing contextual information about how vulnerable libraries relate to their applications and the resources needed to fix them. When developers don’t have the critical data and tools needed, it takes 13.7 times longer to reach the milestone of fixing half of their known vulnerabilities.
Context is key to open source flaw remediation
Veracode’s research found that developers who report they often lack information take more than seven months to fix 50% of flaws, while those who have the information they need fix 50%of flaws in just three weeks. So, what information do developers need to make timely decisions about flaw remediation? And how do they get it?
When considering vulnerabilities and how and when to fix them, developers need specific information, such as:
● Severity: Developers fix low- and medium-severity issues more slowly and high-severity issues much more quickly, exactly as you’d expect.
● Dependency type: Different dependency types affect the speed of updating to non-vulnerable versions. Direct dependencies are the easiest (fastest) to fix. Things get trickier with transitive dependencies.
● Vulnerability type: The particular type of vulnerability can influence complexity.
Developers can glean this information and more from several sources, including tools, internal intelligence and their security knowledge.
● Application scanning – The report 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 and another 25% within a week. This underscores the real challenge in fixing vulnerabilities. It’s not that developers cannot or don’t want to fix them; it’s that they don’t always know about them or understand the severity or impact that vulnerabilities might have. By scanning regularly and frequently for flaws in code, developers are armed with the information to help them identify vulnerabilities early, determine their severity, and take the necessary steps to fix them.
Everything seems like a priority in modern application development, and fixing flaws isn’t always top of the list. Valuable scan information enables developers to make smarter decisions about flaws and prioritize the most important library updates.
● Security intelligence – Another critical piece of this puzzle is a collaboration with security counterparts. While mature AppSec programs integrate security and dev teams, the constant pressure to produce more code faster doesn’t leave much room for collaboration. However, without insights from the security team, developers are often stymied by their lack of security knowledge about a specific vulnerability and its potential danger.
● Developer education – In addition to close collaboration between developers and their security counterparts, organizations would do well to provide security training for developers. With more information and understanding of the security threats to their applications, developers are empowered to address harmful vulnerabilities in their code before they become a problem.
Open-source libraries are constantly evolving. What’s most popular and seemingly secure today might be totally different and riddled with vulnerabilities tomorrow. By staying on top of these trends, scanning frequently and working with security counterparts to get the information needed, developers can fix more third-party library flaws faster to develop more secure applications in the future.
This article originally ran in Today’s Cybersecurity Leader, a monthly cybersecurity-focused eNewsletter for security end users, brought to you by Security Magazine. Subscribe here.
