Debunking Open Source Software Security Myths

There are many long-held, critical opinions regarding open source software security. But do these opinions reflect the modern reality of open source? Or are they reflective of a past that no longer exists?

In this blog, we look at the current state of open source software security, debunk some commonly held myths regarding open source risks, including concerns around longevity, testing, validation, and enterprise viability.

What Is the State of Open Source Software Security?

Creating a software system that is 100% secure is virtually impossible. Computers are incredibly complex machines, and all the consequences of programs written to run on them cannot be understood by even the best minds in IT. 

Also, it's important to realize that there are thousands of unique OSS projects available for download. Perusing this vast landscape, one will quickly see that not all OSS is created equal. From OSS created by a high school student in their basement to OSS developed by a consortium of some of the largest companies in the world, you can imagine that there would be a great deal of variability in both the quality of the software and how secure it is. In reality, OSS is no less secure than commercial or proprietary software.

So instead of asking "is open source software secure?" a more realistic question that IT managers, developers, and system administrators might ask is "Does the OSS project that I’m considering deploying into my organization’s infrastructure meet or exceed the minimum security requirements or policies that exist for all software used in production?” 

That question needs to be asked for every OSS project in consideration. For this reason, it is recommended that organizations institute open source governance and software lifecycle management policies and practices to help to mitigate exposure to security vulnerabilities from OSS.

Common Open Source Software Security Myths

Within the general concerns regarding open source security, we typically hear complaints centered around a perceived lack of testing and validation. Teams also frequently express reservations about the longevity of the OSS trend, and OSS suitability for enterprise applications as barriers to adoption. But are these fears valid?

Let's unpack these commonly cited risks and see if there’s any truth to them.

Myth #1: Open Source Software Isn’t Tested

Mature OSS projects adhere to rigorous testing processes before they are released. Open source projects that are part of a foundation like the Apache Foundation, the Linux Foundation, or the Cloud Native Computing Foundation (CNCF), enforce strict processes and policies to ensure the highest quality of their software releases. For example, the Apache Test project is focused on designing test tools for the Apache HTTP Server.

However, the ultimate test for software comes when it is deployed in production environments to handle a wide variety of use cases. Considering that a great number of OSS projects have been used in many production environments for decades in thousands of organizations around the world, I would say that OSS projects are generally more well-tested than their commercial counterparts.

As a software development manager years ago, I used to tell my development team that the best software we have is the code that we have deployed to production. Therefore when starting a new project, our focus was to reuse existing production code over writing new code.

With reuse in mind, many OSS projects use other OSS libraries to implement their features. For example, most of the features included in the WildFly application server come from other OSS projects like Undertow, Infinispan and Artemis.

Myth #2: Open Source Software Isn’t Validated

Open source Java Enterprise Edition (JEE) application servers like WildFly must undergo a third-party evaluation process in order to be “certified JEE compatible”.

CNCF's Certified Kubernetes Conformance Program (KCSP) enables vendors to prove that their product conforms with a core set of Kubernetes APIs and are interoperable with other Kubernetes implementations.

The Linux Test project is a joint project started by SGI, and developed and maintained by IBM, Cisco, Fujitsu, SUSE, Red Hat and others with a goal to deliver test suites to the open source community that validate the reliability, robustness, and stability of Linux.

But the ultimate validation is how broadly a piece of software is deployed to solve a multitude of problems in companies around the world. The Apache HTTP server is the most widely used web server in the world. The Chrome web browser is used by millions daily. Linux is found everywhere, from the smallest servers, like IoT devices, to the world’s fastest supercomputers. Examples like these validate that these OSS projects are ready for prime time.

Open Source Software Security & Compliance: What Organizations Need to Know

Watch this on-demand webinar for open source software security updates and compliance regulations around OSS usage.

The referenced media source is missing and needs to be re-embedded.

Myth #3: Open Source Software Is a Fad

With the increasing investment by companies and venture capitalists throughout the years, it is clear that OSS isn’t going anywhere anytime soon. Below is a small list of some of the major investments made in the OSS arena in recent years:

• 2018 IBM acquires Red Hat for $34 billion (the largest software acquisition in history)

• 2018 Microsoft acquires GitHub for $7.5 billion

• 2018 Salesforce acquires Mulesoft for $6.5 billion

• 2019 VMWare acquires Pivotal for $2.7 billion

• 2020 Progress Software acquires Chef for $220 million 

• 2022 Snowflake acquires Streamlit for $800 million

Considering that investment in OSS seems to be growing exponentially, and it is being used in key parts of the mission-critical infrastructure of a vast number of companies, there is no going back to the proprietary ways of the past.

Myth #4: Open Source Software Isn’t Enterprise-Ready

Many of the most popular open source projects had their inception within large enterprises. Kubernetes is a perfect example of this. Since being donated to the OSS community in 2015 by Google, 64% of enterprise companies included in the Cloud Native Computing Foundation’s biannual survey in 2022 reported that they’re running Kubernetes in production environments.

Below is a list of some other notable OSS technologies that had their start inside corporations:

• Chrome - Google
• Kubernetes - Google
• Cassandra - Facebook
• Apache Kafka  -  Twitter/X
• Open Service Mesh – Microsoft

