Role of Software BoM in Securing Software Supply Chain
In July 2021, a ransomware group, R-Evil, attacked a Managed Service Provider, Kaseya. R-Evil hit Ksaeya’s remote monitoring platform. More than 1,000 Kaseya’s customers used the platform. Each of these customers provides services to many other large businesses. By noon, US Eastern time, R-Evil claimed that one million systems were down because of their ransomware attack! The ransom of $1 million at 8 am was raised to $70 million US dollars by noon! This is all because of one vulnerability in the remote monitoring software that attackers could exploit successfully. Like traditional supply chains, software supply chains can also create a domino effect and disrupt businesses and society.
Software Supply Chain
The software supply chain comprises source code, third party and open source libraries, other software components, tools, etc., needed to build and release the software. If any of the dependencies fails, the functionality of the software or application is impacted. Disrupting the software supply chain is not only impacting the software and technology companies but can affect almost all businesses, government, and society. That is why securing the software supply chain is the most important priority. `
The US government issued an executive order to secure information and infrastructure. Executive Order (EO) 14028, Improving the Nation’s Cybersecurity (May 12, 2021),1 focuses on the security and integrity of the software supply chain and emphasizes the importance of secure software development environments. The EO directs the Department of Commerce, in coordination with the National Telecommunications and Information Administration (NTIA), to publish the “minimum elements” for a Software Bill of Materials (SBoM).
SBoM
The term Bill of Material (BoM) originates from the manufacturing industry. The BoM is a list of raw materials included in manufacturing a product. In its simplest form, the Software Bill of Material or SBoM is defined as a list of third party or open sourced components used in the software. In other words, SBoM is a snapshot of the software supply chain. To maximize the benefits and optimize the SBoM creation process, the SBoM should be integrated with the Secure Software Development Lifecycle.
The SBoM usually includes the following information:
- Author Name: Author of the SBoM. The author name field could be the same as the supplier name, or the company could hire a third party to do the work.
- Supplier Name: The supplier is the software developer or creator.
- Component Name: Names of the various components and libraries included in the software.
- Versioning String: Version information of the components/libraries included in the software.
- Component Hash/Unique Identifier: Adding component hash provides a unique and secured identifier.
- Relationship: The relationship of the component included with the software is very important. The direction of the relationship is not as important as long as it is consistent in one direction.
SBoM Formats
Currently, there are three SBoM formats are in use. Please click on the names below to find out more about each format:
Benefits of SBoM
Some of the critical benefits of SBoM to software vendors & customers are:
- Quantifying and managing licenses
- Identifying and remediating known vulnerabilities
- Identifying and managing compliance requirements
The software vendor or supplier has one more crucial benefit — Transparency. By sharing the SBoM, the software supplier can prove that they have processes to manage vulnerabilities, apply patches, and adhere to compliance.
The benefits of SBoM are far more to customers with the onPrem deployment. This is because, in the case of onprem deployments, customers are on the hook for applying certain patches and managing the environment. Knowing what is in the software keeps them looking for new vulnerabilities or versions of any dependent software.
However, in the case of cloud customers, especially SaaS customers, these benefits are not as lucrative since SaaS consumer does not have to manage vulnerabilities, apply patches, or upgrade to the new version.
The Case for Transparency
The SaaS vendors can use SBoM for transparency and to vouch for the quality and security of the software. By sharing the SBoM, the software vendor assures the customers of the products and processes' authenticity, integrity, and reliability. Apart from the software vendor’s SBoM, SaaS customers can also obtain SOC 2 and other third party audit/compliance reports to verify the quality and security of the software,
- SAP Managed Tags:
