In 2016 open source is increasingly used for everything from cloud computing to big data to analytics and the mobile space.
For the past 10 years Black Duck Software has conducted an annual survey on open source use in conjunction with North Bridge venture partners. When we first started the survey a decade ago, about five percent of the code in use within the Fortune 500 was open source. Our most recent survey indicates that open source code now typically comprises 50 per cent of the average commercial application.
The year 2008 seems to have been the tipping point when the business community began to realize that open source was no longer a niche area associated with operating systems, but was really much more pervasive in terms of different technologies from web-based to mobile applications, core infrastructure, and development tools.
In 2011 our survey found that cost efficiencies were no longer the top reason why companies were adopting open source. Rather, enterprises were now viewing open source much more strategically in terms of how its use could speed up their time to market, deliver new functionality, and build new applications and services. That year was also when Marc Andreessen made his notable quote about software “eating the world.” By 2013, the word “software” could have been replaced by “open source,” and now in 2016 open source is increasingly used for everything from cloud computing to big data to analytics and the mobile space.
The Need for OS License Compliance
Over the years we’ve seen developers move from traditional code writing to more of an “assembly” mindset, where an application’s components are assembled from open source with proprietary code added as needed. While there are obvious benefits in the use of open source to reduce development costs and to accelerate time to market, there are also challenges around open source code management. One risk factor is open source license compliance. From a business perspective, that’s a valid concern. For example, poor open source code management can cause targets in M&A transactions to suffer. In Black Duck’s experience, 95 percent of the targets we audit have open source code they didn’t know they were using. Half the time that unknown open source was licensed under one of the licenses from the GPL family of licenses.
When unreported open source is discovered during due diligence, it can impact the acquiring company’s ability to go to market quickly with the target’s products, or otherwise derail plans that the acquiring company had for the target company’s software. That can lead to purchase price reduction or even a termination of the deal.
Insight into Open Source for Code Security
But beyond license compliance, a key risk around open source use is in not being aware of security vulnerabilities that lurk there. Of 200 applications recently audited by Black Duck, 67 percent contained known vulnerabilities in open source components, most of which had remained unpatched for more than five years. In fact, 4000+ new open source vulnerabilities are revealed every year.
If you don’t have visibility into the open source you use, and don’t have processes into place to track its ongoing security, you’re providing adversaries with a simple path to attack your application. With the popular use of open source, its security management can’t be ignored without putting your organization at risk of being the victim of the next high-profile and costly security exploit.
It’s important to note that the issue isn’t simply open source security vulnerabilities. The open source community is very quick to respond to discoveries of vulnerabilities and, in most cases, a fix is released the same day as the vulnerability details are published. The real issue is the need to have timely and continual insight into the open source code you’re using in order to keep it up-to-date and secure for both yourself and your customers.
Static application security testing, dynamic application security testing, and run-time application self-protection (otherwise known as SAST, DAST, and RASP) are all essential tools for finding application vulnerabilities in custom code. But alone they may provide an incomplete picture of risk, one of the reasons why cybersecurity leaders such as HPE and IBM both extended their application security testing solutions earlier this year to include open source scanning.
It’s critical to use security testing tools to gain visibility into and identify vulnerabilities in your proprietary code. Of equal importance is the need to understand the open source components in your applications, and have continuous insight into any risk that may be introduced by those components. Like any code, open source components age, new versions are released, and new vulnerabilities are discovered. Without continual visibility into open source as well as proprietary code, organisations risk exposing their applications to attack.