Open source dependency best practices for developers

Open source software is everywhere. No matter the industry, every business relies on software to meet their business needs. And the majority of applications that organizations build and use contain open source elements in their code. As industries migrate to cloud-native applications, and as applications grow in complexity, software security risk grows as well. Organizations need to implement open source dependency best practices throughout their software development life cycle (SLDC), and select the correct tools to manage their open source risk. Training developers in open source security and implementing a powerful software composition analysis (SCA) tool are both crucial steps to securing code from open source software risks.

Software risk is real: the 2022 OSSRA report

The OSSRA report offers a few key points about the wide adoption of open source software and the security risks it poses. The report investigated 17 industry sectors, four of which—computer hardware and semiconductors, cybersecurity, energy and clean tech, and Internet of Things—contained open source in 100% of their audited codebases. The remaining verticals had open source in 93% to 99% of their codebases.

The report noted that although license conflicts were down—they were found in 53% of codebases as compared to 65% in 2020—there was an increase in instances of unexamined dependencies. That is, when developers introduce open source dependencies, they’re often unaware of subdependencies containing license terms and conditions. For example, some versions of the popular node.js component include a dependency that leverages code licensed under the CC-SA 3 license, which might place undesirable requirements on the licensee and require legal evaluation for possible IP issues.

While the decreases in license conflicts and high-risk vulnerabilities are encouraging, the fact remains that more than half of the codebases audited contained license conflicts, and nearly half contained high-risk vulnerabilities. Even more troubling, of the 2,097 audited codebases that also had risk assessments performed, 88% contained outdated versions of open source components. That is, an update or patch was available but not applied.

There are justifiable reasons for not keeping software up-to-date, but unless an organization keeps an accurate and up-to-date inventory of the open source used in its code, an unupdated component can be forgotten until it becomes vulnerable to a high-risk exploit.

That’s precisely what occurred with Log4j. While the exploit itself was a danger, the panic and churn that ensued when organizations tried to fix it was largely caused by organizations not knowing where Log4j was located in their systems and applications. Many organizations had to scramble to see if it was there at all.

Establish open source dependency best practices before a crisis

Establishing a comprehensive open source software management program in an organization can be daunting, but there are a few best practices that can help you get started.

To avoid scrambling when a zero-day vulnerability is announced, and to protect your organization’s resources and data, you need to establish software governance. This includes defining a strategy, setting up an approval process, and doing a thorough software audit for existing open source software dependencies.

1. Define a strategy

Building an open source policy for your organization minimizes the legal, technical, and business risks of using open source software. An open source software policy and governance program can focus both on using open source code in the development process and using open source software internally, for example, to facilitate IT operations and support. Some organizations even build an open source program office to manage anything related to open source software.

The first step to creating a policy for open source is to identify your key stakeholders. These range from those who will be affected by the policy, such developers whose work will be directly affected, to C-level executives who have to approve the policy and bear the risks of using open source software. Stakeholders also include IT staff, managers of teams that use open source software, legal experts that advise on open source license compliance, and software architects. All key stakeholders should be involved as early as possible in the process.

Your strategic policy should outline your organization’s goals for incorporating open source software, identify how much open source software you currently use, and define your target usage of open source. The policy should also define which open source licenses are covered and how open source software usage differs for internal development and software that is shipped. You’ll want to establish a sourcing and selection process for open source software. Ideally, such a process explicitly states the approved websites, repositories, and methods to obtain open source software, and how to decide whether a particular package is right for the job. It should also specify who can download open source software, where from, and whether permission is required before downloading, using, or distributing it.

2. Establish an approval process

You should also establish an approval process to determine whether a software package meets the needs and quality standards of your organization. Some criteria to consider include code quality, level of support, project maturity, contributor reputation, and vulnerability trends.

An approval process that takes these criteria into account will protect teams from winding up with different versions of the same software package scattered throughout your organization’s code, each of which may or may not have been patched and upgraded appropriately.

If an approval process is to work, it needs quick turnaround on requests. Establishing a preapproved open source list can help with this process.

3. Create an audit process to detect open source software

In addition to ensuring compliance with internal policies, an audit provides a full picture of what open source software you are using. This will help you identify and locate components, which is vital to maintaining open source license compliance and when there is a vulnerability disclosure.

You should perform open source scans throughout the software development life cycle (SDLC), but you should ensure that a final scan is done every time an application is built into a release candidate that utilizes open source software, especially if you rely on components from third parties.

In order to pinpoint vulnerable components in your applications, you have to first identify ALL the open source components in your applications. Doing so requires that you consider all versions and forks of the code, detect components in source and binary form, analyze commercial software where open source is frequently embedded, and look beyond what has been declared in package managers. Automating this task saves teams from having to keep manual—and often inaccurate—inventories of open source. It also makes it possible to very quickly pinpoint vulnerable components and know immediately when new vulnerabilities are reported. This full inventory is the first step because if you don’t know you have it, you can’t make sure you patch it.

After an audit, you will be able to create a list of tasks and a corresponding plan to help close any gaps and achieve compliance. Such tasks may include providing or having available the source code, including required notices in your code or documentation, and updating your end user license agreement. In cases where compliance is not feasible, you will have to look for alternatives, for example, different libraries.