Introduction
Software composition analysis (SCA) tools concern themselves with the identification of open source libraries and tools that have been built into or support an application, an identification that helps evaluate unpatched code, licensing issues and potential security vulnerabilities. The continued growth in the percentage of open source in newly created applications, and one big data breach, have led to a significant increase in the in-use percentage of SCA, according to 451’s Voice of the Enterprise, Information Security studies.
The 451 Take
Applications remain a target for security attacks by bad actors, especially as infrastructure abstracts and becomes more hardened. Open source vulnerabilities are especially attractive in attacking scenarios because they represent a type of vulnerability that can be used across applications, a known element of an otherwise custom application. At the same time, an entire generation of developers have arrived for whom using open source code or tools is as natural as using any library. In the midst of competitive time frames, they are going to concentrate on the custom code that stitches an application together, not redeveloping functions for which code is already accessible. Years ago, it was relevant to ask whether an application had open source code in it; now the relevant question is the composition of open source in an application, with some sources noting the number is above 50% for newly written apps. Given this rising composition – and one huge data breach that demonstrated the costs of not managing open source risk – it’s of little surprise to see SCA’s growth in the last year.
Software Composition Analysis Growth
The figure below shows the response over a two-year period to the Voice of the Enterprise, Information Security study when respondents were asked whether they have a SCA solution in place, or if not, what their implementation plans were, if any:
The numbers tell a fairly straightforward story: 13% of all enterprises participating in the study had SCA in place in 2018, with 11% having fairly solid plans to add SCA in the near future. In 2019, that rose to 21% of surveyed enterprises having SCA in use, and 12% reported being in a pilot phase. Among those with SCA in place in 2019, half planned to increase spending in the next year. Larger companies are more likely to have SCA implemented (just as they are more likely to have in-house application development): those organizations with more than 1,000 employees have SCA in use 32% of the time. Approach to technology adoption also makes a difference: 24% of those that consider themselves more on the early adopter side of technology adoption already have SCA. Finally, while 38% of respondents have any type of application security solution in place, that shoots up to 47% in those organizations that do in-house application development, and 30% of those organizations have implemented SCA.
There are likely two primary drivers, the first identified above is simply the rise of open source composition in modern applications and the need to then manage it. Beyond security, that extends to license management, patch or version management, and simply ensuring that hundreds of different versions of the same open source library aren’t being implemented in an organization. A second driver, though, follows that Santayana aphorism: “Those who cannot remember the past are condemned to repeat it.”
A Big Breach
The Heartbleed bug in OpenSSL, discovered in 2014, was a highly publicized defect in a widely used open source library that caused a number of organizations to consider the exposure of their software supply chain to open source risk, and drove a level of adoption of SCA. The Equifax breach in 2017 triggered a similar response whose lingering effects are still playing out in the relatively tectonic adoption curve of enterprise security technologies.
The Equifax breach resulted in some $1.4bn in costs, affected 140 million people, and resulted in executive resignations. The costs were outsized, and much of the burden fell on third parties that had no insight or control over the firm’s security posture or incident response. Equifax came into a good deal of criticism based on that response, with months going by between the announcement of the Struts vulnerability that served as the attackers' entry point being disclosed, the breach occurring, its discovery, and finally its disclosure.
Much of the criticism centers on Equifax’s response being a case study in how not to handle a data breach. But the entry point of an open source vulnerability, one that had a fix available, is relevant. Amid the tut-tuts of the security industry, 33% of IT professionals revealed in a 451 Voice of the Enterprise: Digital Pulse study (see Figure 2 above) that they are pretty sure their organization could be compromised the same way, and 70% acknowledged the possibility. How does that drive forward open source risk assessment? Sometimes it’s about learning from the mistakes of others:
"[With breaches] it's more of an evaluating our overall posture and trying to adjust for any new threats or what you see in Equifax or the other large breaches. What do we have to do to protect against that, or to identify, to limit the damage on that? So it is definitely an overall theme, looking at those big breaches, to adjust our security program and work plans.”
– IT/Engineering Managers and Staff, 2,000-4,999 employees, $1-2.49bn, Telecommunications
Much of the criticism centers on Equifax’s response being a case study in how not to handle a data breach. But the entry point of an open source vulnerability, one that had a fix available, is relevant. Amid the tut-tuts of the security industry, 33% of IT professionals revealed in a 451 Voice of the Enterprise: Digital Pulse study (see Figure 2 above) that they are pretty sure their organization could be compromised the same way, and 70% acknowledged the possibility. How does that drive forward open source risk assessment? Sometimes it’s about learning from the mistakes of others:
"[With breaches] it's more of an evaluating our overall posture and trying to adjust for any new threats or what you see in Equifax or the other large breaches. What do we have to do to protect against that, or to identify, to limit the damage on that? So it is definitely an overall theme, looking at those big breaches, to adjust our security program and work plans.”
– IT/Engineering Managers and Staff, 2,000-4,999 employees, $1-2.49bn, Telecommunications
What's Next?
SCA offerings differentiate themselves in a number of ways: how far beyond the National Vulnerability Database (NVD) they’re able to go to, the ease of patching (sometimes whether an official patch is available or not), and the actual usage (not just presence) of open source components. But a definite schism is beginning to open between offerings that were early to market and some of the features, or integrations with larger application security testing (AST) toolsets that have emerged since:
The industry has definitely caught up with [my SCA vendor]. I would say probably 60% [likely for us to switch away]…. It's like I'm doing my compliance, I'm doing my dev portion of it. And then we got to make them take the same code that they just scanned and put it into the open source scan …..so you got to do two scans. It would be much easier for the developer to ship at one time and get two [reports].
–Senior Management, 10,000-49,999, $5-9.99bn, Telecommunications
We made the point fairly emphatically last year that the pace of modern application development, and the organic standardization of DevOps toolchains, was both forcing and enabling AST earlier in the system development lifecycle. The Voice of the Enterprise Information Security data showed both a shift left for AST to the construction phase of application development and greater usage of AST tools by, in particular, developers. Adapting to those conditions will be the battleground for SCA going forward. As the quote above points out, simple things like running a single scan for both static analysis and SCA results is but one example of a desire for greater efficiency. Vendors have integrated SCA checks on code commit, with an IDE or even as browser plug-ins as developers search for a relevant piece of open source software. Supporting a low-friction approach to SCA that enables developers to use open source while preventing sprawl and reducing security risk at the organizational level will continue to be a key differentiator for SCA vendors going forward.
After-the-fact scans will still be appropriate for certain use cases – evaluating an application in a merger or acquisition or conducting a point-in-time evaluation of an organization’s open source risk, for example. Increasingly, however, adequate coverage of open source risk will only be achieved through continuous processes built into developers’ day-to-day operations, with reporting that allows security teams to gain a precise view of the organization’s open source risk posture over time.
The industry has definitely caught up with [my SCA vendor]. I would say probably 60% [likely for us to switch away]…. It's like I'm doing my compliance, I'm doing my dev portion of it. And then we got to make them take the same code that they just scanned and put it into the open source scan …..so you got to do two scans. It would be much easier for the developer to ship at one time and get two [reports].
–Senior Management, 10,000-49,999, $5-9.99bn, Telecommunications
We made the point fairly emphatically last year that the pace of modern application development, and the organic standardization of DevOps toolchains, was both forcing and enabling AST earlier in the system development lifecycle. The Voice of the Enterprise Information Security data showed both a shift left for AST to the construction phase of application development and greater usage of AST tools by, in particular, developers. Adapting to those conditions will be the battleground for SCA going forward. As the quote above points out, simple things like running a single scan for both static analysis and SCA results is but one example of a desire for greater efficiency. Vendors have integrated SCA checks on code commit, with an IDE or even as browser plug-ins as developers search for a relevant piece of open source software. Supporting a low-friction approach to SCA that enables developers to use open source while preventing sprawl and reducing security risk at the organizational level will continue to be a key differentiator for SCA vendors going forward.
After-the-fact scans will still be appropriate for certain use cases – evaluating an application in a merger or acquisition or conducting a point-in-time evaluation of an organization’s open source risk, for example. Increasingly, however, adequate coverage of open source risk will only be achieved through continuous processes built into developers’ day-to-day operations, with reporting that allows security teams to gain a precise view of the organization’s open source risk posture over time.
Daniel Kennedy
Research Director, Voice of the Enterprise: Information Security
Daniel Kennedy is responsible for managing all phases of the research process. He is an experienced information security professional who has written for both Forbes online and Ziff Davis, has provided commentary to numerous news outlets including The New York Times and The Wall Street Journal, and his personal blog Praetorian Prefect was recognized as one of the top five technical blogs in information security by the RSA 2010 Conference.
Jeremy Korn
Research Associate
Jeremy Korn is a Research Associate at 451 Research. He graduated from Brown University with a BA in Biology and East Asian Studies and received
Aaron Sherrill
Senior Analyst
Aaron Sherrill is a Senior Analyst for 451 Research covering emerging trends, innovation