Can Your Patching Strategy Keep Up with the Demands of Open Source?

Unlike commercial software, whose publishers can automatically push fixes, patches, and updates to their customers, open source software offers a pull support model — in other words, you are responsible for keeping track of any patches and updates for the open source software used within your organization. This includes taking care of security vulnerabilities. So, no pressure, right?

The ubiquity of open source usage when coupled with the pull support model provides attackers with a target-rich environment as vulnerabilities are disclosed through a variety of sources such as the National Vulnerability Database (NVD) mailing lists, GitHub issues, and project homepages. Many organizations don't keep accurate, comprehensive, and up-to-date inventories of the open source components used in their applications. For example, a 2019 staff report by the US 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.

The newly released 2019 "Open Source Security and Risk Analysis" (OSSRA) report examines findings from audits of more than 1,200 commercial codebases in 2018. These audits were performed by the Black Duck Audit Services team during the technical due diligence processes associated with activities such as a corporate merger or acquisition. In this context, a codebase represents the source code for an application, library, or service. The results of these audits are then anonymized and used as input data for the OSSRA report.

In the 2019 OSSRA, we found that overall open source usage rose to 60% of the code within a codebase in 2018, up from 57% in 2017. While this indicates 40% of code is proprietary, it's important to note that 96% of codebases contained at least one open source component. Additionally, the average number of open source components per codebase rose 16% to 298.

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 makes up to 90% of new codebases. According to the 2019 Red Hat "State of Enterprise Open Source" report, over 69% of the enterprises surveyed felt that their use of open source was at minimum "very important." With data for the OSSRA report coming from audits of production commercial software versus surveys, we're looking at actual software composition from companies whose business is building software. For those companies, striking a balance between proprietary code and time to market is critical, and open source usage allows these companies to focus their attention on their unique value proposition.

The Red Hat report notes that 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.

Open Source Backbone
Whatever numbers you look at, it's clear that open source components and libraries form the backbone of nearly every application and spans all industries. 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 of it.

At the same time, 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 open source component choices made by their developers. As a consequence, all the benefits that come with open source can also bring a variety of risks.

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. It's the act of patching that is often the problem.

An alarming number of companies aren't applying patches in a timely fashion (for both proprietary and open source software), 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 with the financial costs of addressing that risk.

Unpatched software vulnerabilities are one of the biggest cyberthreats that 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 one open source vulnerability. In 2018, the NVD added over 16,500 new vulnerabilities. This represents a rate of over 45 new disclosures daily, or a pace most organizations are ill equipped to handle. Given open source components are consumed both in source form as well as from commercial applications, a comprehensive open source governance strategy should encompass both source code usage as well as the governance practices for any software or service provider.

The bottom line is that it's impossible to patch software you don't know you have in use. Similarly, it's a waste of resources to perform scans for network vulnerabilities in software which you haven't deployed. Effectively, 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.

Related Content: