What Is “Risk” in the Age of Open Source?

The Black Duck Audit Services team at Synopsys conducts open source audits on thousands of codebases for its customers every year. Those audits are driven primarily by merger and acquisition transactions and eventually become the primary source of anonymized data for our annual Open Source Security and Risk Analysis (OSSRA) report. The just-released 2019 OSSRA report examines findings from the data of over 1,200 commercial codebases for organizations wanting to assess their open source license compliance and security risks.

The audits found open source in over 96% of codebases scanned in 2018, with more than 99% of the codebases with over 1,000 files containing open source components. Open source represented 60% of the code analyzed in 2018, up from 57% in 2017. These numbers reflect that the audited codebases were generally from companies whose business is building software. The value of these companies is often in their proprietary code, and the ratio of open source to proprietary code in their codebases tends to be lower.

By contrast, analysts such as Forrester and Gartner note that over 90% of IT organizations use open source software in mission-critical workloads and that open source composes up to 90% of new codebases. According to the 2019 Red Hat's “State of Enterprise Open Source” report, over 69% of the enterprises surveyed felt that their use of open source was at minimum “very important.”

Whatever numbers you look at, it’s clear that open source components and libraries form the backbone of nearly every application in every industry. Most organizations have thousands of different pieces of software ranging from mobile apps to cloud-based systems to legacy systems running on-premises. That software is typically a mix of commercial off-the-shelf packages, open source software, and custom-built codebases. Vulnerabilities affect all.

Yet, few companies are adequately tracking the open source components they use in their code and haven’t implemented the policies, processes, and tools needed to keep up with the choices made by their developers to use open source. As a consequence, all the benefits that come with open source can also bring a variety of risks.

The Risk Issue Is Unpatched Software, Not Open Source Use

As the Red Hat report notes, security is cited as a major barrier blocking some enterprises from permitting open source use. Interestingly, the same report cites security as one of the top benefits IT decision makers see in their use of open source. This seeming contradiction reflects the concern that unmanaged open source code can introduce vulnerabilities in both open source and proprietary solutions, versus an awareness that proper management of open source—including using trusted sources and automated tools to uncover and remediate security problems—can significantly reduce the potential of open source risk.

All software, be it proprietary or open source, has weaknesses that might become vulnerabilities, which organizations need to identify and patch. The open source community does an exemplary job of issuing patches, often at a much faster pace than their proprietary counterparts.

But whether for proprietary or open source software, an alarming number of companies aren’t applying patches in a timely fashion, opening themselves to risk. The reasons for not patching are varied: Some organizations are overwhelmed by the endless stream of available patches and are unable to prioritize what needs to be patched, some lack the trained resources to apply patches, and some need to balance risk versus the financial costs of addressing that risk.

Unpatched software vulnerabilities are one of the biggest cyberthreats organizations face, and unpatched open source components in software add to security risk. The 2019 OSSRA report notes that 60% of the codebases audited in 2018 contained at least open source vulnerability. Synopsys added 7,393 open source vulnerabilities to its Black Duck KnowledgeBase in 2018. Well over 50,000 open source vulnerabilities have been reported in the past two decades.

What’s the Risk?

Certain characteristics of open source make vulnerabilities in popular components attractive to attackers. Unlike commercial software, whose publishers can automatically push fixes, patches, and updates to users, open source has a pull support model. In other words, you are responsible for keeping track of both vulnerabilities and fixes for the open source you use.

The ubiquity of open source provides attackers with a target-rich environment as vulnerabilities are disclosed through sources such as the National Vulnerability Database (NVD), mailing lists, GitHub issues, and project homepages. And as noted earlier, many organizations don’t keep accurate, comprehensive, and up-to-date inventories of the open source components used in their applications. For example, a staff report by the U.S. Senate Permanent Subcommittee on Investigations noted that Equifax’s lack of a complete software inventory was a contributing factor to its massive 2017 data breach.

Proper Management of Open Source Software Isn’t Just About Security

There are thousands of open source licenses, and a failure to comply with those licenses can put businesses at significant risk of litigation and compromise of intellectual property. Whether using one of the popular licenses sanctioned by the Open Source Initiative or some variant, organizations can manage and comply with license requirements only after identifying the open source components governed by those licenses. Thirty-two percent of the audited codebases detailed in the 2019 OSSRA report contained custom licenses that had the potential to cause conflict or needed legal review. Sixty-eight percent contained components with license conflicts.

In addition to security and license risk, operational risk is a less acute but still important consequence of open source use. Many open source components in use today are abandoned. In other words, they don’t have a community of developers contributing to, patching, or improving them. If a component is inactive and no one is maintaining it, that means no one is addressing its potential vulnerabilities. The 2019 OSSRA report notes that 85% of the codebases audited contained components that were more than four years out-of-date or had no development activity in the last two years.

Use of Open Source Isn’t Risky, but Unmanaged Use of Open Source Is Risky

Open source offers many benefits to organizations that use it—but only when open source is being properly managed to identify any security and legal compliance issues. To defend against open source security and compliance risks, organizations should:

Create and Enforce Open Source Risk Policies and Processes

Only a handful of open source vulnerabilities—such as those infamously affecting Apache Struts or OpenSSL—are ever likely to be widely exploited. With that in mind, organizations should focus their open source vulnerability management and mitigation efforts on CVSS (Common Vulnerability Scoring System) scores and the availability of exploits, not only on “day zero” of a vulnerability disclosure but over the life cycle of the open source component.

Developers must be educated about the need for managed use of open source. Put in place an automated process that tracks the open source components in a codebase and their known security vulnerabilities, as well as operational risks such as versioning and duplications, and prioritizes issues based on their severity.

Perform a Full Inventory of Their Open Source Software

It’s essential to have a full, accurate, and timely inventory of the open source used in your codebases. The inventory should cover both source code and information on how open source is used in any commercial software or binary deployed in production or used as a library in an application.

Map Open Source to Known Vulnerabilities

Public sources, such as the National Vulnerability Database, are a good first stop for information on publicly disclosed vulnerabilities in open source software. But don’t rely solely on the NVD for vulnerability information. Instead, look to a secondary source that provides earlier notification of vulnerabilities affecting your codebase and, ideally, delivers security insight, technical details, and upgrade and patch guidance.

Monitor for New Security Threats

The job of tracking vulnerabilities doesn’t end when applications leave development. Organizations need to continuously monitor for new threats for as long as their applications remain in service.

Identify Licensing Risks

Failure to comply with open source licenses can put organizations at significant risk of litigation and compromise of IP. Educate developers on open source licenses and their obligations. Involve your legal advisors in the education process and, of course, in reviewing licenses and compliance with legal obligations.

Make Sure Open Source Is Part of M&A Due Diligence

 If you’re engaged in an acquisition, understand that the target company is using open source—and possibly not managing it well. Don’t hesitate to ask questions about their open source use and management. If the software assets are a significant part of the valuation of the company, have a third party audit the code for open source.

The bottom line is that it’s impossible to patch software you don’t know you have in use. If you can’t say with confidence that the open source components you use in your internal and external applications are up-to-date with all crucial patches applied, it’s time to reassess your open source management policies and processes.