Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

10:00 AM
 Tim Mackey
Tim Mackey
Connect Directly
E-Mail vvv

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

It's time to reassess your open source management policies and processes.

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:

Tim Mackey is Principal Security Strategist, CyRC, at Synopsys. Within this role, he engages with various technical communities to understand how to best solve application security problems. He specializes in container security, virtualization, cloud technologies, distributed ... View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Author
6/19/2019 | 10:05:28 AM
Re: On Open Source, Freeware and other slithy toves
My core point being that open source components are likely throughout your environment, not just in a test area. That's in large part due to the types of problems solved. So, if you look closely at any firmware, you'll likely see open source components in there. The same goes for virtualization and containerization software or public cloud infrastructure. Even Microsoft is a huge supporter of open source with over 2500 projects published on GitHub and .Net Core available under an MIT license.

Net of this, you're absolutely right that a risk reward tradeoff is required – it's just that with the ubiquity of open source usage in commercial applications, you're going to want to ensure you know what's being used or embedded regardless of where it originated.
User Rank: Ninja
6/19/2019 | 8:40:28 AM
Re: On Open Source, Freeware and other slithy toves
i neglected to comment that some open source or shareware can be VERY VERY useful, performing short-cut work that off the shelf applications do not and, by that virtue, are beloved.  That said, IT professionals then have to weigh the risk-reward equation on this product.  Is it worth the ease of task vs. ease of infection and lack or difficulty of patching resources.   There is also the severity of platform mount - is the software on a non-important system or a critical host server.  Some of it is just grand for programming.  Single workstation, ok, a threat point but not a server.  So it is a balance act between threat and gain. 
User Rank: Author
6/18/2019 | 3:31:35 PM
Re: On Open Source, Freeware and other slithy toves
The most interesting thing we see when auditing an application is how strongly some teams hold on to the perception there is no, or at best limited, use of open source technologies in their applications or environments. The reality is that open source is part of most modern applications – be it in the app itself or how its deployed. Not knowing what you've got is the easiest way to get blind-sided. That's why the patch management strategy is so crucial, and if you'd prefer a patch Tuesday type model, there are many vendors out there who'll happily provide that type of service for a license/support fee. Just be careful to get that complete inventory so you can ensure full compliance from all vendors - otherwise that 50s Olds experience could be the result!

User Rank: Ninja
6/18/2019 | 2:31:15 PM
On Open Source, Freeware and other slithy toves
I have liked shareware ages ago because it was fun and generally free.  These days it is also wide open available and as an open door product, I have never considered for use in a corporate environment.  Rather like having an old 1950's Oldsmobile in the back yard - easy to break into.  It just is a risk by itself and patching is the next nightmare, point of this article.  Indeed you have to devote some resource and time to patching - no Patch tuesday here.  It just never struck me in the right vein and, today, I have none of it at all.   
7 Tips for Infosec Pros Considering A Lateral Career Move
Kelly Sheridan, Staff Editor, Dark Reading,  1/21/2020
For Mismanaged SOCs, The Price Is Not Right
Kelly Sheridan, Staff Editor, Dark Reading,  1/22/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment:   It's a PEN test of our cloud security.
Current Issue
IT 2020: A Look Ahead
Are you ready for the critical changes that will occur in 2020? We've compiled editor insights from the best of our network (Dark Reading, Data Center Knowledge, InformationWeek, ITPro Today and Network Computing) to deliver to you a look at the trends, technologies, and threats that are emerging in the coming year. Download it today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-01-25
An exploitable out-of-bounds read vulnerability exists in AMD ATIDXX64.DLL driver, version 26.20.13001.50005. A specially crafted pixel shader can cause a denial of service. An attacker can provide a specially crafted shader file to trigger this vulnerability. This vulnerability can be triggered fro...
PUBLISHED: 2020-01-25
An exploitable out-of-bounds read vulnerability exists in AMD ATIDXX64.DLL driver, version 26.20.13025.10004. A specially crafted pixel shader can cause a denial of service. An attacker can provide a specially crafted shader file to trigger this vulnerability. This vulnerability can be triggered fro...
PUBLISHED: 2020-01-25
An exploitable out-of-bounds read vulnerability exists in AMD ATIDXX64.DLL driver, version 26.20.13003.1007. A specially crafted pixel shader can cause a denial of service. An attacker can provide a specially crafted shader file to trigger this vulnerability. This vulnerability can be triggered from...
PUBLISHED: 2020-01-25
An exploitable type confusion vulnerability exists in AMD ATIDXX64.DLL driver, versions 26.20.13031.10003, 26.20.13031.15006 and 26.20.13031.18002. A specially crafted pixel shader can cause a type confusion issue, leading to potential code execution. An attacker can provide a specially crafted shad...
PUBLISHED: 2020-01-24
Cross-site scripting in SimpleSAMLphp before version 1.18.4. The www/erroreport.php script allows error reports to be submitted and sent to the system administrator. Starting with SimpleSAMLphp 1.18.0, a new SimpleSAML\Utils\EMail class was introduced to handle sending emails, implemented as a wrapp...