In the last post of this series, we had an overview of software supply chain security and summarized some observations during the research. You can read the previous post here. In this post, we’re going to talk about the threats faced by the software supply chain.
Globalized economic development has brought more opportunities and potential, and the presence of a value chain facilitates globalization, diversification and complication while bringing more significant challenges and threats to enterprises in managing supply chains. The lengthy software supply chain with complex processes, complicated links and massive suppliers exposes itself to an expanding attack surface. Cyberattackers use the vulnerable links of the supply chain as the window. Every vulnerable link, from information flows between suppliers and consumers in the traditional sense, system and business vulnerabilities, non-backdoor implant, software pre-installation, to some advanced pre-fabricated issues, can be exploited for attacks.
From the perspective of the entire life cycle, the software supply chain can be divided into upstream supply chain security, development security, delivery security, use security and downstream supply chain security, while the risks exist throughout the entire life cycle of the software supply chain.
Security of Upstream Software Supply Chain
In response to unique business demands, companies resort to customization or cloud services, and may use software supplied by software suppliers or cloud service providers. In such a context, whether enterprises have considered the risks facing the upstream supply chain becomes a question. In terms of software products, there are risks such as whether software suppliers can ensure the core component used in the software is reliable and clearly constructed, and whether an enterprise can isolate component risk promptly when the vulnerability is exposed. Another risk is whether the software has attack resistance in the face of external cyberattack risks. It is also important to determine whether a software supplier is capable of locating vulnerabilities, assessing the risks of such vulnerabilities and code, and providing sustained updates in the face of internal vulnerabilities or external attacks. The scope of critical data and credential management capacity when assessing the upstream software, with the concern of critical data leak in particular, have been key factors in choosing upstream enterprises. The sustainability of the software should also be ensured. It is not allowed to have business influenced by components or environmental elements, such as the potential interruption of SaaS and PaaS of cloud service providers.
In security of the upstream software supply chain, there is another risk—open-source risk. The use of open-source software has promoted technological development to a certain degree and brings more possibilities for innovations. But on the other hand, the complicity of the international landscape, the open source and easily accessible features of such software may invite greater risks, including growing vulnerabilities of open source components and frameworks as well as the lower tracking and repair capabilities for the vulnerabilities which are not officially recorded due to the broader presence of open source software in every community. In addition, the invisible reliance on open-source software breeds compliance and compatibility risks among open-source software applications, which may invite IPR risks and bring more challenges in vulnerability detection and repair. Whether upstream enterprises are capable of regulating open-source software is also a question.
In the event of the lack of considerations about pre-procurement risk points and response capacity, it is very likely to be unable to isolate the software risk and curb the spread of such risks when the software is attacked or any vulnerability is exposed, and clients using such software shall be impacted to a degree that ranging from business disrupted to suffering financial loss or even the survival threatened.
Development Security of Software Supply Chain
The exclusion of security considerations during the development of software by developers to raise efficiency may result in security issues and higher overall costs and challenges in repairing. From the perspective of security, software development security can be divided into three phases: IDE security, development process security, and compilation and construction security.
During software development, tools shall be prepared to assist in coding business functions. The selection of development tools matters, as risky development tools probably bring security risks to the finished software. What’s more, the contamination of either IDE or CI/CD integrated environment may result in code tampering, malicious implant, or even security risks in the entire coding environment. The source code needs to be stored in an uncontaminated repository after R&D, or it is vulnerable to tampering or malicious implanting by malicious personnel through a hosting platform or code repository.
Threats may be invited even in the development process. For example, some developers prioritize function development over security due to tight schedules or heavy workloads, or borrow codes while incapable of identifying or judging code security issues. In addition, the security issues of the internal coding logic and the revision, tailoring and iterations may introduce more security issues. In the development lies the potential risk brought by open-source components.
Even when the development is finished and compiler construction starts, the insecure compiler tools may also lead to back-door implant. Since most Internet companies adopt in-house package management tools for storing self-developed software packages, if it is not specified that these packages can be downloaded in the intranet only, cybersquatting may happen and the production configuration files of developers may refer to packages that do not exist in official sources during the use process.
Delivery Security of Software Supply Chain
Nowadays many enterprise software applications are outsourced to third-party suppliers: purchasing the basic framework of third-party software and customizing and modifying it according to their own conditions. When source code is shared, the security responsibility of source code becomes shared for both sides. But few enterprises will raise management requirements for source code in the third-party suppliers’ repositories. Software suppliers keep their eyes on the delivery of functions instead of the security of source code storage. For example, the workplace and the source code reservoirs in the same area, insufficient security devices in the connected environment, unrestricted access control for source code and other issues are prevailing.
In delivery, besides the security of source code, the management scope of delivery shall also be expanded. If the delivered software has not been compiled or compilation information has been leaked, the insecurity of source code will be more concerning, which provides easier access for attackers to breach security measures by tampering, implants or other methods to make profits. The ordinary usage of software also involves the risk of credential and key leakage. If the reliability of the basic environment can not be secured, the leakage of credentials and keys shall make it more inviting to invasions.
Usage Security of Software Supply Chain
In using a software application, information security emergency is inevitable, such as 0-day vulnerabilities and other software viruses. Failure to respond and isolate in time may severely threaten an organization and cause heavy financial loss.
The usage of software relies on the internet infrastructure or cloud platforms. Infrastructure under malicious attack or natural disaster may lead to broader service disruption and threaten normal operations. Organizations should ensure the compliance of the internet infrastructure with national regulatory requirements and put in place the construction and maintenance of the internet infrastructure.
Security of Downstream Software Supply Chain
The downstream software supply chain is dominated by marketing, service, and branding. The information of the downstream supply chain shall be the input of the upstream supply chain. Considering the broad participation in every link of the supply chain, however, the flow of demand information among organizations tends to be reserved, and during the transmission and amplification of demands from the downstream supply chain to the upstream supply chain, there will be the “bullwhip” effect. The bullwhip effect distorts and amplifies the information, curbing effective and real-time information flow. Since the demand information perceived by the organizations depends on the input, more links in the supply chains and a longer supply chain mean the severer distortion of information and less efficiency of the supply chain.
The implications of the upstream supply chain also exist in the downstream supply chain. For example, an exclusive downstream supplier is used, or there are differences in management level, corporate culture, operation mode, and financial conditions of downstream suppliers. The upstream and downstream supply chains are of the same significance to corporate management.
Risks in Software Supply Chain Security
Previous post on software supply chain security:
