Open Source Security – Risks and Best Practices

What Is Open Source Security?

Open source security means securing open source code, which developers use because it’s often (but not always) free, usually high-quality, and the convenience saves them time and money. For instance, if they need to add new functionality to a website, open source libraries and components are ready and waiting.

It offers other advantages too. Open source software is typically developed collaboratively, and users are encouraged to contribute to the codebase. That means a whole community of knowledgeable and enthusiastic users is ready to offer technical assistance if anyone runs into difficulties. 

With proprietary software, users can feel locked in because the cost and inconvenience of switching away from a vendor they’ve invested so much in seems too high, but with open source that isn’t an issue. License terms usually allow developers to modify the code to meet their specific needs, and the community can add features and quickly fix bugs, because, unlike with proprietary solutions, the code is transparent, so everyone can see how it works.

The transparency factor is a big deal when it comes to open source security because it often means many pairs of eyes have scrutinized the code, so in theory, there shouldn’t be any issues. Unfortunately, that isn’t always the case. Bad actors will always try to infiltrate open source projects because they see the opportunity to distribute their malware widely, possibly to millions of victims. That’s why the 90%+ of organizations using open source code need to understand open source security risks. In this article, we look at some potential open source security pitfalls and discuss how security teams can protect against them.

Open Source Security Risks

Unpatched Vulnerabilities

In an ideal world, open source security would be effective across the board because all volunteers would issue critical updates and patches promptly, but this is the real world, so with some packages, you may encounter no support and no accountability. Some receive regular security updates, some intermittently, and others not at all.

When you entrust maintenance to volunteers, you’re at the mercy of their skills, goodwill, and available bandwidth. That’s why everything from minor bugs to critical security flaws in some applications can go unpatched, leaving the door open for attackers to exploit.

Compromised Packages

Cybercriminals can add malicious code that deliberately introduces vulnerabilities to open source code. They may also introduce back doors into popular open source libraries, thereby compromising the countless systems that use them.

Misconfiguration

Then there’s human error. Organizations may inadvertently misconfigure open source software, which can create open source security holes, and the software’s default settings might not be secure, especially in production environments.

Dependency Management

Many open source projects have complex dependency chains, making it difficult to track all their components. Vulnerabilities in any of these dependencies can affect the entire application.

Insider Threats

Open source projects can be modified by anyone, including malicious insiders who intend to add harmful code.

Compliance and Licensing Issues

Organizations must ensure they comply with open source licenses, which can be complex. Non-compliance can lead to legal risks and potential financial penalties, so most invest in software compliance analysis (SCA) tools, like Black Duck, Snyk, and WhiteSource (now Mend) to track and manage licensing. 

Integration Challenges

Integrating open source with proprietary software can introduce open source security risks, especially if it lacks adequate security features or if the integration is not done securely.

Lack of Open Source Security Maintenance

As we’ve noted, open source projects may not have the resources or funding to maintain and update their software so vulnerabilities may go unpatched.

Zero-Day Exploits

Open source software can be vulnerable to zero-day exploits, which can be utilized before a patch or fix is available.

Unvetted Contributors

Open source projects often rely on contributions from unknown or unvetted individuals, which can increase the risk of intentional or unintentional security vulnerabilities. 

Inadequate Documentation and Support

Open source software may lack comprehensive documentation and support, making it challenging for organizations to implement and secure the software correctly.

Recent Examples of Open Source Security Incidents

XZ Utils Backdoor (March 2024)

A malicious backdoor was discovered in XZ Utils, a fundamental compression tool used in many Linux distributions. The compromise (CVE-2024-3094) occurred when attackers gained access to the maintainer’s account and inserted malicious code that could enable remote code execution. This incident was particularly severe because XZ Utils is a core component in many Linux systems and build processes, so it had the potential to affect millions of servers and devices. The backdoor remained undetected for several days before security researchers discovered it.

We mentioned this episode in our polyfill.io article. This popular JavaScript library was taken over by a mysterious Chinese company (called Funnull) whose CDN began delivering malicious JavaScript code, which reached over 110,000 websites. 

PYPI Supply Chain Attacks (Late 2023-Early 2024)

Multiple malicious packages were discovered masquerading as popular Python libraries like Requests and urllib3. The attackers used typo-squatting techniques (similar package names) and version number manipulation to trick developers. These packages contained malicious code designed to steal sensitive information and credentials, and they affected thousands of developers before this was detected. 

Curl Vulnerabilities (October 2023)

The curl vulnerabilities, particularly CVE-2023-38545, allowed attackers to bypass authentication in multi-user systems. The issue affected millions of devices since curl is one of the most widely used data transfer tools in the world. It’s surprising and concerning to note that this vulnerability had gone undetected for over a decade before it was finally discovered. 

NPM Package Compromise (2021)

A Regular Expression Denial of Service (ReDOS) vulnerability, CVE-2021-29060, was discovered in the NPM package color-string (a library for parsing and generating CSS color strings). This vulnerability could be exploited by providing a crafted invalid HWB string, leading to potential denial of service. 

Azure App Service Source Code Leak (December 2023)

The debug feature misconfiguration in Azure App Service for Linux exposed customer application source code through a publicly accessible endpoint. This incident affected organizations using Azure’s platform-as-a-service offerings and emphasized the risks of default debug configurations in production environments. Microsoft had to release an emergency patch and notify affected customers. 

Shellshock (2014)

