Security has long been a point of concern in the open source community. If not managed carefully, the same openness that allows innovative code contributions from global users can also present vulnerable attack surfaces for malicious actors. In fact, when asked about roadblocks preventing their organizations' use of open source, respondents to Anaconda’s 2021 State of Data Science report cited "Fear of CVEs, potential exposures, or risks" (41%) and "Open source software is deemed insecure, so it's not allowed," (26%) among other concerns.

Yet open source drives innovation, and there are ways to dramatically decrease the potential risks that arise from the use of open source software. This is why many organizations take a “best of both worlds” approach, adopting open source while prioritizing security measures.

If you think of open source security as a spectrum, with “no security controls” on one end and “locked-down controls” on the other, technically advanced organizations tend to fall somewhere in the middle. Here are some lessons you can learn from their approaches.

1. Everyone Should Be Involved
Setting up open source security parameters should not be left solely up to the IT and data science teams. To be successful, you need buy-in from the whole organization, including executive leadership. Together, leaders must consider the tradeoffs of security risks and innovation rewards, and create a framework to define an acceptable level of risk for using open source software.

In creating security frameworks across organizations, preventative and containment-based perspectives are necessary. Since open source projects are open to globally dispersed contributors, the code doesn’t have the same level of built-in security as private vendor applications. For that reason, you need to have a proactive approach to security, setting clear risk parameters and pre-emptively implementing safeguards in the event of a breach. A key aspect of the latter component is the idea of a software bill of materials (SBOM), which lists the origin of all the code running in each application or package. With an SBOM in place, when an incident like last year’s Log4j incident occurs, you can quickly identify which areas of your infrastructure are impacted.

2. Take a Nuanced Approach
If the security framework is a hard-and-fast set of nonspecific rules, you’ll likely run into two problems. First, you risk security becoming an exercise of box-checking, where practitioners aren’t necessarily thinking critically about their actions and are just crossing items off a security checklist. Second, you’ll likely miss out on the best innovation open source has to offer.

Of course, there are a few areas where you want to be very firm in your security protocols, such as implementing access controls and firewalls and using only repositories that have been built on or are being mirrored from a secure environment.

However, there are other areas where you can introduce some nuance, such as parameters around acceptable CVE scores. For example, there are tens of thousands of open source packages in the Python realm alone. If you set automated filters that allow your data scientists to use only packages with a CVE score of 6 or lower, you could miss out on a package with key functionality that has a score of 7 but whose vulnerability would not be exposed in your particular use case.

Another approach is to establish different risk tolerance levels in development and production environments. This gives developers and data scientists more freedom to explore packages in the dev environment, which can be separated behind a firewall. Then, when it comes time to move workflows into production, you can enforce stricter security protocols. If a given package doesn’t meet those requirements, it’s an opportunity to explore whether to introduce more nuance into the rules.

3. Give Back to the Open Source Community
It might be tempting to think that forking an open source project and bringing the fork inhouse would help mitigate security issues by giving you tighter control over the code distribution. However, that path has several downsides, as noted in a recent memorandum from the Department of Defense. These include increased support risk (due to the loss of several pairs of eyes checking over code), decreased access to community-driven innovations, and increased code maintenance costs.

Instead of forking a project, many industry leaders work closely with the open source community to help surface, mitigate, and patch vulnerabilities when needed. Most projects rely on volunteer effort, and any resource contributions (including developer time, monetary support, and in-kind donations like server space) will benefit everyone who uses a project.

Conclusion
Security is a journey, and everyone progresses at a different pace. It’s important to implement systems and strategies that work for your industry, resource level, and expertise. At the same time, it’s worthwhile to continually refine your security posture and adopt more sophisticated practices. The cyber threat landscape is ever evolving, so it’s incumbent on us as technologists to evolve and adapt so that we can stay protected, secure, and one step ahead.