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.


10:00 AM
Lech Sandecki
Lech Sandecki
Connect Directly
E-Mail vvv

Open Source Security's Top Threat and What To Do About It

With open source developers regularly churning out new tools, the risk landscape has become too fragmented to properly monitor.

Ninety-nine percent of enterprise codebases contain open source components, according to a recent study. But amid that overwhelming adoption, a hazard has emerged: Organizations have lost visibility of the plethora of open source components being used in their applications and infrastructure, making it harder to identify potential security vulnerabilities.

The same thing that makes open source so powerful — a worldwide community of millions of developers constantly churning out new tools to foster efficiency and innovation — also presents its biggest security test. With so many subcomponents being used in every application, the risk landscape has become too fragmented for security teams to properly monitor the holes that cyberattackers can exploit.

Related Content:

6 Lessons IT Security Can Learn From DevOps

The Threat from the Internet—and What Your Organization Can Do About It

New on The Edge: Think You're Spending Enough on Security?

Fifty-seven percent of respondents to a Gartner survey rated security vulnerabilities as a major challenge when working with open source, which shows that the cost benefits, flexibility, and convenience of open source comes with certain risks that need to be addressed.

It was easier for organizations to understand and control their use of open source software 10 or 20 years ago, when a smaller pool of commercial open source vendors licensed their software to customers, understood everything about the code, and handled security patching.

Now, however, developers draw from a massive array of smaller projects they find on GitHub or share with each other. That, after all, is the beautiful thing about open source — developers no longer have to struggle with bad tools or reinvent software wheels when they can easily benefit from the community's freely available contributions to tackle just about any development need.

When they do so, however, they seldom examine what's under the hood — the source code and its dependencies (the other components with which the tool was assembled and must use to run). 

Can they really trust the code? Does the party who created it stand ready to pinpoint and disclose any security flaws? Is there even someone to contact? A single application can have 10 runtimes and 100 other packages. How can you be confident all are up to date from a security perspective?

This fragmentation is the No. 1 open source security threat for enterprises, and it may help explain why Common Vulnerabilities and Exposures (CVEs) in open source software more than doubled between 2018 and 2019, from 421 to 968, according to a report by information security company RiskSense. 

As COVID-19 brings a variety of changes affecting IT infrastructure and raises new cybersecurity concerns, it has become more important than ever for organizations to recognize the need for better security practices in their enterprises.

Here are three essential steps that every enterprise should follow.

Step 1: Track Open Source Components That Are Being Used
In manufacturing, a bill of materials is a centralized, comprehensive inventory of all the materials and parts needed to make a product. If one is found to be defective, the manufacturer can pinpoint the impact immediately.

By adopting a similar approach, enterprises can gain new visibility into the clutter of open source components that their developers are using. As a result, they can take control of ensuring that their open source components are secure rather than relying on information from the community that is often scant or hard to find. This inventory, which includes all the dependencies used by different applications, can be compiled manually or with an automated discovery tool.

Step 2: Stop Emphasizing Agility Over Security 
To remain competitive, every company today feels pressure to deploy new applications quickly. But that should never come at the cost of security. This is why every organization should embrace DevSecOps, which applies better hygiene to application delivery by introducing security earlier in the application life cycle and requiring security tests and verification at every step.

Step 3: Go with Trusted Proxies Whenever Possible 
Linux publishers, such as Canonical for Ubuntu, have a comprehensive program to review, prioritize, and fix their software packages for vulnerabilities. Although not all open source applications might be covered by default, it is worth checking which open source packages and versions can benefit from security patching. OS publishers maintain their own database to track remediation of the latest public vulnerabilities from various sources, including MITRENIST NVD, and others. These are the kinds of qualities that make a trusted open source provider, and companies would be smart to consider them as part of their open source decisions.

By following these three steps, enterprises can ensure that fragmentation in their open source software doesn't have to mean compromised security. 

Lech is responsible for the security and public cloud products at Canonical, the publisher of Ubuntu. He has over 10 years of experience in product leadership functions across software development, consulting and telecommunication industries. He holds an Executive MBA from LBS. View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
WannaCry Has IoT in Its Crosshairs
Ed Koehler, Distinguished Principal Security Engineer, Office of CTO, at Extreme Network,  9/25/2020
Safeguarding Schools Against RDP-Based Ransomware
James Lui, Ericom Group CTO, Americas,  9/28/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> ...