4. Tools

1. Source Code Scanning Tools

In the open source identification and inspection stages of the open source process, you can use source code scanning tools. These tools range from open source-based tools that can be used for free to commercial tools. Each tool has its strengths, but no tool provides a perfect solution to all problems. Therefore, companies should select the appropriate tool that fits the characteristics and requirements of their products.

Many companies use these automated source code scanning tools in conjunction with manual reviews. The Linux Foundation’s FOSSology project is an open source source code scanning tool that companies can easily use for free.

https://www.fossology.org/

For information on how to install and use FOSSology, please refer to Get Started with FOSSology.

2. Dependency Analysis Tools

In recent software development, build environments that support package managers such as Gradle and Maven are used. In these build environments, even without source code, the necessary Dependency libraries are fetched from a remote space at build time to compose the distribution software. However, these Dependency libraries are included in the distribution software but are not detected by the source code scanning tools. Therefore, it is also important to use tools for Dependency analysis.

The OSS Review Toolkit, which is open source, provides a Dependency analysis tool called Analyzer.

https://github.com/oss-review-toolkit/ort#analyzer

In addition, LG Electronics has released the FOSSLight Dependency Scanner as open source. The FOSSLight Dependency Scanner supports various package managers such as Gradle, Maven, NPM, PIP, Pub, and Cocoapods.

https://fosslight.org/ko/scanner/

3. SBOM Management Tools

ISO/IEC 5230 standard 3.3.1.2 requires that the SBOM list included in the distribution software be documented and stored.

SBOM can be managed with spreadsheet programs like Excel, but it is not easy to manage manually when the number and version of distribution software exceed hundreds. Therefore, it is recommended to introduce open source automation tools for this purpose.

The SW360 project, sponsored by the Eclipse Foundation, provides the ability to track the list of open sources included in each distribution software.

The installation and usage of SW360 can be referred to in the SW360 Docker.

And the aforementioned FOSSLight also provides features for SBOM management.

https://fosslight.org/fosslight-guide/started/2_try/4_project.html

LG Electronics has been managing the SBOM for all business units' distribution software for the past several years using FOSSLight, which it developed in-house. In June 2021, it announced that it had released it as open source so that anyone can use it.

https://fosslight.org/

4. Open Source Vulnerability Management Tools

Companies need to track products/services that contain known vulnerabilities and resolve them. To do this, companies need to build a tool environment that automates this.

SW360 can automatically check if there are any security vulnerabilities in the registered Release. For this, SW360 provides a feature to schedule the collection of CVE information every 24 hours. If you set up this scheduling, SW360 will collect CVE information from the CVE Search site (https://cve.circl.lu/) at the set time. After the Vulnerabilities information is collected, you can check if there are any security vulnerabilities in the created Project, so you can also track whether newly disclosed vulnerabilities exist in products that have already been released.

The method of managing security vulnerabilities with SW360 can be referred to in the SW360 guide.

FOSSLight also automatically acquires security vulnerability information and automatically checks project information where security vulnerabilities have been detected, providing notifications such as emails as needed.

5. Open Source Compliance Artifact Generation Tool

The main open source compliance artifact, the open source notice, is a document that provides copyright and license information for the open source included in the distributed software. Open source notices can be created using a document editor tool, but it is recommended to use a tool that generates them automatically.

SK Telecom has released an open source notice automatic generation tool (onot: https://github.com/sktelecom/onot) used internally as open source, and Kakao has participated in joint development by contributing major features.

onot installation method

onot is a tool that automatically converts SBOMs written in SPDX document format into open source notice format. It is a Python program that is lightweight and easy to use.

onot generated open source notice sample

FOSSLight also provides a feature to automatically generate open source notices based on the acquired SBOM.

https://fosslight.org/fosslight-guide/started/2_try/4_project.html

6. Open Source Compliance Artifact Storage

It is recommended that companies build an open source website and register open source compliance artifacts so that external customers can conveniently download open source notices and source code packages to be disclosed for distributed software at any time.

For this, the ISO/IEC 5230 standard requires a documented procedure for archiving copies of the compliance artifacts of the supplied software.

You can refer to this tool environment on SK Telecom’s open source website.

https://sktelecom.github.io/compliance/

This website was developed as open source, and the source code is open, so other companies can easily build a similar environment.

https://github.com/sktelecom/sktelecom.github.io

7. Summary

If you build up to the tool environment, you can meet the requirements marked in green in the ISO standard specification.


Last modified November 29, 2023: update English guide (ffabfdaf)