Open source software (OSS) is a critical component of modern software development. It allows developers to leverage existing code, reduce development time, and focus on building new features.
However, OSS also introduces security risks. Vulnerabilities in OSS components can expose organisations to cyber threats, data breaches, and financial losses. To mitigate these risks, organisations must adopt best practices for managing the security risks associated with OSS.
In this blog post, we explore best practices for managing the security risks associated with OSS.
We review the literature, conduct interviews with industry experts, and analyse case studies to identify key strategies for securing OSS components. Our research highlights the importance of regular vulnerability assessments, tooling, continuous monitoring, binary repositories, risk management and mitigation, static application security testing, and forking as essential practices for managing the security risks associated with OSS.
Regular vulnerability assessments
Regular vulnerability assessments identify, prioritise, and apply patches to systems and software to address vulnerabilities. As the OSS landscape constantly evolves, organisations encounter thousands of new vulnerabilities. Yet, many businesses do not have a robust patch management strategy in place and fail to implement critical patches promptly, leaving them vulnerable to security breaches (Hackerone, 2024).
With an estimated 84% of open source components having at least one vulnerability (Sawers, 2021), regular vulnerability assessments are essential for managing the security risks associated with OSS.
A rough overview of the process is as follows (Hackerone, 2024):
- Initial Preparation – Defining the scope and goals of the vulnerability testing to ensure a targeted and practical assessment.
- Vulnerability Testing – Running automated tests to identify vulnerabilities within the systems included in the predefined scope.
- Prioritise Vulnerabilities – Assessing which vulnerabilities are most critical, requiring immediate attention, and evaluating their potential business impact.
- Create Vulnerability Assessment Report – Produce a detailed report outlining medium and high-priority vulnerabilities found and recommended remediation strategies.
- Continuous Vulnerability Assessment – Conducting scans for vulnerabilities on a continuous basis to verify if previous vulnerabilities have been effectively remediated and to discover new ones.
Regular vulnerability assessments are frequently mentioned in the best practices for managing the security risks associated with OSS. Without automated vulnerability assessments, it is difficult to keep up with the large number of OSS components used in modern software systems and the many vulnerabilities discovered each year. Therefore, with automation, regular vulnerability assessments are a best practice for managing the security risks associated with OSS.
Tooling
Tooling is the functionality that allows for automating the management of OSS components. It can be very useful as a way to manage the large number of OSS components used in modern software systems without introducing unnecessary manual work. Any software project that actively works to reduce security vulnerabilities is less risky. Therefore, tools that aid in identifying security vulnerabilities within software projects are critical (Department of Defense, 2022).
There are three tools found from our literature review that are considered “leaders”; Snyk, Sonatype, and Synopsys (Black Duck) (Worthington et al., 2023). These tools are designed to help organisations manage the security risks associated with OSS. They can be used to automate vulnerability assessments, manage licensing, enforce an OSS policy, and generate SBOMs. With this in mind, due to the diversity of OSS components, there is no one-size-fits-all solution (Wen et al., 2019).
We consider tooling to be a best practice for managing the security risks associated with OSS. It enables organisations of all sizes to manage many OSS components used in modern software systems without introducing unnecessary manual work. There is a lot of research into tooling, and a wide range of tools are available. We found that many tool-promoting papers and articles are written by the companies that produce the tools, so it is down to the organisation to evaluate the tools and decide which one is best for them.
Continuous monitoring
Modern software applications are built using a complex web of dependencies, including open-source libraries and frameworks. This process is typically recursive, with each dependency having its dependencies, and so on (Dietrich et al., 2023). Infamously, this web of dependencies can lead to security vulnerabilities, as seen in the equifax data breach (Fruhlinger, 2020) and the log4j vulnerability (Gallo, 2022).
Continuous monitoring is the process of monitoring OSS components for vulnerabilities and other security risks on an ongoing basis. These can be manual but are often automated and part of an organisation’s CI/CD pipeline. It is crucial for application developers to detect dependencies on vulnerable libraries as soon as possible, to assess their impact precisely, and to mitigate any potential risk (Ponta et al., 2020).
Now more than ever, developers are using automation to secure their dependencies; in 2023, developers merged 60% more pull requests from GitHub’s Dependabot, a tool that automates dependency updates, than in 2022 (Daigle, 2023).
Software composition analysis (SCA) can be used to conduct regular vulnerability assessments, can be implemented as part of the continuous integration/continuous deployment (CI/CD) pipeline, and can be used to enforce an OSS policy (Alvarenga, 2023a). SCAs will provide an inventory of all open-source components used in a project, including their versions and licenses, and will also identify any known vulnerabilities in these components; effectively, producing an SBOM (Alvarenga, 2023a).
Due to the dynamic nature of the open-source ecosystem, continuous monitoring is essential for managing the security risks associated with OSS. An SCA is a great way to monitor OSS components continuously and can be implemented as part of the CI/CD pipeline and can be used to enforce an OSS policy. It is a best practice for managing the security risks associated with OSS.
Binary repositories
A binary repository manager is a tool designed to store and manage binary files (the compiled version of your source code) and their metadata. Some popular binary repository managers include JFrog Artifactory, Sonatype Nexus Repository, and GitHub Packages.
A binary repository manager is indispensable for managing open-source components effectively. It facilitates the caching of local copies of these elements, ensuring that frequently used packages remain accessible even during downtimes of external repositories. This capability is essential for maintaining continuous project development and operations without interruptions.
Moreover, such a tool distinguishes between approved third-party artefacts and those pending approval, significantly improving the management and visibility of open-source components within projects. It also allows access to specific libraries to be excluded and limited, thereby safeguarding projects from incorporating non-compliant artefacts (Wainstein, 2018).
By caching versions of all open-source software components, you also safeguard against incidents like the left-pad debacle, where the withdrawal of a minor package from the npm package manager (a package manager for the JavaScript programming language) resulted in widespread failure in numerous projects (Williams, 2016).
There is a licensing concern, specifically with GPL-licensed open-source software. The GPL license requires that any software distributed that includes or is derived from GPL-licensed code must itself be available under the GPL. If a binary repository contains GPL software and is shared externally, the entire repository may need to be open-sourced. For example, Microsoft released Hyper-V drivers with GPL-licensed binaries, leading to Microsoft having to open-source the drivers in question (Linux Network Plumber, 2009).
Binary repositories appear to be a polarising issue in the literature. The Department of Defense, 2022 recommended binary repositories as a best practice for managing the security risks associated with OSS, whereas Anand, 2023 (Salesforce) mentioned securing a repository as a best practice, but didn’t mention binary repositories specifically.
Risk management and mitigation
Risk management and mitigation is the process of identifying, assessing, and prioritising risks, and then taking steps to reduce or eliminate them.
According to the Open Worldwide Application Security Project (OWASP), the most significant risk associated with open source software is “Vulnerable and Outdated Components” and has moved from 9th to the 6th most critical risk to web applications (OWASP, 2020).
OSS vulnerabilities grew by 50% year-on-year — from just over 4,000 in 2018 to over 6,000 in 2019 (Zorz, 2020).
One reason for the increase in vulnerabilities is the growing number of open source components being used in software projects from developers utilising the speed and convenience of open source, especially under time pressure, without considering the security implications. This highlights the need for formal processes to manage the risks. Typically, these correlated to implementing some continuous monitoring and regular vulnerability assessments, as outlined in Section 4.2.1 and 4.2.3 (Anand, 2023, Chandler et al., 2022, Mathpati, 2023). Such efforts should avoid being overly laborious and manual to ensure they do not frustrate developers and slow down the development process (Contrast Security, 2020).
Like those outlined in this report, the most effective way to mitigate OSS risks is to follow best practices (Chandler et al., 2022).
Interestingly, our interviews and case studies found that the approach to risk and risk mitigation varied from organisation to organisation. Larger organisations seemed more proactive in mitigating risk, with dedicated teams and processes in place. Whereas smaller organisations were more reactive, only taking action when a risk materialised and looking to improve their processes after the event. This suggests there is a gap in the best practices landscape, as it doesn’t consider the different approaches to risk management and mitigation based on the size of the organisation.
Static application security testing
Static application security testing (SAST) is a method of testing the security of an application by examining its source code, byte code, or binary code for security vulnerabilities.
Frequent scanning and security assessment of your repository aids in detecting security concerns at early stages, minimising the chance of significant security problems developing later on. Static code analysis tools can pinpoint typical security weaknesses, and dependency vulnerability scanners can highlight any recognised problems in your project’s dependencies (Anand, 2023). SAST goes hand in hand with the continuous monitoring of OSS components, as it allows for detecting vulnerabilities in OSS components as soon as possible, allowing for their impact to be assessed and mitigated, see Section 4.2.3.
From our research, SAST is only suggested by Salesforce as a best practice. However, current tooling is comprehensive and can be used to automate the continuous monitoring of OSS components, as outlined in Section 4.2.2. Therefore, SAST can be considered a technical implementation of continuous monitoring.
Forking
Forking is the process of creating a new project based on an existing project. It allows you to monitor alterations in open-source components, as there will always be a connection to the original repository. One of the key advantages mentioned in the definition of open-source is the explicit permission granted to duplicate and independently alter the source code of an open-source project as desired (The Open Source Definition 2024).
However, it’s important to be mindful that opting to create a private fork entails the responsibility of integrating any updates from the upstream version of the component. This responsibility grows as the differences between the forked components and the original increase. An ideal situation for forking is when you take an open-source component from a project that is unlikely to receive many updates in the future (Wainstein, 2018).
The process often includes creating a distinct OSS developer community (OSS-DC) for the forked version, allowing the organisation to focus on modifying or enhancing specific components of the software—usually those deemed critical for their purposes (Méndez-Tapia et al., 2021).
Forking does get mentioned in varying mediums as a best practice. However, the added responsibility of integrating updates from the upstream version of the component is often overlooked, and from our interviews, we found that forking is not widely used in practice.
Conclusion
In this blog post, we explored best practices for managing the security risks associated with open-source software. We reviewed the literature, conducted interviews with industry experts, and analysed case studies to identify key strategies for securing OSS components.
Our research highlights the importance of regular vulnerability assessments, tooling, continuous monitoring, binary repositories, risk management and mitigation, static application security testing, and forking as essential practices for managing the security risks associated with OSS.
By adopting these best practices, organisations can reduce the likelihood of security breaches, data loss, and financial losses associated with OSS vulnerabilities. We recommend that organisations implement these practices to enhance the security of their software systems and protect their data and assets.
