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 many benefits of open-source software, it’s not surprising how widely adopted it is. However, while open-source code is cost-effective, flexible, and agile, it poses some serious security and liability risks. We’ll get into all of it and the role of the SBOM (software bill of materials).
Security vulnerabilities and licensing compliance are the two most significant concerns with open-source code. Security flaws are present in 70% of open-source applications, which is even more alarming since almost 80% of libraries are never updated.
One of the most visible examples of the security risks associated with open-source code is the 2017 Equifax breach that 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 one.
The liability risk from open-source software comes from the different and often conflicting types of licenses. There are over 200 types of open-source licenses. Organizations often use multiple open-source solutions, so keeping track of the licensing requirements can be challenging. The major risks you face with licensing are infringement and restriction.
Open-source software is more likely to be infringed because it lacks freedom from third-party infringement clauses with 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 uncover 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 components’ versions, the patch status, and the 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 keep track of all of the sub-components of their software to ensure patches and updates are installed when they should be. It also helps them ensure they aren’t violating any license agreements.
An SBOM is designed to be shared across an organization to provide transparency into the different 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, much less maintain an accurate, 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 because no centralized system covers the expanding software ecosystem. Tracking versions presents similar challenges. Different companies label and track versions and distributions differently. 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 allows tracing all the software back to its parts to ensure 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 as long as common, machine-readable data formats are used.
In addition to being machine-readable, the data format of an SBOM should also be human-readable to enable 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. Information about sub-components may be challenging to locate. 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 completely graphing all component relationships because some use cases, such as proving a particular component is not in a network, require a completed 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, including 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 process of manually compiling an inventory. Code quality analysis also identifies unused code and removes it, reducing the risk of dependency issues. SCA also supports many languages and offers plans to suit the needs of every team. Reach out today to learn how we can help manage all aspects of your open-source risks.
