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
Cyberattacks Are Tailored to Employees ... Why Isn't Security Training?
Tim Sadler, CEO and co-founder of Tessian,  6/17/2021
7 Powerful Cybersecurity Skills the Energy Sector Needs Most
Pam Baker, Contributing Writer,  6/22/2021
Microsoft Disrupts Large-Scale BEC Campaign Across Web Services
Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-24
In the bindata RubyGem before version 2.4.10 there is a potential denial-of-service vulnerability. In affected versions it is very slow for certain classes in BinData to be created. For example BinData::Bit100000, BinData::Bit100001, BinData::Bit100002, BinData::Bit<N>. In combination with &lt...
PUBLISHED: 2021-06-24
The blockchain node in FISCO-BCOS V2.7.2 may have a bug when dealing with unformatted packet and lead to a crash. A malicious node can send a packet continuously. The packet is in an incorrect format and cannot be decoded by the node correctly. As a result, the node may consume the memory sustainabl...
PUBLISHED: 2021-06-23
Vulnerability in OpenGrok (component: Web App). Versions that are affected are 1.6.7 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via HTTPS to compromise OpenGrok. Successful attacks of this vulnerability can result in takeover of OpenGrok. CVSS 3.1 ...
PUBLISHED: 2021-06-23
A vulnerability in SonicOS where the HTTP server response leaks partial memory by sending a crafted HTTP request, this can potentially lead to an internal sensitive data disclosure vulnerability.
PUBLISHED: 2021-06-23
A command execution vulnerability exists in the default legacy spellchecker plugin in Moodle 3.10. A specially crafted series of HTTP requests can lead to command execution. An attacker must have administrator privileges to exploit this vulnerabilities.