How industry leaders should approach open-source security

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.

To read the complete article, visit Dark Reading.