Additionally, Netflix has made many of the technologies it uses to run its business available as OSS.

It is, however, still critical that organizations have processes in place to evaluate any given OSS package to ensure that it meets a set of minimum requirements for deploying it into their enterprise. One of the key requirements would be “can I get immediate 24/7 technical support for this package if production goes down?”

In those high pressure situations, relying on the community for answers may not be the best option. To address this issue, organizations can partner with vendors like OpenLogic for SLA-backed support for many of the most widely used open source technologies in the world. Since every technology OpenLogic supports has been vetted by our certification process, organizations also have the confidence that those open source technologies are indeed ready to use in their enterprises.

Myth #5: Open Source Is Unregulated

Compliance is an big part of the open source security conversation and the open source technologies you find running mission-critical apps in enterprise settings are generally as regulated as closed source software, if not more so. In terms of open source compliance, organizations may be subject to both internal IT policies and external regulations that are federally enforced. 

Internal open source compliance requirements could include:

• Running the latest version of the current release
• No end-of-life (EOL) software
• Formal technical support
• Appropriate licensing in place for all open source components. 

External compliance standards tend to focus on things like applying vendor-supplied security patches and not using unsupported versions of software. There are also regulations that are specific to particular sectors and use cases, like FedRAMP for government agencies and PSI-DSS for credit card transactions, as well as more general regulations, like the CIS Benchmarks. 

Here's a brief video explaining some of these compliance standards in more detail:

Another way to internally regulate your organization's use of open source is to create an Open Source Program Office, or OSPO. 

What Is an Open Source Program Office?

An Open Source Program Office (OSPO) is a dedicated team responsible for coordinating and managing how OSS is used within their organization. 

An OSPO can address tasks such as:

• Open source governance and policy development: Establishing and ensuring compliance with policies, guidelines, and best practices on how OSS should be used within their organization.

• Maintaining a Software Bill of Materials (SBOM): SBOMs provide an inventory of all OSS components and dependencies included in a project and provide information on versions and licenses. The OSPO may institute policies that specify which versions of OSS should be used within the organization based on known vulnerabilities and other factors. 

Video: Why You Need a Software Bill of Materials 

The referenced media source is missing and needs to be re-embedded.

• Risk management: Proactively managing risks associated with using OSS components by conducting risk assessments, monitoring vulnerability databases, and implementing processes to promptly mitigate them can help prevent security incidents and reduce the impact should one occur.

• Vulnerability management: The OSPO can implement processes for vulnerability management and remediation. When a new vulnerability is reported, the OSPO team can use the SBOM to quickly determine if their systems are affected and work with development teams to remediate them, greatly reducing the risk of exposure.

New Open Source Software Security Initiatives

Last year, the OSS Security Mobilization Plan was created by the Linux Foundation and OpenSSF with input from some of the world's biggest technology companies. The plan outlines 10 streams of investment for improving open source software security; to learn more, watch this video.

Another indication of how critically important open source software security has become to society is the bipartisan Securing Open Source Software Act, a bill introduced in the U.S. Senate in 2022. In short, the bill would require the Cybersecurity and Infrastructure Security Agency (CISA) to develop a framework for identifying and mitigating vulnerabilities in open source software used by federal agencies. The CISA would evaluate how this framework could be used voluntarily by critical infrastructure operators. 

A big impetus for this bill is to prevent Log4Shell types of security incidents by strengthening collaboration between the government and OSS communities. If passed, it will bring great benefits to OSS security as the vast resources of the federal government can be employed to tackle the complex and rapidly evolving OSS security landscape.

The OpenLogic Approach to Open Source Software Security 

Before we decide to provide support for a particular OSS project, OpenLogic employs a comprehensive certification process that examines a wide range of aspects (how many developers, how many releases per year, how well documented, number of reported vulnerabilities, user base size, etc.) of the project in question.

Open source documentation and forums can only do so much. Since most security incidents are related to the misconfiguration of software, not the software itself, OpenLogic provides advisory support to our customers on OSS configuration best practices which help to mitigate security risks. Click the button below to learn more. 

Explore Solutions 

Final Thoughts

The debate over the enterprise viability of OSS is, for the most part, over. With open source technology at the heart of the digital transformation revolution happening around the globe, Marc Andreesen’s famous declaration, “software is eating the world,” can now be restated as “open source is eating the world.” 

With regards to open source software security, it is worth noting that the transparency of OSS means more eyes on the code, which can enhance security by community scrutiny and collaboration. The visibility of source code in OSS can also facilitate vulnerability discovery by security communities and researchers. Of course, a multi-faceted approach is always required to reduce an organization’s exposure to security incidents, so it is important to follow security best practices and guidelines for all software used in production, commercial and open source.

Additional Resources

• Blog - Navigating Software Dependencies and OSS Inventory Management
• Blog - Understanding CVEs and CVSS Scores
• Webinar - Application Security Basics
• White Paper - State of Open Source Report
• Blog - Why Companies Choose OpenLogic for OSS Support
• Guide - What is Enterprise Application Security?
• Blog - What is the Cyber Resilience Act?
• Video - Risks of Ignoring EOL
• Video - Open Source Security