Open source software is everywhere. No matter the industry, every business relies on software to meet their business needs. And most 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.
Firms 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 robust software composition analysis (SCA) tool are crucial steps to securing code from open source software risks.
What is the landscape of open source software?
The 2022 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.
When developers introduce open source dependencies, they’re often unaware of sub-dependencies containing license terms. 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 and require legal evaluation for 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% of them 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 un-updated 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 firms tried to fix it was caused by firms not knowing where Log4j was located in the systems and apps. Many firms had to scramble to see if it was there at all.
How can organisations stay one-step ahead?
Use open source dependency best practices before a crisis. Establishing a comprehensive open source software management program in a firm can be daunting, but there are a few best practices that can help you. To avoid scrambling when a zero-day vulnerability is announced, and to protect your firm’s data, you need to establish software governance.
This in particular includes defining a strategy, setting up an approval process, and doing a thorough software audit for existing open source software dependencies.
Define a strategy
Building an open source policy for your firm 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 firms even build an open source program office to manage anything related to open source software.
First, create a policy for open source is to identify your key stakeholders. These range from those who will be affected, 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.
Establish an approval process
You should also establish an approval process to determine whether a software package meets the quality standards of your organization. Some criteria to consider include code quality, level of support, project maturity, contributor reputation, and vulnerability trends.
In addition, 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. And if an approval process is to essentially work, it needs quick turnaround on requests. Establishing a pre-approved open source list can help with this process.
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 locate components, which is vital to maintaining open source license compliance and when there is a vulnerability disclosure.
You should perform open source scans across the software development life cycle (SDLC), but also ensure that a final scan is done every time an app 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 apps, you have to first identify ALL the open source components in your apps. Doing so requires that you consider all versions of the code, detect components in source and binary form, analyze 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 to help close any gaps and achieve compliance. Such tasks include 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, such as different libraries.