A Guide to Code Portability
As applications need to operate across multiple environments, code portability has emerged as a topic of focus for developers. This guide will help you understand what code portability is and…
Open source software is driving 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 it’s been widely adopted. However, while open source code is cost-effective, flexible, and agile, it also poses some serious security and liability risks. We’ll get into all of it, as well as 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 the data of 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.
This risk of infringement is higher with open source software. This is because it doesn’t have the type of freedom from third-party infringement clauses that come with commercial licenses. Additionally, 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 as a whole 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 all 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 versions of the components, 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, where it’s used to list all of the raw materials, sub-assemblies, and parts 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 an integral part of 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 put together 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 them 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 there’s no single centralized system that 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 of the software back to its component 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 both with generation and readability. Additionally, predictable implementation and data formats are necessary to take full advantage of 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 trouble-shooting 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 pretty straightforward and have existing standards, while some have multiple best practices. In both situations, the process should be specified.
The practices and processes section should include at least the following elements:
Anytime software is updated or patched, a new SBOM should be created. A new SBOM should also be made 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 as well as the transitive dependencies. Businesses may need to start with top-level components when they first create an SBOM. Information about sub-components may be challenging to locate. However, implementing practices and processes will support increased depth with further iterations.
At a minimum, 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.
The unknown elements must be explicitly identified as known unknowns when the full dependency graph isn’t available in the SBOM. It should be easy to distinguish between components with no further dependencies and components whose dependencies are incomplete or unknown.
There are two components to sharing the SBOM up and down the software supply chain, including how the people are told about the SBOM and how they can access it. There are a lot of variables that 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 keep access limited to customers. Businesses that want to control access to their SBOM 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 a complete and 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 dependencies issues. SCA also supports many languages and offers plans to suit the needs of every team. Reach out today to find out how we can help manage all aspects of your open source risks.
