Managing 3rd Party Software Components with Software Bill of Materials

Abstract

One of the newest obstacles in the software security industry is the increasing number of encountered and exploited vulnerabilities. Vulnerabilities can be divided into two categories for a specific software: internal, which are found in the software's own code, and then external vulnerabilities which are caused by the 3rd-party-components used in the software. As the usage of 3rd-party-components has been growing lately, also the risk of having vulnerable components also has been rising. Now, there is also a rising trend with moving from proprietary external components to Open Source Software (OSS) solutions, which brings its own challenges. OSS may be convenient and cheap to use, but may cause problems with support, management, and especially security among other things. Security accidents in 3rd-party-components have become more of a common theme with the accidents such as Log4Shell and the likes. With the lack of security in some components and their increasing usage in even enterprise level software, cyber-attackers have become more active in focusing their attacks on these vulnerable components. Governmental legislation may lack behind as usual in fast-growing areas, but for example, the USA has taken the initiative in this field with EU following closely behind. As one of the solutions to this problem, the Software Bill of Materials (SBOM) was constructed, which aims to provide control and management on these external components. SBOM introduces common standards for processes and formats for handling the 3rd-party-component data and enabling its share across company borders. This thesis aims to learn about the SBOM and adapt it into a Proof-of-Concept (PoC) in an enterprise setting by following design science approach. The goal is to find the most suitable tool and process for SBOM generation, management, and analysis in M-Files Hubshare development environment.

Software Bill of Materials (SBOM) refers to a data record which contains the details and supply chain relationships of the components in a software. SBOM contains three main concepts known as the minimum elements. First comes the common practices and processes which define how the SBOM data record should be created, handled, consumed, and distributed to make it universally compatible and usable. Second are the data fields, which define the required information in the SBOM data record such as the SBOM data record's author, supplier, main component name, and the used external components. Third is the requirement for automation support to make the handling of SBOM data record faster, easier, and non-reliant on manual work that is prone to errors and delays. This gets us to the formats that are recognized as SBOM formats CycloneDX, SPDX, and SWID tags. Each format has its uses and tools for generating and analyzing them.

SBOM and SBOM tool requirements differ, for example, based on the company policies, development environments, and software languages. For this work the requirements were gathered in three parts. First general research was done to find out some common requirements or restrictions that should be kept in mind when thinking of a SBOM solution for a specific software. These can include things such as budget, general usability, programming language support, and both vulnerability and false positive vulnerability detection rates. For M-Files Hubshare, the requirements were divided into two categories, "Must have", are things that the tools must enable/have, and then "Good to have" which can be seen as bonuses outside the mandatory features. The "Must have" requirements mainly focus on scanning, storing, and analysis of the SBOM data and its components' vulnerabilities. Software development languages and frameworks also may limit possible tool list, which is C\# with NuGet package manager and TypeScript with NPM package manager. This means that the SBOM generation and analysis tool must be able to interpret these environments. "Good to have" requirements focus on extra functionalities that may be done with other tools and systems if the chosen main tool does not support them. These include things such as discovering and listing internal software projects from version control systems.

The tool testing was done in three different stages. First, an overall image and list of possible tools was gathered. The tools were divided based on their supported SBOM format and then their documentation and features were briefly evaluated against the requirements. Overall, SWID tools were the least prominent, while CycloneDX tools were the biggest group and had the many prominent tools. SPDX tool group was somewhere between SWID and CycloneDX tools with a couple of prominent tools. Three tools, two from CycloneDX and one from SPDX, were chosen for further testing where they were tested in a local environment against a simulated project similar to the one in M-Files Hubshare. The chosen tools were Dependency-Track for CycloneDX, FOSSLight for SPDX, and Open Source Review Toolkit (ORT) for CycloneDX/SPDX.

Of the three tools, Dependency-Track worked the best for SBOM management and analysis but didn't provide means to generate the SBOM data record itself. The SBOM generation would require another tool from the CycloneDX tool family. FOSSLight provided both the analysis and generation tools in one package but was difficult to learn and cumbersome to use. ORT managed to provide good scanners and generator for the SBOM but failed in to provide good means to analyze and manage the SBOM data records as it was mainly a command line interface tool. Both FOSSLight and ORT focused more on the open source compliance part with some vulnerability handling on the side while Dependency-Track focused on the vulnerability handling with some open source compliance on the side. The main focus of this work was to find a tool for handling and managing the 3rd-party-component vulnerabilities, so it was natural to choose Dependency-Track for the job after a common meeting with the stakeholders. As Dependency-Track does not generate the SBOM itself, CycloneDX Generator (cdxgen) was chosen as the tool for that part. After the tool was chosen a PoC was created in a live environment with minimal configurations. The PoC can then be monitored and used for testing and seeing if the selected tools will be taken into use in a larger scale in the company.

The thesis' conclusion is that the SBOM is going to be an important part of software development and its security. The SBOM process requires some adaptation for specific environments, but the tool collection is, luckily, broad so the right tool can be found and selected with some testing. When testing and selecting the SBOM tool, some things are important to consider such as the software development environment, used software package managers, and the desired SBOM format. In this thesis the Dependency-Track was found to be versatile and compatible with the M-Files Hubshare environment.