Five steps to managing Open Source Software vulnerability and license management

Third-party security and compliance risk is reaching epidemic proportions – threatening the very integrity of the software supply chain.  Think Heartbleed!

Today, in many organisations, there is more open source than homegrown or proprietary code in a company’s product.  Unfortunately, most companies, while taking advantage of Open Source Software (OSS) in order to create products faster, are not respecting the open source licenses associated with the software components they use.  While OSS is free of cost, it is not free of obligations.  These obligations run the gamut from passing along a copyright statement or a copy of license text, to providing the entire source code for the company’s product.  Data shows that most companies are aware of only a small percentage of the open source they depend on.  By not knowing what you are using, it is impossible to comply with the obligations specified in the license.  Additionally, software can have bugs or vulnerabilities which may affect your product.  By not keeping track of what you are using, it can make it possible to be far behind on upgrades or patches that fix known software vulnerabilities.

However, there is great value in open source.  

Discovering, Managing and Complying in Five Steps

Once the issue of OSS compliance or vulnerability management comes up, the first question is often “What can I do to get a handle on what open source components are we using?”

There are five steps that can help you understand what your company is doing and set up a process for discovering, managing and complying with the OSS you are depending on.

Step 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 and 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 organisation.  It is very common today that developers will be using what is known as a Repository Manager.  These tools allow developers to specify the components that they want to use, and then the Repository Manager will be responsible for downloading the source code, or compiled binary file as well as any dependencies that this component may have.  These 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 organisation 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.

Step 2:  Start looking for OSS

Once you know the way that open source is selected and used, you can start performing an assessment of what components you depend on and how they are being used or distributed.  This is typically known as building your Bill of Materials (BOM), or creating your open source disclosure list.  This list is used to follow the obligations, modify OSS policy and react to published vulnerabilities.  It is common to find open source packages that have licensing obligations that your organisation is not 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.

Step 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 personal 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.

Step 4: Understand how incoming OSS is managed

There should be a consistent and enforced process for managing your third-party usage.  This allows your organisation to properly comply with open source license obligations, and well as be able to react to new vulnerabilities.  It is common to have teams with varying level of completeness and compliance.  Some organisations 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 is important to understand the level of analysis performed, and what should be expected to be found.  It is common to come into compliance in phases as more components are discovered and managed.

Step 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 following these five steps, educating your company about proper OSS usage and encouraging others in your ecosystem to do the same, you will be able to use open source to create powerful modern applications, while at the same time, respecting the open source licenses and organisations that make this possible.  Additionally, the more you know about how your product is assembled, the third-party pieces that compose it and the current vulnerability status of them, the more secure and supportable your product is.