Open-source software drives the digital-first transformation and is at the heart of the Fourth Industrial Revolution. Currently, 90% of IT leaders use open-source software, and 79% expect to increase their use over the next two years. Considering the numerous benefits of open-source software, it’s not surprising that it is widely adopted. However, while open-source code is cost-effective, flexible, and agile, it poses some serious security and liability risks. We’ll delve into all of this, including the role of the SBOM (Software Bill of Materials).
Security vulnerabilities and licensing compliance are the two primary concerns associated with open-source code. Security flaws are present in 70% of open-source applications, which is even more alarming, given that almost 80% of libraries are never updated.
One of the most notable examples of the security risks associated with open-source code is the 2017 Equifax breach, which exposed data from over 143 million people. Equifax was advised of the security risk and the need for a patch more than two months before the breach, but failed to install it.
The liability risk associated with open-source software stems from the diverse and often conflicting types of licenses. There are over 200 types of open-source licenses. Organizations frequently utilize multiple open-source solutions, making it challenging to keep track of their licensing requirements. The significant risks you face with licensing are infringement and restriction.
Open-source software is more likely to be infringed because it often lacks freedom from third-party infringement clauses typically found in commercial licenses. Any programmer can add infringing code to open-source software because it’s developed without traditional controls.
Another licensing risk with open-source code is restriction. Some open-source components are distributed under licenses that require that software that contains or is derived from it be freely distributed. Therefore, proprietary software may be “tainted,” obliging developers to make the code available and license the work at no charge. A software composition analysis can help DevSecOps teams identify and address all of these issues.
A software bill of materials (SBOM) is a resource that gives development teams an overview of the security, performance, and licensing issues related to their software. An SBOM lists all open-source and third-party components in a codebase. It also includes the component versions, patch status, and governing licenses.
All organizations that build software using open-source or third-party components must create and maintain an SBOM.
The concept of a bill of materials (BOM) comes from the manufacturing industry. A BOM lists all of the raw materials, sub-assemblies, and parts needed to manufacture an end product. Manufacturers can use the BOM to quickly identify and rectify problems related to their products, such as recalls or supply chain issues. Similarly, an SBOM helps teams track all the sub-components of their software to ensure patches and updates are installed when they are due. It also helps them ensure they aren’t violating any license agreements.
An SBOM is designed to be shared across an organization, providing transparency into the various software components produced throughout the software supply chain. The SBOM should be integral to every DevOps team’s cybersecurity strategy.
Although an SBOM is a valuable tool, few companies fully understand their open-source components, let alone maintain an accurate and comprehensive list of all open-source code in their software builds. When development teams assemble an SBOM, it should be a formal, machine-readable list that uniquely identifies all software and its components, including copyright and licensing data.
The minimum elements of an SBOM include:
The data fields in an SBOM contain information about each software component that should be tracked and maintained. Data fields contain enough information to easily map to other data sources, such as license agreements or vulnerability databases.
Data fields should include information such as:
If possible, the ability to note multiple identifiers for supplier and component names should be included, as no centralized system currently covers the expanding software ecosystem. Tracking versions presents similar challenges. Different companies label and track versions and distributions in different ways. Although there are best practices for version tracking, they aren’t widely used.
Other unique identifiers can include:
Of course, every piece of software won’t have this information, but if it’s available, it should be included.
The dependency relationship field enables tracing all software components back to their parts, ensuring consistent use and version control. Finally, the SBOM-related data fields will identify the metadata source, which could be the software developer, the supplier, or an analysis tool.
For an SBOM to scale, there must be support for automation in both generation and readability. Additionally, predictable implementation and data formats are necessary to fully utilize an SBOM and incorporate it into a cybersecurity strategy. For example, automated SBOMs can be used for real-time compliance auditing and vulnerability management, provided that standard, machine-readable data formats are employed.
In addition to being machine-readable, the data format of an SBOM should also be human-readable, enabling troubleshooting and innovation. The following data formats were developed for these purposes:
While data and automation support are crucial to developing a functional SBOM, it also needs to outline practices and processes that will be used to fully integrate it into the secure software development cycle. Some aspects of these practices and processes are straightforward and have existing standards, while others have multiple best practices. In both situations, the process should be specified.
The practices and processes section should include at least the following elements:
A new SBOM should be created anytime the software is updated or patched. It should also be created if a build includes an updated component or if a supplier corrects an error in an existing SBOM.
Ideally, an SBOM will include all top-level components and the transitive dependencies. Businesses may need to start with top-level components when creating an SBOM. Locating information about sub-components may be challenging. However, implementing practices and processes will support increased depth with further iterations.
An SBOM must include primary components and enough information to find dependencies. The goal should be to completely graph all component relationships, as some use cases, such as proving a particular component is not in a network, require a complete graph.
When the full dependency graph isn’t available in the SBOM, the unknown elements must be explicitly identified as known unknowns. It should be easy to distinguish between components with no further dependencies and those with incomplete or unknown dependencies.
Sharing the SBOM up and down the software supply chain has two components: how the people are told about the SBOM and how they can access it. Many variables will affect how each organization carries this out, but a specific practice should be implemented.
Some suppliers may want to make their SBOMs public, while others may want to limit access to customers. Businesses that want to control access to their SBOMs should specify the terms and conditions.
The first implementation of an SBOM should include an accommodation of mistakes to allow for errors and omissions. Internal management of supply chain data is an emerging field. As errors are corrected and new data is known, an updated SBOM should be issued.
In addition to the above components, other data fields can be helpful in an SBOM, particularly in use cases that require higher security. These include:
Using a validation tool to create an SBOM and manage open-source security simplifies the process and reduces the risk from third-party code. Kiuwan’s Open Source Insights (SCA) automates the process throughout the software lifecycle. SCA generates an accurate inventory of all third-party or open-source components used in applications and builds. It detects any threats so they can be quickly addressed and patched as needed. Developers can automatically manage libraries, check for updates, track versions, and get obsolescence alerts.
Kiuwan Insights eliminates the need for manual compilation of an inventory. Code quality analysis also identifies unused code and removes it, reducing the risk of dependency issues. SCA also supports multiple languages and offers plans tailored to the needs of every team. Reach out today to learn how we can help manage all aspects of your open-source risks.
