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
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/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-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...