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

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.

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 MITRE, NIST 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.