close search bar

Sorry, not available in this language yet

close language selection
 

How to use FOSS management systems to manage FOSS components

FOSS management systems make it easy for you to track the licenses and vulnerabilities in the free and open source software components you use.

How to use FOSS management systems
In modern software development, the importance of using free and open source software (FOSS) components to build software products and systems isn’t debatable. Using FOSS components for commonly available functionalities such as logging (e.g., Log4j), text search (e.g., Apache Lucene), and secure communication (e.g., OpenSSL) has become an important factor to speed product time to market (TTM). Additionally, developers can reuse these high-quality functionalities to better concentrate on their products’ core functionalities.

Learn by example

Commitment to FOSS by software giants like Microsoft and Google emphasizes the importance of FOSS in developing software. Microsoft has already undertaken key FOSS projects (e.g., Visual Studio Code, TypeScript). With more than 16,000 contributors to open source software, Google also has key open source projects (e.g., its flagship machine learning library: TensorFlow).

Companies need to manage the use of FOSS components from the following aspects:

  • FOSS usage policy
  • FOSS component identification
  • License compliance
  • Security vulnerabilities
  • Auditing workflows
  • Integration with software development and production infrastructure and processes

FOSS management systems that are designed and developed by experts can ensure that these aspects are addressed properly. A comprehensive FOSS management solution helps customers handle the different aspects relating to FOSS component usage.

What are the different aspects relating to FOSS component usage, you ask?

FOSS usage policy management

Every company that uses FOSS components should have a FOSS usage policy. The policy should contain rules that govern different aspects of FOSS management, including:

  • Stakeholders that have a say in terms of developing and maintaining such policy (e.g., architects, FOSS managers, security specialists, development managers, the legal department)
  • The internal and external usage of FOSS components
  • FOSS licenses (e.g., MIT, GPL, etc.) that are compatible with the company’s business model
  • FOSS repositories in place to download FOSS components
  • Rules that govern the company’s contributions to the open source community

Reliable FOSS component detection and identification

Companies need a reliable way to identify FOSS components that are in use. There are four ways a FOSS component can be used in a company’s codebase:

  • A whole FOSS component in use within the codebase
  • Certain files of the FOSS component in use within the codebase
  • Code snippets from the FOSS component in use
  • A mix of the above

Identifying and managing these different types of usage can be a daunting and error-prone task if done manually. This is especially true when considering the complexity of modern software systems, and the ease of access to the vast pool of available FOSS components. Reliable FOSS management systems should be well-equipped with functionalities and algorithms to identify and detect FOSS components. This can save a company valuable efforts that can be otherwise used in developing their products.

Open source license compliance

Different FOSS components are associated with different types of open source licenses. These licenses have different legal obligations, depending on how the FOSS component is used by the company. For example:

  • Is the FOSS component in use internally only? Or, is it distributed with a product? If so, is it being distributed in binary or source format?
  • Is the FOSS in use as is? Or is it being modified?
  • Is it being linked statically or dynamically?

As an example, the GNU General Public License (GPL) mandates different obligations if the FOSS is distributed as part of the company’s product, as opposed to its use only internally. Also, customers using FOSS components with different open source licenses should make sure that such licenses are compatible. As an example, distributing products that contain code licensed under Mozilla Public License (MPL) and GPL will violate the terms of the licenses.

FOSS management systems are able to detect different open source licenses in use. They can also help customers identify license obligations based on the way these components are used. Additionally, they can provide input to help the legal team make decisions in terms of whether the use of a certain FOSS component is or isn’t allowed. This is based on the compatibility of license obligations with the company’s policies and business model.

Security vulnerabilities

Companies should make sure that their products don’t contain security vulnerabilities that could expose customers to security breaches. Like any other piece of software (open or closed), FOSS components are also vulnerable to security issues. Companies producing software need to be aware of vulnerabilities associated with FOSS components in use. Additionally, they should continuously monitor newly discovered vulnerabilities in these components, or known vulnerabilities that are fixed.

