Tackling Software Supply Chain Security: A Toolbox for Policymakers

For software development platform provider CircleCI, this year began with a scramble to respond to a software supply chain compromise. CircleCI’s tens of thousands of customers use the continuous integration and delivery (CI/CD) platform for automating the building, testing, and deployment of software. A malicious actor had gained remote access to an employee’s laptop and was consequently able to access customer data, including private keys used for software signing and credentials stored in the platform. 

Among CircleCI’s several affected customers was Datadog, a company that provides software for monitoring cloud infrastructure. As a result of the attack on CircleCI, Datadog had to notify its customers that its systems had been rendered partially vulnerable. This case illustrates the potential impact of software supply chain compromises: One incident can have ramifications further down the supply chain, impacting not only the customers of the originally targeted software-developing entity but also their customers’ customers (and so forth). This is a lesson that the international cybersecurity policy community had learned the hard way in previous years, for instance, following the discovery and subsequent exploitation of a vulnerability in the widely used open-source software library Log4j. This component is part of a wide range of software supply chains, so malicious actors were able to exploit the same vulnerability for cryptomining, botnet building, and ransomware purposes, affecting organizations and individuals worldwide.

Governments and industry have become increasingly aware of the security risk that software supply chains can cause if not managed properly. One of the five pillars of the 2023 U.S. National Cybersecurity Strategy, for example, is to “shape market forces to drive security and resilience.” Among other things, the recently released strategy mentions implementation of labeling schemes for Internet of Things devices and a shift in liability for insecure software products that would put responsibility on companies. These are key components in strengthening supply chain security. However, the strategy does not specify how to put these objectives into practice. The strategy’s principles are consistent with the U.S. Cybersecurity and Infrastructure Security Agency’s (CISA’s) recent calls for private companies to step up measures to prevent software supply chain compromises. The core of CISA’s argument holds that technology providers must build products that are “secure by default” and “secure by design.” CISA also announced that it is building a new supply chain cyber risk management office, highlighting its focus on the issue. 

These are worthwhile efforts. But there is nonetheless much wider room for government action and specific measures that can and must be leveraged to strengthen software supply chain security. As security flaws keep software and entire supply chains vulnerable, it is time now for policymakers to set regulatory lanes for developers to build safe and secure technology. They must create incentives for the private sector to prioritize software supply chain security, deter insecure practices and negligent behavior, and help coordinate among industry, government, and civil society stakeholders according to their respective roles. The new U.S. National Cybersecurity Strategy details important strides in this direction. Concrete government actions and policy interventions should start with those areas that are most critical to the secure, safe, and smooth function of key digital infrastructure that is of benefit to modern society. With this in mind, we make recommendations for where policymakers should start and how to prioritize supply chain security measures. 

Why Is Cyber Supply Chain Security So Difficult?

Three characteristics of the software-developing ecosystem open the door to software supply chain compromises: First, software-developing entities rely significantly on a multitude of software components developed, delivered, and maintained by others. While software-developing entities can and should test the security of these components, complete security is usually not feasible. As a result, the final software inherits security risks like software vulnerabilities from these third-party components, which is particularly problematic in the case of generic components that are integrated in a wide range of software applications and deployed globally. 

Second, despite improvements in software security, especially in commercial software, security still too often remains an afterthought rather than a primary consideration in software development. The fact that security does not figure prominently in current training for software developers worsens the situation. This is because companies often have little incentive to invest in the security of their software because neither end-users nor business partners demand security; what matters is a short time-to-market, which directly affects how much development and testing time is spent on security of software products prior to their release. Furthermore, there is no regulation that would hold companies liable for failing to prioritize security. 

Third, software-using entities struggle to assess the (in)security of a given software, which is why these customers seldom demand it. This is due to information asymmetries between consumers and suppliers and a lack of transparency on the entities and their security practices that form part of a given software supply chain.

New Approaches to Secure Software Supply Chains

