By Jeff Luszcz, Vice President of Product Management at Flexera Software
If Heartbleed has taught us anything, it’s that third-party security and compliance risks are dangerously threatening the integrity of the softwaresupply chain.
As you may know, the majority of organizations use more open source code in their products than code they’ve written themselves, which expedites the product creation process. The problem with this is that many companies, when using open source software (OSS), do so with no regard for the licenses associated with the code they use. Because OSS is free to use, many companies misunderstand that they still need to respect the legalities associated with its licensing, such as passing along a copyright statement or a copy of license text, or providing the entire source code for the company’s product.
Often, enterprises are largely unaware of the percentage of OSS their products depend on, and it’s impossible for them to be aware of the legal responsibilities associated with the code they don’t know they’re using. Software vulnerabilities could also negatively affect your product, and lacking awareness about what open source code you’re using will put you behind the curve on upgrades or patches for known software bugs, as anyone impacted by the recent WannaCry attack can attest to.
That said, there’s amazing value in OSS. You just need to know how to comply.
Discovering, Managing and Complying in Five Actions
Once you know the risks associated, you need to figure out how to get a handle on the open source components your company is using. There are five key actions that can help you understand what your company is doing and set up a process for discovering, managing and complying with the OSS it uses.
1.Understand how OSS enters your company
There are many ways that open source enters your company. The classic case is that a developer decides to use an open source component, downloads the source code and incorporates that source code into their product. This is still a very common case, but there are many other ways that open source ends up being used in an organization. Often, developers will use what is known as a Repository Manager. This allows developers to specify the components that they want to use and download the source code, or compiled binary file, as well as any dependencies that this component may have. Repository Managers typically store the open source components in a separate repository outside of your classic source code management system. Some common Repository Managers are Maven, Nuget or npm.
Another way that open source comes into an organization is as a subcomponent of a commercial or larger open source component. It is very common to have multiple open source subcomponents or dependencies for a single, top-level component. These subcomponents are often not disclosed or managed.
Additionally open source will be used as runtime infrastructure pieces such as Web servers, operating systems or databases.
All of these components may be pulled in by developers, graphic designers, procurement, professional services, IT administrators and many others. This is no longer only a developer-based process.
2.Start looking for OSS
Once you know the ways that open source is selected and used, you can start performing an assessment of what components you depend on and how they are being utilized or distributed. This is typically known as building your Bill of Materials (BOM), essentially your open sourcedisclosure list. This list is used to follow the obligations, modify OSS policy and react to published vulnerabilities. It is common to find opensource packages that have licensing obligations that your organization isn’t able to follow. This puts you out of compliance with the license. In these cases, the open source component needs to be removed and the functionality replaced either through the use of another OSS component or by writing equivalent functionality.
Codebase reviews, interviews and scanning tools can be helpful during this process.
3.Question your development team
As projects get larger, more complex and more distributed, it has become harder to discover all of the pieces that are in use. This makes it important to have periodic conversations with the developers, devops and IT personnel involved with the creation, deployment and running of the project in question. Asking targeted question such as “What database do we use?” or “What encryption libraries do we use?” can be helpful in discovering other modules that may have been missed the first time.
Simply asking “What open source are we using” rarely creates a complete list for a few reasons, including that the knowledge of what OSS components were selected often has disappeared from memory or the company. There is also a misunderstanding or lack of knowledge among many developers about what is considered open source.
4.Understand how incoming OSS is managed
There should be a consistent and enforced process for managing your third-party usage. This allows your organization to properly comply with open source license obligations, as well as be able to react to new vulnerabilities. It is common to have teams with varying level of completeness and compliance. Some organizations are currently only tracking components that have been “Requested” by developers. These types of companies find that they are often only tracking the larger pieces of open source, or have some developers who are better than others in following the process.
Other companies use scanning technology to help discover and track OSS. Depending on the scanner used, or the level of analyses performed, varying degrees of discovery will be found. Some tools only discover license text, not actual OSS components. Others can find components managed by package managers but can’t find anything else. It’s important to understand the level of analysis performed, and what should be expected to be found. It’s common to come into compliance in phases as more components are discovered and managed.
5.Look for evidence of OSS compliance
Once you create policies, start looking and managing OSS, and requiring compliance with the OSS obligations it is important to confirm that this compliance is visible. Do you see the required attributions or copyright notices in the product or documentation? Do you see the license text as required? Is there a written offer for source code or the actual source code distributions for any Copyleft-style licensed content you may be using? These are all visible indicators of an effective open source management process.
By going through these five actions, in addition to educating your company on how to use OSS correctly and encouraging other enterprises to do the same, you’ll be able to integrate OSS into your applications while respecting licensing agreements. Not only will this keep you more informed and aware of the code in your products; it also creates a more secure product for your customers.