This vulnerability affected the Bash shell, a common command-line interpreter used in many Unix-based systems. Shellshock allowed attackers to execute arbitrary commands on affected systems, leading to potential system compromise. 

Equifax Data Breach (2017)

Equifax suffered a massive data breach due to an unpatched vulnerability in the Apache Struts framework, an open source web application framework. The breach exposed the personal information of approximately 147 million people. 

Apache ActiveMQ Vulnerability (October 2023)

The remote code execution vulnerability in Apache ActiveMQ (CVE-2023-46604) allowed attackers to execute arbitrary code on affected servers. This was particularly impactful because ActiveMQ is widely used in enterprise environments for message queuing and system integration. Several ransomware groups actively exploited this vulnerability to deploy malware and crypto miners.

Log4j Vulnerability (December 2021)

This vulnerability (CVE-2021-44228) in Apache’s Log4j library allowed attackers to execute arbitrary code by sending specially crafted strings that could be logged. This vulnerability was particularly severe because Log4j is used in countless Java applications and enterprise systems, making it one of the most widespread open source security issues ever discovered. The ease of exploitation and the ubiquity of the affected software led to millions of attacks within hours of disclosure. Many organizations are still discovering and patching affected systems even years later.

Heartbleed Bug (2014)

The Heartbleed vulnerability (CVE-2014-0160) in OpenSSL allowed attackers to read sensitive memory contents from affected servers, potentially exposing private keys, passwords, and other sensitive data. This bug affected approximately 17% of all SSL-enabled web servers when discovered and is considered one of the most significant open source security vulnerabilities ever found. What made it particularly devastating was that it left no traces of exploitation and had existed for about two years before it was discovered. The incident led to widespread changes in how open source projects are maintained and funded. 

Open Source Security Best Practices

Below is the current OWASP Foundation list of the top 10 risks associated with using open source code, and for each one, we’ve included the best practices you can use to avoid them.

Known Vulnerabilities

Given that open source components may contain vulnerable code, it’s important to regularly update and patch software to fix these known vulnerabilities. You should also use vulnerability databases and security advisories to stay informed about new threats. 

Compromise of Legitimate Package

Attackers may inject malicious code into legitimate projects, so use secure distribution channels and verify the integrity of packages. The Funnull case mentioned previously shows just how important a trustworthy distribution channel is. Implement cryptographic signatures to ensure the authenticity of the software.

Name Confusion Attacks

This is where attackers create components with names similar to legitimate ones. In response, you should implement strict naming conventions and verify the source of components. Use tools that can detect typosquatting and other naming attacks, such as JFrog Xray (part of JFrog Artifactory), which can alert on discrepancies in dependency names or versions, ensuring components are correctly referenced.

Unmaintained Software

When components are no longer actively developed, monitor and replace them with actively supported ones. Contribute to the maintenance of critical components if possible.

Outdated Software

For old versions of components, make sure to regularly update to the latest ones. Use automated tools to track and manage updates.

Untracked Dependencies

For dependencies that developers are unaware of, use SCA tools like those mentioned previously to identify vulnerabilities and licensing issues. They can identify and manage open source components within software applications, as well as scan the codebase for open source libraries, dependencies, and third-party components. They check for vulnerabilities, licensing issues, and outdated libraries. Using them helps ensure that the software is secure and compliant with licensing requirements.

An SCA can generate a Software Bill of Materials (SBOM), which is a detailed inventory of all the components that make up a piece of software. It lists the open source and proprietary components, their versions, and their relationships to other components. Think of it as being like a list of ingredients for a recipe but for software. An SBOM helps with transparency, security, and managing the software supply chain. 

License Risk

Components may have incompatible or unclear licenses. Ensure compliance with licensing requirements and use automated license management tools. Conduct regular audits to verify license compliance.

Immature Software

This means projects that do not follow best practices. Test the maturity of projects before using them and perhaps consider contributing to improving their practices. Favor components with a strong community and active development.

Unapproved Change

Unauthorized changes to components. Implement strict change management processes and verify the integrity of components. Use version control systems to track changes and ensure accountability.

Under/Over-Sized Dependency

Components that provide too little or too much functionality. Choose components that match the required functionality and avoid unnecessary dependencies. Regularly review and refactor dependencies to ensure they are appropriate for the project.

How Reflectiz Can Help with Open Source Security

Reflectiz manages open source dependencies by providing comprehensive visibility and continuous monitoring of all components within your web environment. Here are some key aspects of how Reflectiz handles open source dependencies: 

1. Comprehensive Visibility: Reflectiz maps all your website’s components, including open source tools, into a single, accessible online inventory. This helps in identifying and managing all dependencies effectively.

2. Continuous Monitoring: Reflectiz continuously monitors all website components to detect risks and vulnerabilities at the earliest stage. This includes monitoring third-party apps, remote services, CDN repositories, and open source tools.

3. Risk Management: Reflectiz helps in establishing a baseline for approved and unapproved app behaviors based on your business context. This minimizes alert fatigue by flagging only genuine and significant changes.

4. Security Insights: Reflectiz provides enhanced visibility of your web exposure, allowing you to proactively combat sophisticated web-based cyber threats. This includes managing the risks associated with open source dependencies.

5. Compliance: Reflectiz ensures full security compliance by monitoring all actions related to sensitive data, PII, and PHI.

By integrating these features, Reflectiz helps your organization manage open source dependencies more effectively, ensuring security and compliance across its web environments. Find out for yourself. Sign up here, today!