Drawing on the expertise of an international expert working group, one of us recently co-authored a report for the Berlin-based tech policy think tank Stiftung Neue Verantwortung seeking to provide policymakers on both sides of the Atlantic with a toolbox to strengthen software supply chain security. (Note: There was equal co-authorship on this Lawfare article.) While the maturity of supply chain security efforts varies across industry sectors and countries, basic building blocks for increasing supply chain security have been in the making for more than half a decade. The adoption of those best practices and measures by software-developing entities, ranging from small and large native technology companies to old industry giants and new start-ups that have embraced new digital technology, is a different matter. In short, the adoption of these practices and measures has been slow. In part, the lack of direct incentives, market pressure, and government demand can be blamed for the current stage of adoption. But also, existing tools, such as technical standards, certifications, and conformity assessments, have not sufficed to effectively address the dynamic complexity of software supply chains. More recent technical, organizational, and institutional innovations, some tested more broadly than others, have the potential to form a new and more comprehensive approach to software supply chain security. Some of them have already been implemented successfully in sectors other than software. Now, bolstering software supply chains will require harnessing those new tools jointly with existing measures and coordinating their deployment across government, industry, and frankly the entire information and communications technology (ICT) ecosystem. 

Among those key cybersecurity innovations are software bills of materials, security labeling schemes, and product liability. A software bill of materials (SBOM) lists the components and supply chain relationships of a given piece of software. It transposes the idea of bills of materials—which are common in supply chain management of hardware like machinery—to the software realm. For software users, it is particularly critical to know the various components and their properties of a given piece of software when new vulnerabilities are discovered, as they should be able to easily find out whether software they are using may be affected.

Product security labels are attached to software products and indicate to consumers that the product fulfills given security criteria, based on conformity assessments or the like. Labels already exist for many other types of products to indicate, for instance, the nutritional value of food or the energy efficiency of home appliances. When transposing this idea to software, a central question is whether the labels should be product or process based: While product-based labels attest to the security characteristics of a particular product at a given time, process-based labels contain information about the processes in place at the responsible software-developing entity, for instance, for how long security updates will be provided. The idea is that product security labels make the security of software visible to consumers and may therefore, in the long run, contribute to making security one factor among others in software sourcing decisions. While there are already private initiatives for this and governments have been starting to implement voluntary product security labeling schemes for software, mandatory labels have yet to be established.

In a product liability regime that covers software, software-developing entities (or potentially retailers) can be held liable for harms caused to users of the software. Many existing product liability regimes do not cover software and address only cases in which faulty products result in physical harm, death, or property damage. In other words, they do not address the harms typically caused by software supply chain compromises, including data loss, reputational damage, or lost profits due to downtime of information technology systems. The idea of product liability for software is not new but has received little traction so far, especially given industry fears of excessive lawsuits. Accordingly, software product liability is the most nascent of the three cybersecurity innovations and likely the most difficult to implement, as it would require legislators to reallocate risk-bearing to industry.

A Policymaker’s Toolbox for Increasing Software Supply Chain Security 

The toolbox combines these innovations with tried and tested instruments. Each component tackles different root causes of supply chain compromises. And even the more established instruments would benefit from an increased adoption among software-developing entities. 

In addition to the three innovative instruments mentioned above, the toolbox includes two more quality assurance instruments: secure software development practices and coordinated vulnerability disclosure. Beyond product security labeling schemes, quality assurance instruments include technical standards and conformity assessment schemes. All three serve to reduce information asymmetries between software-developing and software-using entities. Secure software development practices are guidelines for software-developing entities that include both recommendations for the construction of more secure software and guidance on how to manage suppliers with entities upstream and downstream in the supply chain. Finally, coordinated vulnerability disclosure (CVD) describes the coordinated process that starts when a finder, often a security researcher, reports a vulnerability to a software-developing entity and ends when a remediation for the vulnerability is provided (often by the software-developing entity in the form of a software patch). 

Instruments of the toolbox policymakers for increasing software supply chain security:

• Quality assurance instruments.
• Secure software development practices. 
• Coordinated vulnerability disclosure (CVD).
• Software bill of materials (SBOM).
• Product liability.

