Today, we published a special supplement to our annual State of Software Security report that focuses exclusively on the security posture of the open source libraries found in applications. Prominent in almost every application today, open source libraries allow developers to move faster by quickly adding basic functionality. In fact, it would be nearly impossible to innovate with software without these libraries. However, lack of awareness about where and how open source libraries are being used and their risk factors is a problematic practice. This analysis, which examined 351,000 external libraries in 85,000 applications, found that open source libraries are, as expected, ubiquitous in applications, and that they do in fact contain risky code. But it also unearthed some good news about ways to keep track of and alleviate that risk. The report’s highlights include:
Open source libraries are ubiquitous, and risky
Open source libraries make up a significant portion of most applications’ code. Our research found that most JavaScript applications contain hundreds of open source libraries – some have over 1,000 different libraries. In addition, most languages feature the same set of core libraries. JavaScript and PHP in particular have several core libraries that are in just about every application.
Along with their prevalence comes risk. The report found that 70 percent of applications have a security flaw in an open source library on initial scan. Cross-Site Scripting is the most common vulnerability category found in open source libraries – present in 30 percent of libraries – followed by insecure deserialization (23.5 percent) and broken access control (20.3 percent).
Developers may be pulling in more libraries than they realize
This report highlights the amount of interconnected dependencies among open source libraries, and how that can be contributing to layers of hidden risk. In fact, our data reveals that most flawed libraries end up in code indirectly. Forty-seven percent of the flawed libraries in applications are transitive – in other words, they are not pulled in directly by developers, but are being pulled in by the first library (42 percent are pulled in directly, 12 percent are both). This means that developers are introducing much more code, and often flawed code, than they might be anticipating.
Securing these libraries is not necessarily a major undertaking
In the good news department, addressing the security flaws in these libraries is most often not a significant job. Most library-introduced flaws (nearly 75 percent) in applications can be addressed with only a minor version update. Major library upgrades are not usually required!
This data point suggests that this problem is one of discovery and tracking, not huge refactoring of code.
See below for the data highlights, and check out the full report for all the data details, plus our advice on how to use the story told by the numbers to improve your own application security program.