Wednesday, January 1, 2025
HomeComputer SecurityBeware of Dangerous Security Risks By Using Open-Source Software and Tools

Beware of Dangerous Security Risks By Using Open-Source Software and Tools

Published on

SIEM as a Service

Open-source is increasingly prevalent, either as components in software or as entire tools and toolchains.

It has become a vital part of DevOps and cloud-native environments and is at the root of many servers and systems.

This frequency should make minimizing the risks of using open-source a serious consideration for any organization.

- Advertisement - SIEM as a Service

In this article, you’ll learn some of the most common risks of open-source inclusion.

You’ll also learn some best practices for minimizing your risk and ensuring that you can continue to use open-source safely.

Common Open-Source Risks

Understanding the risks that come with open-source use is the first step to securing your components and systems.

Risks are more than just individual vulnerabilities, although these issues are also important.

Community Nature

The community nature of open-source opens you to risks associated with project abandonment.

Open-source maintainers and contributors are typically working voluntarily and open-source projects are not their primary responsibility.

If these volunteers lose interest in a project or are otherwise unable to contribute, project development may suddenly stop or stall.

This leaves you responsible for all future maintenance, vulnerability fixes, and advancement.

Intellectual property infringement is another risk that stems from community sourcing.

Although project maintainers have control over what code gets inserted into a project, they don’t necessarily know whether or not code contributed by others is proprietary. 

Likewise, if a project was started for personal use, the originator may have decided to ignore licensing. Or, they may have used code that was only available for personal use.

If you include these components and later find that proprietary code is included, you could be held liable.

Exploits are Public Knowledge

Open-source vulnerabilities are made public knowledge, typically 30 to 90 days after a vulnerability is discovered.

Ideally, this gives communities and users enough time to develop a patch and apply it.

However, if you do not patch during this time, your systems will remain vulnerable and an easy target. 

It is common practice for hackers to take publicly available vulnerability information and seek out organizations that are behind on patching.

This information tells attackers exactly how your systems are vulnerable and even how to perform an attack, making their job easy.

Difficulty Tracking Use

The widespread use of open-source means you are likely to have components in most of your applications and tools.

This is true whether or not you’re aware of it. You can read the documentation of tools and applications you use to see what’s included.

However, this information isn’t always easy to find and can be difficult to act on. 

In your own development projects, you may have more control over what dependencies are included.

Unfortunately, it’s common that only partial components or code snippets are used, which are almost impossible to track.

Additionally, your teams may use multiple versions of a single component, making tracking and updating more complex.

Inclusion of Vulnerabilities

Copying open-source code or bits of code without understanding what’s being copied is likely to introduce vulnerabilities. Unfortunately, libraries and tooling are often included in a black-box fashion, with minimal understanding of how items function. 

This is especially problematic when only a portion of code is taken. Unless you understand exactly how code functions it is difficult to tell whether it includes vulnerabilities.

It could also be that vulnerabilities in the copied code are addressed in later lines or accounted for by other functions.

By only copying a portion of the code, you’ve unintentionally excluded these fixes.

Best Practices for Managing Open-Source Vulnerabilities

The following best practices can help you manage risks created by the inclusion of open-source applications and code. 

Monitor Vulnerability Feeds and Databases

Maintainers of open-source projects typically don’t notify users of vulnerability issues. Due to this, it is your responsibility to monitor for patches and to get vulnerability information from other sources. There are a variety of sources to choose from including government and independently managed databases

These sources can provide real-time information and typically include details about vulnerable systems and remediation steps.

Whichever sources you choose, make sure to monitor both official and community feeds. If you don’t you are likely to miss key vulnerabilities. For example, 

JavaScript vulnerabilities are less likely to be reported to official databases. 

Good sources to start with include: 

  • National Vulnerability Database (NVD)
  • Open Web Application Security Project (OWASP)
  • The community feeds of your components

Keep Components Up-to-Date

You need to monitor any open-source components you use and ensure that everything remains up-to-date. The easiest way to do this is with Software Composition Analysis (SCA) tools. 

SCA tools can inventory components, scan for updates and patches, and alert you when components are out-of-date.

These tools typically incorporate or can incorporate the feeds you are already watching.

Unlike with proprietary software, updates will not be pushed to you so it’s your responsibility to pull fixes in.

Additionally, make sure to apply these patches feeds as soon as possible. A number of very public breaches have been caused by vulnerabilities that had a patch which the organization didn’t apply. For example, the Equifax breach.

Minimize Your Dependencies

When deciding which open-source components to include in your systems, try to minimize your dependencies as much as possible.

If you are using the same dependency in multiple projects, try to use the same version.

This makes it easier for you to keep components up-to-date and can minimize compatibility issues.

When using full tools and applications, choose ones that are well maintained with active and reliable communities.

Tools with less support are more likely to have undiscovered or unpatched issues. You should also try to use tools that do not rely on excessive dependencies.

Each dependency adds risks and may be a sign of poor product quality, particularly if libraries are used for easy-to-code functionalities.

Conclusion

Open-source applications and code can be hugely beneficial to organizations and individuals, provided you use it carefully.

When using open-source, there are no service level agreements or liability obligations to fall back on.

Instead, ensuring that your components are updated and properly secured is up to you. 

Hopefully, this article helped you better understand the most common risks faced when using open-source applications and code.

Being mindful of these issues and applying the best practices introduced here should help you minimize your risks. 

Also Read: Top 5 Best Open Source Security Projects That Promote Online Privacy & Protect Your Identity

Balaji
Balaji
BALAJI is an Ex-Security Researcher (Threat Research Labs) at Comodo Cybersecurity. Editor-in-Chief & Co-Founder - Cyber Security News & GBHackers On Security.

Latest articles

CISA Warns of Palo Alto Networks PAN-OS Vulnerability Exploited in Wild

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has issued a high-priority alert on...

US Treasury Department Breach, Hackers Accessed Workstations

The Biden administration confirmed that a Chinese state-sponsored hacking group breached the U.S. Treasury...

TrueNAS CORE Vulnerability Let Attackers Execute Remote Code

Security researchers Daan Keuper, Thijs Alkemade, and Khaled Nassar from Computest Sector 7 disclosed...

New Botnet Exploiting D-Link Routers To Gain Control Remotely

Researchers observed a recent surge in activity from the "FICORA" and "CAPSAICIN," both variants...

API Security Webinar

72 Hours to Audit-Ready API Security

APIs present a unique challenge in this landscape, as risk assessment and mitigation are often hindered by incomplete API inventories and insufficient documentation.

Join Vivek Gopalan, VP of Products at Indusface, in this insightful webinar as he unveils a practical framework for discovering, assessing, and addressing open API vulnerabilities within just 72 hours.

Discussion points

API Discovery: Techniques to identify and map your public APIs comprehensively.
Vulnerability Scanning: Best practices for API vulnerability analysis and penetration testing.
Clean Reporting: Steps to generate a clean, audit-ready vulnerability report within 72 hours.

More like this

Lumma Stealer Attacking Users To Steal Login Credentials From Browsers

Researchers observed Lumma Stealer activity across multiple online samples, including PowerShell scripts and a...

NjRat 2.3D Pro Edition Shared on GitHub: A Growing Cybersecurity Concern

The recent discovery of the NjRat 2.3D Professional Edition on GitHub has raised alarms...

Palo Alto Networks Vulnerability Puts Firewalls at Risk of DoS Attacks

A critical vulnerability, CVE-2024-3393, has been identified in the DNS Security feature of Palo...