This combination of instruments provides policymakers with a range of options to tackle software supply chain security. To deploy these tools effectively, governments should take advantage of the full spectrum of government actions at their disposal, including but not limited to:

• Convening stakeholders around pressing supply chain security issues through government forums. 
• Issuing guidance through best practices and templates. 
• Providing funding to encourage adoption of security measures, initiate research and development, and promote software supply chain security start-ups. 
• Taking action on education and workforce development at universities and training institutions, and fostering security-oriented curriculum development. 
• Adapting governmental processes to lead by example and implement good practices in software-developing government agencies and their contractors.
• Issuing public procurement guidelines to include software supply chain security in the requirements for public ICT purchases and shape markets through demand-side requirements. 
• Developing policies and regulation through regulatory authorities, for instance, in critical infrastructure sectors.

These actions constitute a spectrum ranging from voluntary actions, such as facilitating and providing financial incentives for implementing good practices in software supply chain security, to hard mandatory requirements like sanctioning software-developing entities that do not comply with minimum requirements. Taken together, these instruments and government actions show how policymakers can tackle the software supply chain security problem.

Closing In on Sources of Supply Chain Insecurity

As software vulnerabilities abound, the past years have seen an increasing number of voluntary and mandatory measures developed by industry and governments. While these efforts point in the right direction to improve software supply chain security, there is still a long way until widespread adoption. Keeping in mind that maturity of software supply chain security efforts varies across industry sectors and countries, policymakers are well advised to carefully consider where they should prioritize their efforts. Governments should focus efforts on three critical sets of actions in order to effectively manage and mitigate supply chain risk and enhance supply chain security. The public and private sectors must have a shared understanding, informed by a strategy, in order to implement these priority actions in a coordinated manner that is guided by ample political leadership. Depending on where a given country’s policy stands on software supply chain security as well as how salient the issue is and how many resources and capabilities are available, policymakers may tackle these three sets of actions one after the other or choose the one that best suits their needs.

Level 1: Basics First

Every government committed to strengthening software supply chain security should first work to get the basics right. These are fundamental building blocks on which further government and private-sector actions can build in the future. Governments have made significant progress in the past decade to build up the cybersecurity foundation in the form of frameworks and standards for such actions. The National Institute of Standards and Technology (NIST) Cybersecurity Framework and the EastWest Institute’s ICT Buyers Guide are examples that early on prioritized supply chain security, linking to relevant standards and providing sets of questions to make informed supply chain security decisions. These basic actions require limited resources and capabilities and can be implemented in a short time frame as they draw on existing, well-established practices.

These government-driven basics include:

• Making secure software development practices an integral part of education and workforce training for developers. These secure coding practices are well established within the industry and have developed significantly over several decades. Governments, together with the private sector, can take actions to make them an integral part in professional training and university education. 
• Issuing guidance on how to set up and manage CVD at software vendors and technology providers. The disclosure of software vulnerabilities by security researchers is well understood. Governments can provide guidance, including exemplary policies and templates, to help establish effective disclosure, reporting, and mitigation practices, which should translate into better cybersecurity. The U.S. government provides such guidance through a template CVD policy by the U.S. National Telecommunications and Information Administration (NTIA). 
• Specifying data formats and issue guidance for technical tools for SBOMs. SBOMs are a promising yet nascent development that has the promise to shorten security mitigation due to automation and effective reporting, especially when combined with technical tools that build on SBOM data. Governments can recommend the use of SBOMs in general terms or they can go a step further and set directions (for example, “choose a winner”) in this development. The latter will speed up the development and adoption of SBOMs and bring those participants on board that have been waiting on the sideline. 

Level 2: Ambitious but Tried and Tested

At the next level of software supply chain security, governments should aspire to include more stringent security requirements, especially for more critical and/or widespread functions,while the most critical services deserve even stronger levels of protection. These actions still only require limited capabilities to be put into practice and have been implemented previously, so numerous reference implementations exist. Thus it is reasonable to assume that a committed government can take these actions within short to medium time frames and require only limited resources. 

