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:30 AM
Jeff Williams
Jeff Williams
Connect Directly
E-Mail vvv

Open Source Software Poses a Real Security Threat

It's true that open source software has many benefits, but it also has weak points. These four practical steps can help your company stay safer.

Open source code has conquered the world of software. Almost every website, API, and application is built on an enormous stack of open source libraries and frameworks that totals many millions of lines of code. Millions of corporations and developers are taking advantage of the expansive array of components, zero cost, and easy integration to create more-sophisticated software far faster than building it themselves.

I am a huge advocate of open source and have led several very successful open source projects. But along with all the benefits of open source components, we have to recognize some new risks. There are millions of these libraries in all the different software languages, such as Java, .NET, Ruby, Python, Go, and many more. Dozens of new vulnerabilities are discovered every week, but we’re only scratching the surface. The problem is that only a handful of talented security researchers are doing the highly skilled work of testing this code.

That means that there are, almost certainly, large numbers of latent vulnerabilities in open source software. Having a researcher discover one of these and publish it seems like an expensive fire drill for companies, because they have to search to see if they're using the library, replace it, recode their application to match, retest, resecure, and redeploy. But if a malicious actor finds the vulnerability and starts attacking companies with it, the damage can be much more expensive. Web applications and web APIs run with almost full privilege inside a company's data center, and all that open source inherits the power to do anything the application can do.

Bad actors have recognized the power of the software supply chain attack vector. If finding a vulnerability gets too hard, they can switch to attacking the open source projects themselves. For example, they could simply join a project and contribute code that contains or creates a weakness. Or they could target the open source repositories cloning an existing library, introduce malicious code, and make it available with a similar name as the original. Hackers have even targeted the development "tool chain" to inject their code into binaries. In all these examples, developers and end users alike would not see the attack happening in their data center, but they would be completely owned.

The ramifications of this are staggering. If an attacker was able to infiltrate a popular library like log4j, they would very quickly be running with privilege inside most data centers in the world. They could use this access to not only attack the targeted application but as an internal launching point for attacks on the organization's internal network. And that's just a single library. This is the easiest path to seriously disrupting the Internet and harming huge numbers of people.

Organizations need to minimize their exposure and establish the capability to respond to novel vulnerabilities and attacks within hours. Unfortunately, most organizations take months to respond and are very exposed in the interim. Every company that is betting their future on software needs to have a strategy for beefing up the security of their software supply chain. Here are a few practical tips:

  1. Exercise Restraint: Don't allow just any random library into your supply chain. Remember that you are betting your company on the security of that code. Set and enforce some policies around the types of code you will allow. Look for projects with high popularity, active committers, and evidence of process — including security.
  1. Establish Guardrails: Create guidelines for secure use of the libraries you select for use. Define how you expect each library to be used, and detail how developers should safely install, configure, and use each library in their code. Also, be sure to identify dangerous methods and how to use them safely.
  1. Constant Vigilance: Establish continuous self-inventory so you know exactly what open source libraries you are using in your inventory. Ensure that you have a notification system in place, so you know exactly what applications and servers are affected by new vulnerabilities.
  1. Runtime Protection: Use runtime application security protection (RASP) to prevent both "known" and "unknown" library vulnerabilities from being exploited. If novel vulnerabilities are disclosed, your RASP infrastructure enables you to respond in minutes, not weeks or months.

In an age of "digital transformation initiatives" your software supply chain is the key to creating and deploying applications quickly. Please make sure you don't inadvertently undermine your entire business in the rush to reinvent it.

Related Content:

Learn from the industry's most knowledgeable CISOs and IT security experts in a setting that is conducive to interaction and conversation. Early-bird rate ends August 31. Click for more info

A pioneer in application security, Jeff Williams is the founder and CTO of Contrast Security, a revolutionary application security product that enhances software with the power to defend itself, check itself for vulnerabilities, and join a security command and control ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
9/28/2018 | 4:59:22 PM
Re: contrast with closed source
Well, you're right in the sense that this is a problem for both open and closed source code.  But they're not the same. The success of open source code has made your point incorrect.  The size and complexity of the open source supply chain is dramatically larger than for closed source. The average web application is now 81% open source libraries and frameworks (although 72% of *that* is never invoked).  Your point about closed-source projects just makes my point.  Further, updating open source isn't the same as updating closed source.  Nobody goes back and provides patches for old open source... you are forced to upgrade to the latest version.  That means changing your software to match.  As I mentioned, I'm a huge open source advocate, but you can't try this false equivalence thing -- it's not helping the cause.  That bear now deserves to be poked.
User Rank: Strategist
8/15/2018 | 2:41:39 PM
contrast with closed source
I feel that this headline was designed to poke the FOSS bear. :)

Singling this out as an open-source problem is insufficiently precise. The valid points made here have less to do with open source per se than they do with overall software supply chain.

Further, most closed-source projects are themselves built on top of many layers of open-source components - from Linux to Apache http to Cygwin to the broad spectrum of libraries. This is especially true for security appliances. With open source, you and others can at least verify that you're using current, patched versions of those components - and quickly upgrade them to respond to vulnerabilities, instead of waiting for your vendor's next quarterly/yearly patch/certification cycle.

As a FOSS advocate, it would have been more even-handed of you to have included points such as these as part of your analysis.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Google Cloud Debuts Threat-Detection Service
Robert Lemos, Contributing Writer,  9/23/2020
Shopify's Employee Data Theft Underscores Risk of Rogue Insiders
Kelly Sheridan, Staff Editor, Dark Reading,  9/23/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-09-27
XSS exists in the MobileFrontend extension for MediaWiki before 1.34.4 because section.line is mishandled during regex section line replacement from PageGateway. Using crafted HTML, an attacker can elicit an XSS attack via jQuery's parseHTML method, which can cause image callbacks to fire even witho...
PUBLISHED: 2020-09-27
An issue was discovered in the FileImporter extension for MediaWiki before 1.34.4. An attacker can import a file even when the target page is protected against "page creation" and the attacker should not be able to create it. This occurs because of a mishandled distinction between an uploa...
PUBLISHED: 2020-09-27
An issue was discovered in MediaWiki 1.34.x before 1.34.4. On Special:Contributions, the NS filter uses unescaped messages as keys in the option key for an HTMLForm specifier. This is vulnerable to a mild XSS if one of those messages is changed to include raw HTML.
PUBLISHED: 2020-09-27
In MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4, Special:UserRights exposes the existence of hidden users.
PUBLISHED: 2020-09-27
In MediaWiki before 1.31.10 and 1.32.x through 1.34.x before 1.34.4, XSS related to jQuery can occur. The attacker creates a message with [javascript:payload xss] and turns it into a jQuery object with mw.message().parse(). The expected result is that the jQuery object does not contain an <a> ...