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
Overcoming the Challenge of Shorter Certificate Lifespans
Mike Cooper, Founder & CEO of Revocent,  10/15/2020
US Counterintelligence Director & Fmr. Europol Leader Talk Election Security
Kelly Sheridan, Staff Editor, Dark Reading,  10/16/2020
7 Tips for Choosing Security Metrics That Matter
Ericka Chickowski, Contributing Writer,  10/19/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-10-20
The Transaction Insight reporting component of TIBCO Software Inc.'s TIBCO Foresight Archive and Retrieval System, TIBCO Foresight Archive and Retrieval System Healthcare Edition, TIBCO Foresight Operational Monitor, TIBCO Foresight Operational Monitor Healthcare Edition, TIBCO Foresight Transaction...
PUBLISHED: 2020-10-20
The Boxstarter installer before version 2.13.0 configures C:\ProgramData\Boxstarter to be in the system-wide PATH environment variable. However, this directory is writable by normal, unprivileged users. To exploit the vulnerability, place a DLL in this directory that a privileged service is looking ...
PUBLISHED: 2020-10-20
In Spree before versions 3.7.11, 4.0.4, or 4.1.11, expired user tokens could be used to access Storefront API v2 endpoints. The issue is patched in versions 3.7.11, 4.0.4 and 4.1.11. A workaround without upgrading is described in the linked advisory.
PUBLISHED: 2020-10-20
DomainMOD before 4.14.0 uses MD5 without a salt for password storage.
PUBLISHED: 2020-10-20
Netwrix Account Lockout Examiner before 5.1 allows remote attackers to capture the Net-NTLMv1/v2 authentication challenge hash of the Domain Administrator (that is configured within the product in its installation state) by generating a single Kerberos Pre-Authentication Failed (ID 4771) event on a ...