On this level, governments can incentivize or advocate the following actions:

• Fostering quality assurance on a national level by leveraging the government’s convening power and bringing together national and international stakeholders to strengthen coordination and exchange of good practices. This allows for the ongoing development and learning of existing and new security quality assurance measures. While this may seem a rather basic area for software supply chain security, a tremendous number of initiatives have been undertaken in recent years in these growing fields, supported by major government-led initiatives. An example of international coordination on conformity assessments among EU member states is the European Cybersecurity Certification Group and its multistakeholder equivalent, the Stakeholder Cybersecurity Certification Group. 
• Emphasizing that not all organizations or technology products are the same. Governments should issue guidance tailored to specific needs of particular industries and organization types regarding the implementation of secure software development practices. For instance, both the European Union Agency for Cybersecurity (ENISA) and NIST have published guidance to this effect, focusing on different stakeholders. 
• Establishing CVD policies to drive the adoption of vulnerability disclosure and reporting. In a first step, government entities that develop software should establish CVD policies and adapt respective processes. Relatedly, government procurement requirements should require technology vendors to have organizational CVD policies in place. Instead of isolated efforts, governments can create a whole-of-government approach to CVD and mandate that all government agencies develop CVD policies, as the U.S. government has done. Alternatively, a government could designate one entity to handle CVD for all other government entities, as is the case with Japan. 
• Convening SBOM stakeholders to discuss challenges and uses of SBOM and to conduct prototyping and evaluations with the goal of helping SBOM get off the ground and drive adoption.

Level 3: Breaking New Ground

The way to lead in software supply chain security is hard. This is the route that ambitious governments decide to take because they understand that these actions, difficult as they may be to take, are critical to secure software supply chains, ensure digital security, and strengthen trust. These far more advanced actions require much greater resources and significant capacities to accomplish their successful implementation. Given their nature at the cutting edge of supply chain security, their timeline is much longer because of their greater complexity and the novel ground they cover.

These advanced measures include:

• Strengthening quality assurance by providing dedicated government funding for effective measures, tools, and standards and establishing harmonized regulation on conformity assessment schemes and product security labeling schemes. 
• Mandating through regulation that software developers and technology providers adhere to secure software development practices that are based on recognized, international standards. 
• Implementing a national legal CVD framework that requires (certain) software-developing entities to adapt a legally binding CVD policy for their organization and technology products. The 2022 EU Cyber Resilience Act draft legislation would prescribe this for all vendors of products with digital elements. 
• Mandating the use of SBOMs for entities selling software, technology, and services to critical infrastructure providers and allocating funding to advance the SBOM development, specifically data formats and technical tools to automate the rapid exchange of relevant SBOM data to help detect, communicate, and mitigate security vulnerabilities with partners. The Cyber Resilience Act draft legislation contains provisions to this effect, and, according to Executive Order 14028 in combination with White House Office of Management and Budget Memorandum M-22-18, software vendors from whom U.S. federal agencies choose to solicit SBOM documentation need to provide this data in one of three data formats specified in a guidance document by the U.S. NTIA. 
• Establishing a product liability regime for software products. While there is little experience with this instrument, the 2022 Cyber Resilience Act draft legislation envisions a strict liability regime that would also cover stand-alone software. When developing any regulation in this field, policymakers need to consider how it will affect subject matter experts and individual developers, who typically have fewer resources and may thus be disproportionately affected by regulatory burdens. 

These three levels for taking action show that all governments, tailored to their existing policies, requirements, and capabilities, can and must take action to tackle software supply chain insecurity. Previous compromises exploiting weaknesses in software supply chains are too numerous to ignore and have affected people and organizations all around the world. It is time for a broader range of governments to start creating effective policies and implementing measures. The new U.S. National Cybersecurity Strategy as well as current EU cybersecurity proposals are important milestones as they incorporate many of the report’s findings and recommendations. This creates momentum for important change that policymakers and the industry together should work to capitalize on in order to reduce the attack surface of software for users worldwide, for the benefit of all users and the rapidly growing digital economy.