Popular for being cost-effective and ready-made, open source software (OSS) has earned a spot in enterprise tech stacks, from SMBs to the largest of corporations.

As more businesses increase their reliance on open source software and threat actors show increased focus on supply chain attacks, security leaders are making the effort to better understand what it is their teams are using, what benefits they bring, and any security risks related to their use. This post provides guidelines on how organizations choosing to use these tools can do so both effectively and safely.

Why Open Source Software Is Everywhere

When organizations invest in their security tech stack, open source solutions are a rising choice, providing scalability and cost-effectiveness tailored to the unique needs of their business. Findings from the 2023 edition of the Open Source Security and Risk Analysis (OSSRA) report confirmed the staying power of open source use in today’s industries. Of those surveyed, 96% of scanned codebases contained open source and 76% of code in codebases was open source.

Open source resources are also widely adopted for being highly customizable, allowing users to adapt them to their specific needs. This flexibility can be particularly useful for businesses building a cybersecurity strategy, where organizations often need to tailor their tools to address threats specific to their industry, legal requirements, and client base.

Other than being budget-friendly and extremely accessible, open source resources have also climbed in popularity for their ability to foster innovation in dev teams since new features and capabilities are being added regularly.

The Risks Behind the Use of Open Source Software (OSS)

As more organizations rely on open source frameworks, libraries, and tools in their daily operations, they can easily become keystones in business communications, software capabilities, user interactions and more. Since open source is so accessible for businesses of all sizes and industries, researchers have reported a 633% year-over-year increase in cyberattacks launched against open source software repositories.

Case studies showing threat actor’s focus on open source surges. The 2020 SolarWinds attack, for example, continues to stand as a catalyst for rapid changes in how modern organizations build their security against third-party threats. Just one year after SolarWinds, the Log4j vulnerability shook the digital community when hackers began exploiting an overlooked flaw in the popular open source logging package. At the tail end of last year, threat actors bombarded open source repositories NuGet, PyPI, and npm with over 144,000 malicious packages.

Of particular concern, the OSSRA report found that 89% of codebases scanned in its survey contained open source code more than four years out-of-date.

Before deploying open source frameworks, software, and tools, it is essential for DevOps and SecOps teams to consider the risks they can bring to the organization. Open source security risks include:

• Vulnerabilities and excessive access – True to its name, open source code is accessible by anyone. In the hands of malicious threat actors or opportunistic attackers, open source code can be manipulated and leveraged in malicious campaigns.
• Lack of verification and immature code – Open source software does not carry a guarantee that it has been adequately tested by qualified experts. During its development, it may not have gone through the level of quality assurance needed to ensure its reliability or security.
• Little to no dedicated support or maintenance – Some open source software does not have a dedicated support team meaning security patches and updates may be few if any at all. Without regular updates, bug fixes, and documentation, threat actors can easily exploit existing vulnerabilities to gain unauthorized access to a system.
• Downstream effect of software supply chain attacks – When vulnerabilities exist in third-party code, organizations suddenly run the risk of introducing risks into their own environments, which then affects their clients and so on. Given how popular and widely used many open source repositories are, the U.S. federal government released a series of directives and guidelines on how to secure software development practices.

How to Implement Open-Source Tools Safely

While open source software is an excellent way for SMBs to build their security tool stack, those that err on the side of caution are wise to consider the safety and sustainability of open source tools before working them into their daily operations. Security teams play a vital role in making sure that open source software is good for long-term use by following the below best practices.

Understand the Dependencies & Components

With OSS now common in enterprise software stacks, security, IT and SecOps teams are burdened with the responsibility of investigating the software and making sure it is safe to implement. This investigation starts with managing the risks surrounding dependencies and components.

Businesses using open source libraries should be aware of all dependencies associated with those libraries. Direct dependencies are libraries that a businesses’ code calls directly. Transitive or indirect dependencies add another level – the businesses’ code calls to a library that dependencies are linked to, meaning there is a dependency of a dependency. Such nested dependencies can have several layers in large or complex frameworks. Vulnerabilities can be exposed at any level and dealing with them can become complex. Developers and security teams need to understand each level of dependency and how a security vulnerability impacts the projects they are part of.

Scanners like the OWASP dependency check tool can be helpful in exposing a businesses’ open source usage.

Lay Down Clear Policies on Open Source Usage

For top-down security, business leaders are instrumental in working with SecOps, IT teams and the organization’s security team to create strict policies and rules when it comes to using dependencies.

Developers need training on the risks associated with using open source components and should have a thorough understanding of their company’s policies on review, testing, and approval processes.

Testing the security of open source components is the most effective way to protect the safety of existing applications and assets. This requires a set schedule or process for testing and analysis of open source components, similar to proprietary code reviews.

Track & Update All Used Components

In cybersecurity, it’s often said that visibility is the key to defense. Open source resources allow users to see and modify the source code, which provides transparency and helps ensure that the software does what it claims to do. While in theory this can help identify security flaws or vulnerabilities in the code, in practice much OSS is maintained by unpaid volunteers who may have little time, expertise or inclination to conduct regular security reviews. The burden falls on the user to ensure that code used in a project is verified as trustworthy.

Software composition analysis (SCA) tools can help SecOps teams to analyze software. Creating a central, organized inventory of all open source components in use, ideally with a detailed Bill of Materials (BOM) for each piece of OSS, allows security teams to better track, access, and protect the environment. Inventories should be kept up-to-date and include all current open source projects, regularly-used dependencies, versions in use, and download locations. Inventories are crucial in protecting both code and assets.

To ensure safe and sustainable use, select open source components that have an active development or support community. When security issues and bugs affect components, the open source developers community will often identify and report valuable details and fixes that should be applied immediately. Leaving components unpatched severely heightens the risk of exploitation. In the same vein, the more unsupported or expired libraries that a business decides to use, the harder it is for security teams to keep track of all dependencies, incoming fixes, and newly identified vulnerabilities.

Understand the Risks of Private versus Public Repositories

Once a piece of OSS has entered the organization’s software stack as verified and trusted by the SecOps or DevOps teams, consideration needs to be given to how that code will be maintained and updated.

Package management repositories such as NPM, PyPi, and Crate.io provide great convenience but are also Crate.io targets for supply chain attacks. To mitigate this, developers can fork implementations and use private repositories to update software components. However, it is important to be aware that these also carry risks: dependency confusion attacks can occur if package managers are configured to default to a public repository and the developers use a package name that can be claimed by an attacker, as happened in the PyTorch attack in early 2023. These kind of risks can be mitigated by following best practices such as:

• Ensure package managers call private repositories and are not configured to default to a public repository
• Verify package authenticity through code signing
• Periodically audit and verify externally-sourced code

Conclusion

Demand for business innovation, scalability, and ease of use have all enabled the variety and growth of open source software. With more organizations adopting OSS into their internal processes and their lines of products and services, threat actors have begun to set their sights on targeting exploitable vulnerabilities that exist within open source code and tools.

To safeguard the use of these accessible and cost-effective resources, businesses continue to rely on autonomous, AI-driven cybersecurity platforms like SentinelOne for all-around protection. Whether the code in your network is open source or proprietary, learn how SentielOne’s Singularity™ XDR defends across all possible attack surfaces by contacting us today or booking a demo.