There are multiple platforms that collect and maintain databases of known FOSS components, such as the National Vulnerability Database. FOSS management systems harvest such databases, continuously monitor them, and provide timely information regarding the FOSS component vulnerabilities in their codebases.

Audit workflow

Software shops usually have multiple roles that are involved in auditing the usage of FOSS components (i.e., reviewing and approving/disapproving usage). Examples of such roles include:

  • Legal staff
  • Development managers
  • Security specialists
  • FOSS managers

Auditing can take place two ways:

  1. Proactive auditing takes place when a developer submits a request to grant approval for the use of a FOSS component. This request should include the FOSS details (e.g., name, version, license, URL, intended use of the component, etc.).
  2. Reactive auditing takes place when FOSS components are already in use within the codebase. The analysis aims to identify these components and additional information (e.g., licenses and vulnerabilities).

With both, multiple roles in the company could be responsible for auditing FOSS component usage. These roles include security specialists who check security vulnerabilities that could be relating to the component. It could also include legal staff who check the legal obligations of the component’s license.

FOSS management systems provides workflow engines that simplify the proactive and reactive auditing of FOSS components. A rich and efficient workflow provides and facilitates a smooth audit process. It allows:

  • The definition and configuration of multiple roles involved in auditing
  • Sequential or parallel approval workflows
  • Proper mail notifications for the different auditing parties
  • Audit trail for all activities taking place during the audit of FOSS components

Restful API

A FOSS management solution API allows:

  • Integration with other enterprise systems and applications (e.g., a dashboard that contains information involving detected security vulnerabilities).
  • Integration with build and development environment. Thus, enabling the activities around the audit of FOSS component usage at any stage of the development cycle.
  • Flexible and customized reporting built using data provided by the solution.

Black Duck Binary Analysis offers a comprehensive, reliable, and rich FOSS management solution that enables enterprises to efficiently manage FOSS component usage. For detecting and identifying FOSS components in codebases, Black Duck Binary Analysis uses a large reference database that currently contains over 4 million FOSS releases. These are also associated with over 700 thousand unique FOSS projects, and growing on a daily basis (with over 1 billion source files).

Major FOSS repositories are monitored on a 24/7 basis for new and popular content (e.g., GitHub, SourceForge, Maven, NuGet). This is so customers don’t miss out on FOSS components when auditing their codebases. Synopsys’ patented source file signature method allows Black Duck Binary Analysis to detect fully or partially used FOSS components. This is in addition to identifying code snippets that are reused from FOSS components.

Using its policy management capabilities, customers can identify their whitelisted and blacklisted licenses and copyrights.  Additionally, customers receive alerts for violations of these listed during their codebase analyses. Black Duck Binary Analysis includes a rich restful API that allows a current customer’s codebase to integrate with their build infrastructure. This also enables them to build customized reporting that augments the out-of-the-box reports provided by Black Duck Binary Analysis.

Summing it up

With the ever-growing usage of FOSS components in building software products, software shops find themselves needing to address all aspects relating to this usage. This includes:

  • Identifying FOSS and FOSS components
  • Establishing FOSS policy management
  • Understanding license and compliance measures
  • Examining exposure to security vulnerabilities
  • Integrating with software build infrastructure
  • Implementing clear reporting

Handling these aspects can also consume significant efforts if done manually. FOSS management systems are the natural solution. They can save time and effort, and reduce risks that may accompany such usage.

Feeling lost at sea? It’s time to understand your cyber supply chain.

We can help.

 
Hassib Khanafer

Posted by

Hassib Khanafer

Hassib Khanafer

Hassib Khanafer is a senior manager of Software Engineering within Synopsys' Software Integrity Group. He specializes in open source licenses, compliance, and security. Prior to joining Synopsys, Hassib was the Chief Technology Officer at Protecode, which was acquired by Synopsys in 2015.


More from Open source and software supply chain risks