Enterprise Open Source Governance and Scanning Tool

Need for an Open Source Scanning tool and the RFP template to select the most effective tool

In the previous article (link), we discussed ‘what is Open Source Software (OSS)?’, ‘why it is important for your enterprise?’, and ‘what are the operational risks posed by OSS?’

By this point, you have hopefully started using OSS extensively in your enterprises, and we will focus on the steps needed to effectively manage OSS, including setting up of an Open Source Program Office / Open Source Review Board (OSRB), Governance Framework and Scanning Tool.

Open Source Program Office (OSPO)

OSPO is the “central place where all open source activities are handled for consistent communication inside/outside the company.” — HP Open Source Governance (link).

It is an interdisciplinary team involving IT, Legal and Procurement with the following scope:

  • Drive vision and support for Enterprise OSS adoption.
  • Define and evolve the OSS Governance / Compliance framework.
  • Maintain inventory of pre-approved OSS tools and components.
  • Review and approve (or deny) new OSS tools and licenses.
  • Provide internal support on OSS usage and implementation projects.
  • Develop OSS Competency by evangelizing OSS capabilities and providing Compliance education.

Governance Framework

Image for post
Image for post

Once the OSPO / OSRB has been setup, you need to develop a Governance Framework for your enterprise.

“Open source governance is a framework of policies, processes and tools that helps an organization effectively manage all of its interactions with open source software resulting in optimal use and reduced risk.” — HP Open Source Governance (link).

An effective Open Source Governance framework should be concise (10–15 pages) and address at least the following points: License Management, Security Vulnerabilities Remediation and Operational Readiness guideline for Product / Development teams.

License Management

There are more than 300 OSS licenses, and growing. However, many studies have shown that around 20 licenses account for 80% of the OSS commonly used in enterprises. A practical way to address this is to start with a Blacklist / Whitelist classification of the licenses corresponding to the OSS used in your enterprise. This serves as an easy to use reference, and we have seen very good adoption of such classification lists in enterprises.

The below table shows an example of a license classification list used at a Fortune 500 company (say X).

Image for post
Image for post

*The Open Source Initiative defines distribution (link) as follows:

“… to “distribute” a program means to give someone else a copy of its code — either its source code, or its binary (executable) code, or both. Merely allowing people to invoke a program on your server, for example via networked API calls, does not constitute distribution of the program as generally understood.

Ultimately the meaning of ‘distribution’ is determined through a combination of applying (i) local copyright laws; and (ii) the terms of the of the applicable Open Source Software license.

For the purpose of understanding the above table and determining when OSRB approval is required, we regard Distribution as any of:

  • The provision of Open Source Software licensed code (whether in source code or object code form) to any organization that is not part of X group of companies;
  • The provision of Open Source Software licensed code (whether in source code or object code form) to any customer or LAS; or
  • The uploading of Open Source Software licensed code (whether in source code or object code form) to any publicly available web site, database (including publicly accessible source code repositories) or app store, or otherwise making available to the public.

Examples: posting a download link to software on a website, embedding firmware in devices, rolling out a mobile app, contributing to a public Open Source Software project, uploading to a public source code repository (e.g. Github), providing Open Source Software to a third party supplier (e.g. an outsourcing partner).

**We do not regard Distribution as occurring where:

  • The provision of Open Source Software licensed code (whether in source code or object code form) is solely within X group of companies (internal use); or
  • Open Source Software licensed code is used by enterprise X on a server to provide a service over a network (including the internet) to third parties external to X, where a copy of the Open Source Software licensed code (whether in source code or object code form) is not provided or made available to those third parties [1]. ( This is known as the ‘ASP Loophole’. The Affero GPL licence is deliberately drafted to regard this as distribution, which is why this licence is blacklisted in the above table.)

Code libraries with an Allowed license tend to gain popularity since they are easier to use. Code libraries with a Restricted license (e.g. statically linked LGPL, or any GPL software regardless of linking dynamically or statically) may sometimes be found as a part of SDKs. Such Restricted software should be avoided even for Internal Use (and replaced with an Allowed alternative) if the library must also be copied for your application to work at run-time. A failure to at least clearly identify such usage of Restricted software could create a risk of a license compliance issue if ever in the future the software were Distributed externally (potentially by someone who is not the original developer of the application).

***The main difference between GPL and LGPL is the latter allows the work to be linked with a non-(L)GPL program, regardless of whether it is free or proprietary software (link). Apps which link to LGPL libraries need not be released under the LGPL, but must allow new versions of the library to be linked with the app; and allow reverse engineering to debug this. If you distribute a library having an LGPL license with your app, you need to include source code for the library. If your app instead requires users to obtain the library on their own (with the option to replace it with an alternative), then you do not need to provide source code for the library (link). Most vendors are normally providing a list of links from which to download all the required dependencies as well as specifying which licenses apply. If any of the licenses can be found in the Restricted list, this should be a red flag for the Product Teams to clear before using such software.

****The GNU Affero General Public License (AGPL) is the GPL for the web, which extends beyond X’s definition of Distribution to include “public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.” (link)The OSRB has decided the risk of license compliance issues even from simple usage of unmodified AGPL software outweighs the benefits, and therefore use of AGPL-licensed software is banned at X. Some vendors offer an alternative with a commercial license including paid support.

Common use cases where the use of a Restricted license may be appropriate:

  • Publishing source code developed by X to an external repository where all the application code must be available for the public to download, inspect, run, and modify, as a prerequisite for publishing a related article in a peer-reviewed scientific journal.
  • Contributing to public software projects that were released with a Restricted license.
  • There are no equivalent or better alternatives with an Allowed (or a commercial) license.
  • It will never be externally Distributed therefore obligations to share source code will not be triggered.

If you are unsure whether a particular use case for Open Source Software does or doesn’t involve Distribution, please contact the OSRB for guidance. You can use the decision tree below while evaluating a new OSS component based on the above license classification table:

Image for post
Image for post

Security Risk Management

The second important aspect of the Open Source Governance Framework is a structured approach to identifying and remediating security vulnerabilities in 3rd party OSS. Priority must be given to remediate any Open Source Software vulnerability that allows access to confidential or more specifically consumer / end user identifiable information, malicious performance degrading code, etc. Product teams must:

  • track and manage OSS security vulnerabilities.
  • be able to identify all 3rd party OSS components and packages in their source code.
  • be able to track and report on Mean Time to Fix (MTTF) from identifying a security vulnerability in their source code.

OSS Scanning Tool

Product / Development teams must take steps to ensure that they are in full compliance with the license terms and security obligations of all 3rd party OSS components used in software development.

  • Licensing obligations: Every file containing source code must include copyright, attribution and license information in line with the obligations of the license of the software being used.
  • BoM: Development Teams must produce a Bill of Materials (BoM) for every software release: Itemized list of all of 3rd party and proprietary components included in the software, the license type, versions number and a security vulnerability report.
  • Continuous Compliance: Integrate a continuous compliance process into their DevOps processes.
Image for post
Image for post
OSS Scanning Tool Rollout

The goal of an OSS Scanning Tool is to automate the above OSS Governance / Compliance process.

It should provide at least the following capabilities:

  • Inventory: Output an inventory (BoM) of OSS components in your code.
  • License and Security risk management
  • Software Development Lifecycle (SDLC) integration: In today’s world, the only way such a scanning tool gets used effectively is for it to be integrated in the DevOps pipeline — so this support is a key feature.
  • Reports and Auditing: Ability to define polices and design reports; provide reports to track policy violations and remediation progress.
Image for post
Image for post

There are a number of commercial and open source code scanning tools for identifying 3rd party OSS components and their attributes that can integrate with DevOps tools such as Jenkins, Artifactory and Maven. Here is the link to an OSS Scanning Tool Questionnaire that can be used for RFPs — to assess and benchmark the capabilities of OSS Scanning tools.

RFP Questionnaire xls: (link)

To conclude, we hope that this gives you some starting points to fast-track OSS adoption at your enterprise, and move higher up in the OSS value chain to (finally) become an OSS Community Leader.

Image for post
Image for post
Source: Source: BearingPoint and Black Duck Study on Open Source Maturity

Written by

AI and Open Source Architect | Ex-Nokia, SAP, Oracle | 50+ Patents | https://www.linkedin.com/in/debmalya-biswas-3975261/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store