Software supply chain security covers the whole software life cycle. In terms of software product complexity alone, apart from the software itself, it is necessary to ensure the security of the dependencies and transitive dependencies of software, as well as the security of the software ecosystem composed of these dependency chains. Especially regarding the issue of open-source security, hidden vulnerabilities caused by the transmission of indirect dependencies result in more prominent credit risks and legal risks due to the use of exemption clauses instead of contracts, which is also the aspect most vulnerable to software supply chain attacks in recent years.
An organization must take into account more specific problems when it comes to software supply chain security. For example:
- Is clear information on software composition available for supporting selection decisions during procurement?
- Whether the known security issues (such as vulnerabilities) and risk levels of software composition or open-source components within the selection scope are available to gain.
- Does the supplier employ security development tools for effective management?
- Is the selected supplier or open-source project able to quickly respond to security issues and assist in providing solutions?
- Can legal risks (intellectual property, scope of license, exemption clauses) and business risks be assessed?
- …
- How to effectively deliver software supply chain security capabilities to end users?
- Following the receipt of a security emergency notice, can the information support end users to complete risk assessments quickly?
- How to provide software supply chain security certificates to downstream organizations and end users to attain their trust?
- For international software companies, an SBOM[6], an international standard format used for listing software compositions, is required.
- …
- How to sustain the organization’s own software supply chain security?
- How to check and assess the security of open-source components and third-party components on which software directly or indirectly depend?
- How to log and track the detailed information and updates of software components, and how to trace and locate problems that occur?
- How to ensure that an SBOM is not leaked to a third party when it is transmitted to downstream organizations and end users?
- …
To enable software supply chain security, an organization must clearly transmit the software information that the upstream and downstream depend on with an effective mechanism and ensure the security of the organization itself and its software products by technical and administrative means. Additionally, a mechanism of mutual trust has to be built in the industry to furnish end users with a systematic assessment program for software supply chain security. Based on these three concepts, the following content explains the capabilities necessary for an organization to manage software supply chain security.
Transparency of Software Supply Chain Composition
In order to manage a software supply chain, an organization must first have a consistent description method that clearly transmits the software information between the upstream and downstream and demonstrate the composition of the software supply chain to end users. Compared with the software identification defined in software asset management, this description method for the software supply chain should look further at software product structure to fully describe the composition and dependencies of software products from the perspective of security.
Earlier, the requirements of “Minimum Elements” and “Software Bill of Materials” (SBOM) of software were proposed based on the concept of “Bill of Materials” of traditional supply chain management in the United States H.R.5793 Act. Today, government agencies in the United States, such as NIST and CISA, have identified the SBOM as a priority to promote the management of software supply chain risks. It is also employed as a methodological foundation for many policies and standards. However, the application of the SBOM has encountered certain challenges, one of which is that it can be intractable to consider specific code files or functional modules as the “minimum elements” during software development. When the granularity is excessively fine, organizations may worry about overly disclosing their internal code structure, which will not help end users identify vulnerabilities and discover security risks.
Considering the feasible implementation for organizations, we have broken down the “minimum elements” of software into “software compositions” with different granularity and introduced the concept of transparency of software supply chain composition. The greater the transparency, the smaller the granularity of software composition.
Software compositions at different degrees of transparency constitute their “list of software compositions” that includes all component names, component information, and relationships and hierarchical relationships between components. Each software has a corresponding composition table that stores and logs the basic information on its composition in standard data format. The data help uniquely identify the software components and trace the source and check the maintenance status of the components.
The software composition information is compatible with the SBOM standard. An information example is shown in the following table:
Previous posts on software supply chain security:
- Software Supply Chain Security: Overview
- Threats against Software Supply Chain Security
- The Increasing Trend of Software Supply Chain Attacks
- The Increasingly Complex and Varied Vectors to Attack Software Supply Chain
