Breaking trust: Shades of crisis across an insecure software supply chain

After a particularly exhausting day at work in February 2017, Liv wraps up her project and prepares to head home. Managing the power grid for a third of the country is high-stakes work and tiring at the best of times. Packing up her bag, she goes to turn off her computer monitor and notices an update waiting patiently on her screen: “Flash Player might be out-of-date. The version of this plug-in on your computer might not include the latest security updates.” Liv clicks ‘Yes’ to begin the update and hurriedly steps out of her cubicle. As she moves quietly down the fall, her laptop fan whirs as it visits specific URLs before downloading a file called “install_flash_player.exe,” and, covertly, the Trojan.Karagany.B backdoor.

Liv has no reason to suspect that this software update is different from any other but it allows attackers to quickly install additional tools on her device. Leveraging passwords and usernames stolen through an earlier phishing campaign against Liv’s firm, the intruders move quickly across the entire company’s network and proceed to take screenshots of sensitive windows and capture images of the company’s grid operation control panels. What might have seemed like a harmless software update is actually part of a multiphase campaign that could have allowed attackers to stop the flow of electricity to thousands of businesses and homes in the United States.

This malware isn’t fictional. From 2015 to 2017, an extensive campaign called Dragonfly 2.0 saw “Trojanized” software updates alongside phishing emails and watering hole attacks used to gain access to the networks of more than twenty energy sector firms in the United States and in Europe. In an alarming echo of the 2015 attacks on Ukraine’s energy grid, the attackers obtained operational control of several firms’ networks, giving them the capability to sabotage the energy access of thousands of US users. Using compromised third-party software, attackers gained a foothold in operating systems over the course of the campaign.

Liv wasn’t being careless. Updating software regularly is considered best practice. Yet impersonating updates by trusted third-party vendors provided the DragonFly attackers access to major firms in the energy sector. The software supply chain presents a significant source of risk for organizations from critical infrastructure companies to government security agencies but the state of security in this supply chain doesn’t match up to the risk. There are opportunities for the policy community and industry to work together to address the problem.

Executive summary

Society has a software problem. Since Ada Lovelace deployed the first computer program on an early mechanical device in the 1840s, software has spread to every corner of human experience. Our watches now have Internet connections, combat aircraft come with more code than computer operating systems, and every organization from the Internal Revenue Service to an Etsy storefront relies on software to serve their customers. No longer confined merely to computers, embedded software now controls the operation of complex power generators, medical hardware, the behavior of automotive brake pedals, and planetary scale datasets. As one commentator put it, “software is eating the world.”

With software come security flaws and a long tail of updates from vendors and maintainers. Unlike a physical system that is little modified once it has left the factory, software is subject to continual revision through updates and patches. This makes the supply for code long and subject to myriad flaws, both unintentional and malicious. The private sector’s aggregated risk from software supply chain compromises continues to grow. Ever more feature-rich software is finding its way into a widening array of consumer products and enterprise services, enlarging the potential attack surface. Organizations increasingly outsource IT management and services to cloud computing and managed service providers (MSPs), raising the likelihood that a given firm will be impacted by an attack targeting one of these providers, like the successful penetration of eleven Saudi MSPs in 2018. A similar kind of concentration is present in software development where firms can buy pre-built code from a third parties for complex or widely encountered tasks. Trek Networks, a US company, builds software to allow Internet of things (IoT) devices to communicate over the Internet. In 2020, it was informed of nineteen critical vulnerabilities in its products. These vulnerabilities in one company’s software impacted products from nearly a dozen other manufacturers, like Intel and Caterpillar, potentially affecting hundreds of millions of devices.

The public sector, particularly defense organizations, assumes even greater risk. A generation of Western defense systems, led by those in the United States, benefit from the advantages of Commercial Off-the-Shelf (COTS) procurement. Under a COTS model, defense organizations look to buy and repurpose or build from available commercial components to reduce cost, limit technological lag, and improve development speed. For the United States, COTS software has underpinned a generation of Department of Defense (DoD) systems, leveraging everything from miniaturized low-cost GPS receivers to high-bandwidth satellite data links with unmanned aerial vehicles (UAVs) and growing dependence on open-source software (OSS) in logistics and maintenance systems. A flaw in widely used software could undermine the DoD’s ability to interpret and work with large quantities of sensor data. This attack could be innocuous and go undetected for months, like a 2017 incident in which malicious code was substituted for legitimate samples in the Python Package Manager.

Software supply chain security remains an underappreciated domain of national security policymaking. The debate over 5G and telecommunications security, for example, has focused largely on hardware manufacturing and deployment, yet it is software in these devices that determines data’s confidentiality and path through the global Internet. The push for open architecture in telecommunications, the Open Radio Access Network (ORAN) model, and industry trends toward network function virtualization mean even more hardware functionality will shift to software—making software supply chain security a critical competitive dimension. Exclusive focus on hardware security has resulted in missed opportunities for policy makers. Continued inaction to secure software supply chains risks compromising important intelligence, defense, and public policy programs and will undermine the long-term innovative potential of already faltering US technology dominance.

Software supply chain attacks are popular, they are impactful, and are used to great effect by states, especially China and Russia. High-profile attacks like NotPetya have forced policy makers to confront the importance of software supply chains, but only episodically and without leading to long-term security improvements. Improved technical security measures could raise the cost of attacks, but the United States and its allies must respond to systemic threats and counter the efforts of states to undermine trust in software. The cost of these attacks is as much an issue for states in the European Union (EU) and Asia as it is for the United States. This report’s first trend discusses patterns of state attacks against the software supply chain to motivate several recommendations on new alliance models and operational collaboration.

The security of the software supply chain matters as much as the codebase first delivered to a customer but receives comparably less attention and formal treatment in policy than secure development practices or vulnerability discovery. This report evaluates 115 software supply chain attacks and vulnerability disclosures collected from public reporting covering the past ten years. All of these incidents are based on public blogs, write-ups, and media articles so do not include private disclosures of attacks which never made it to the public domain. As such, even these trends likely undercount the frequency of attacks on certain high-value targets and are biased away from regions throughout the Global South that receive less focus from the cybersecurity industry. This report identifies five trends in software supply chain attacks over the past decade and offers three clusters of recommendations to address, mitigate, and counter them. The five trends identified are:

Deep Impact from State Actors: States have targeted software supply chains with great effect, alone constituting almost a quarter of this report’s dataset.¹ The majority of cases surveyed here did, or could have, resulted in remote code execution. We found that states were more likely to hijack updates, a comparatively sophisticated distribution vector. Several of these cases, like the Dragonfly 2.0 attacks on energy sector targets, are representative of longer campaigns rather than single events. While there are examples from Egyptian, Indian, Iranian, North Korean, and Vietnamese actors, Russia and China were far and away the most frequent. Examples: CCleaner, NotPetya, Kingslayer, SimDisk, and ShadowPad.

Hijacking Updates: These attacks were generally carried out by states or extremely capable actors. Updates that were signed either by stolen or forged certificates carried malware to targets. The advanced malware often contained components allowing it to spread further from the infected machine either along networks or in hardware. These attacks were more likely to encrypt data, target physical systems, or extract information, and, generally, were far more sophisticated than app store components. Examples: Flame, Stuxnet, CCleaner 1 and 2, NotPetya, Adobe pwdum7v71, Webmin, and PlugX.

Undermining Code Signing: The technique relies on public key cryptography and a certificate system to ensure the integrity of updates and the identity of their authors. Overcoming its protections is a critical step in any supply chain attack, enabling anything from simple alterations of open-source code to complex nation-state espionage campaigns. It is the technical process that fosters trust in software and is the central protection against hijacked updates. Examples: ShadowHammer, Naid/McRAT, and BlackEnergy 3.

Open-Source Compromise: These incidents saw attackers either modify open-source code by gaining account access or post their own packages with names similar to commonly used ones. The malicious code they spread usually stole victims’ data and occasionally tried to target payment information. The actors were usually criminals, and their attacks were generally quickly discovered. Examples: Cdorked/Darkleech, RubyGems Backdoor, HackTask, Colourama, JavaScript 2018 Backdoor, and PyPI repository attack.

App Store Attacks: These attacks used the Google Play Store, Apple’s App Store, and other third-party app distributors to spread malware to mobile devices. Usually, the apps were designed by attackers to appear legitimate, though some were legitimate apps that they managed to compromise. The malicious apps tended to run adware, steal payment information, and extract data sent to a server operated by the attackers. Most perpetrators were criminals, though some state-backed tracking also occurred. Examples: Sandworm’s Android attack, ExpensiveWall, BankBot, Gooligan, and XcodeGhost.

These trends show software supply chain attacks are popular and impactful. They exploit natural seams between organizations and abuse relationships where users expect to find trustworthy code. These attacks are also impactful—targeting the supply chain for code can help magnify the value of a breach and sow distrust in widely used open-source projects. Second, these attacks can drive compromise deep into organization’s technology stack, undermining development and administrative tools, code-signing, and device firmware. And, third, software supply chain attacks have strategic utility for state actors and have been used to great effect, especially by Russian and Chinese groups. This trend is likely to continue and should motivate action from US policy makers.

The implication for national security policymakers and the cybersecurity community across the US and allies is that change is necessary to raise the cost, and lower the impact, of software supply chain attacks. New efforts should use existing security controls and make them accessible and low cost for developers. Policymakers should drive new resources and support to open source projects and enable better software supply chain security. Civil society and the cybersecurity standards community hold great potential to help sustain these changes once initiated, especially for open source. The US and allies need to pursue new approaches to joint activity across the Atlantic and Pacific to counter state threats and facilitate more effective long-term investigations of criminal actors. Traditional alliance structures may be insufficient to address threats to major industry players and software supply chains relied on by intelligence and defense departments and agencies.

This report offers three clusters of recommendations to policy makers and industry to address the insecurity of the software supply chain. First, improve the baseline. The lynchpin of any effort to improve the security of software supply chains broadly will be what impacts the largest number of codebases, not what improves one codebase the most. Perhaps the most useful thing the policy community can do is offer support for widely compatible standards and tools to reduce the burden of secure software supply chain management on developers and project owners. Best practices are not effective in isolation, and below a certain threshold it is difficult to profile which vendors and project owners enforce good security practices. The recommendations in this report focus on bringing the best of public and private sector supply chain security tools into the public domain, aligning these tools with widely supported standards, and calling out key stakeholders to help share both how to adopt and assess against them.

Second, better protect open source. Open-source code forms the basis of most enterprise systems and networks. Even large proprietary projects, like the Windows operating system, are built on top of huge quantities of open-source code. The security of open-source projects, and the apparent ease with which attackers can introduce insecure code, is a continuing concern. The fluidity with which anyone can commit code to an open-source project is at once a core strength and glaring weakness. The policy community must support efforts to secure open-source projects, or it will watch a critical and innovative ecosystem wither.

Third, counter systemic threats. Trust is the critical coin of the realm and the United States must work with international partners to protect against deliberate efforts to undermine software supply chains. Efforts by states to impersonate software vendors undermines defender’s ability to patch flaws in code and improve the security of software through the entirety of its lifecycle. This lifecycle is critical to sustaining the national security advantages granted by current and near-future technologies like sensor fusion networks, autonomous supply chains, and “smart” devices. Failure to protect the ability to trust software could cripple the benefits gained from it. These recommendations zero in on systemic threats to trust and highlight new institutional responses from the US and allies to mitigate the activities of states like Russia and China. Transoceanic responses are needed to protect the software supply chain and the US can extend existing partnerships to support more effective joint attribution and collaboration with allies.

Compromising the software supply chain enables attackers to deliver malicious code in the guise of trusted programs. This can be a terribly effective technique to spread an attack widely and in targeting well-secured systems. These risks are particularly acute for the national security community whose ability to churn through huge quantities of surveillance data, run complex weapon systems, and support modern logistics systems is dependent on software, most of it developed outside of government. The solution is not panic nor is it a moonshot, but rather renewed focus on software supply chain security practices, new investment from public and private sectors, and revisions to public policy that emphasize raising the lowest common denominator of security behavior while countering the most impactful attacks. For more on this project and the dataset behind it, please visit us on the web here.

1. Introduction

The state of security in the software supply chain is inadequate and, in some critical respects, getting worse. The policy community must refocus on this topic amidst competing national security priorities and do more to incentivize and support private sector security. Failure to do so creates new and systemic national security risks for the United States and its allies. Attackers capitalizing on vulnerable software supply chains are able to compromise trusted software and important cybersecurity protections to impact large numbers of critical systems.

Significant economic output depends on the security of software every day—the sudden shift to remote work is exemplary of this dependence. Without reliable video conferencing, email, and file sharing, much of the world’s knowledge work would slow to a crawl. Even intangible capacities, like our capacity to innovate, rely in large part on digital tools to collaborate, coordinate, and revise. All of these tasks are dependent on software. Critical defense systems are equally dependent on software. Digitized logistics processes, the ability to work with massive quantities of data, semiautonomous sensors, and munitions all depend on a chain of digital logic embedded in software programs. Part of the F-35’s own software supply chain, the Autonomous Logistics Information System (ALIS), is plagued with vulnerabilities and testing gaps, potentially compromising the entire weapons platform. The supply chain for these physical products is a recognized priority, but the software enabling these systems must be as well.

Software supply chain attacks are not an esoteric or isolated tactic, as this report and its associated dataset shows; they are popular, impactful, and have been used to great effect by state actors. In this dataset, we have collected 115 instances, going back a decade, of publicly reported attacks on the software supply chain or disclosure of high-impact vulnerabilities likely to be exploited in such attacks.² Each instance of an attack or vulnerability was coded with incident name, date, victim, and likely source, while categorizing the basic technical characteristics of each. Figure 1 shows the distribution of attacks and disclosures in the dataset in the examined period.

A software supply chain vulnerability is any software vulnerability that can evolve into an attack, if exploited. In our dataset, we include vulnerabilities that would enable the injection or distribution of malicious code rather than what would be found in the code’s payload, the means of access rather than the harmful payloads. Figure 2 shows the distribution of attacks versus disclosures in the dataset across impacted codebases.

These incidents reveal a stunning diversity—there are as many potential target types in the supply chain as there are types of software. Certain categories have consistently been in the crosshairs for years now: software updates, firmware, and third-party apps. In this dataset, others are being targeted more today than in the past. For instance, as smartphones become ubiquitous, mobile apps, both attacker-made and attacker-infiltrated, have become increasingly popular targets—as have open-source libraries on which much software relies.

Figure 3 uses an abstracted model to show the distribution of the 115 attacks in our dataset and disclosures across a notional software supply chain. There is no good way to concisely represent software development and this graphic is not intended to capture all of the intricacies of the process. This representation of a waterfall-style model matches with much of the software captured in the study. Agile development methodologies like software Development/IT Operations (DevOps) and Development/Security/Operations (DevSecOps) are important but are also no magic solution for software supply chain security issues. These Agile approaches and the philosophy of continuous integration create new opportunities to quickly propagate risk through a codebase.

Figure 3. software supply chain life cycle

While there are attacks through this supply chain model, the figure highlights their concerning concentration against app stores, update processes, OSS projects, and around code signing. Incidents within these types often shared attack vectors, codebases, and distribution vectors, and were carried out by similar actors with similar goals. Figure 3 underlines just how many different opportunities exist to undermine a software supply chain.

The purpose of this dataset is to compile a variety of software supply chain attacks and discovered vulnerabilities, and to catalogue the different characteristics of each incident. While the dataset is not exhaustive, we took care to use consistent definitions and typologies throughout. We defined attacks as occurring when attackers access and edit software somewhere in a software development supply chain, compromising a target farther up on the chain, by inserting their own malicious code. Disclosures that came alongside an ongoing attack were coded as an attack. Attacks don’t require any public disclosure of a vulnerability, only public notice of the attack itself. Software supply chain vulnerabilities are any software vulnerability that, if exploited, would comprise an attack. This flexibility includes a wide variety of critical vulnerabilities, so we limited their scope to those that would enable injection of malicious code, not just compound the effects of an attack’s payload.

Coding the Dataset

Date: Best estimated start date of the attack. When no start date is identifiable, discovery date is used instead.

Name: Name(s) of the attack/incident. Multiple names are included where possible.

Software Supply Chain Attack: A software supply chain attack occurs when an attacker accesses and edits software in the complex software development supply chain to compromise a target farther up on the chain by inserting their own malicious code.

Software Supply Chain Vulnerability: A software supply chain vulnerability is any software vulnerability that could evolve into an attack, if exploited (but which has not been used in an attack).

Affected Code: The code modified by attackers, or the code that had a vulnerability in it.

Code Owner: Who owned that code, or, if open source, the repository name.

Codebase: Categories describing the codebase, product, or service modified by attackers. First party refers to the same author as the creator of the machine; third party is code written by another author whose source code is not publicly available; and open source is code that is publicly viewable.

Attack Vector: How the attacker was able to edit the affected code without detection.

Distribution Vector: How the attacker was able to distribute the modified code.

All incidents were collected via manual online search for media articles, industry reporting, and researcher write-ups of incidents, using information in the public domain. As a result, the dataset here is a lower bound on the population of attacks which undercount incidents that have never been made public and does not include vulnerability disclosures that were not explicitly and publicly reported, i.e., does not include information from patch notes (though this is an opportunity for future work). To analyze trends in these attacks and disclosures, we established five key measures to better understand the different elements of supply chain compromise: attack vector, distribution vector, affected codebase, impact, and supply chain potential. None of these five measures is exclusive: a single entry in the database can have multiple insertion points or methods, distribution vectors, and so on. Information on an entry’s date, responsible actor, downstream target, links to relevant articles, and a paragraph of technical summary was also included. More detailed descriptions of the dataset’s fields can be found in the codebook online.

Although supply chain security has become a hot-button issue for both private industry and policy makers in recent years, the problem is not being addressed holistically and software has largely taken a back seat to 5G in public debate. There are clear and critical policy gaps that exist in securing our software supply chains. Users are increasingly vulnerable, whether it be as a result of malicious apps in app stores, forged digital certificates, or vulnerable open-source code frameworks.

Moreover, this issue is not limited to the United States. State attackers have regularly employed software supply chain intrusions to attack the United States and its allies. Governments around the world are increasingly dependent on open-source and commercial off-the-shelf software for systems relevant to national security, and are exposed to vulnerabilities similar to those faced by the United States. Attacks such as PhantomLance and KingSlayer demonstrate that an attack on systems in one country can easily spread to other states through overlapping supply chains and shared software suppliers. The global nature of software supply chains and the international character of threats make it imperative for the United States to work with partners in the private sector and allies around the world to address this security challenge.

This report offers a series of recommendations that call for a coalition response to the systemic threats posed by software supply chain attacks and vulnerabilities. Working within existing alliance structures while broadening cooperation will allow the United States and its allies to limit the threat actors seeking to undermine trust in the global technology ecosystem, while adapting current alliance networks to the changing threat landscape. Shifting global cybersecurity norms, increasing information sharing to support operational collaboration, and reshaping the focus of interagency equities are all crucial for addressing the serious national security implications of attacks against the software supply chain.

There are opportunities for improvement and a closing window in which to seize them. The remainder of this report discusses five trends in the attacks and disclosures surveyed, including the damaging use of software supply chain attacks by a handful of major adversaries of the United States, efforts to undermine code-signing processes and hijack software updates, and the popularity of attacks on open-source projects and app stores. Following this is a summary of key takeaways from the dataset and specific policy recommendations to drive improved baseline security across software supply chains, better protect open-source software, and counter systemic threats to these supply chains.

2. Attacks on the software supply chain

A software supply chain attack occurs when an attacker accesses and modifies software in the complex software development supply chain to compromise a target farther down on the chain by inserting their own malicious code. These inserts can be used to further modify code by obtaining system permissions or to directly deliver a malicious payload. Modern software products contain a vast number of dependencies on other code, so tracking down which vulnerabilities compromise which products is a nontrivial organizational and technical feat. There are efforts underway to make tracking these dependencies, and discovering them in the event of an incident, more straightforward. The most widely recognized is the Software Bill of Materials (SBOM) multi-stakeholder initiative coordinated by the US Department of Commerce, which remains in development.

Software supply chain attacks take advantage of established channels of system verification to gain privileged access to systems and to compromise large networks. They undermine foundational tenets of trust in software development. Even with the increased exposure gained by these high-profile attacks, we are only just beginning to understand how wide-reaching the impact can be.

The code that attackers and researchers target has changed over time within this dataset. Figure 4 shows the distribution of codebases targeted by these incidents, while Figure 5 shows that distribution over time. Mobile apps have grown more frequent in the dataset, especially those created by attackers and marketed as legitimate. For instance, in 2017, the Android app Lovely Wallpaper hid malware under the guise of providing phone background images. The malware would gain device permissions and charge users’ accounts for “premium” services they had not signed up for. It, and at least fifty other apps hiding the same payload, infected as many as 4.2 million devices, and successors continued to infiltrate the Google Play Store after the original offenders were removed.

2.1 Deep impact: States and software supply chain attacks

2.2 Abusing trust: Code signing

2.3 Breaking the chain: Hijacked updates

2.4 Poisoning the well: Open-source software

2.5 Downloading trouble: App hubs/stores under attack

Third-party firmware is also an increasingly popular target for attackers and researchers alike—a particularly troublesome development given the inherent difficulty of patching firmware and its ability to make privileged edits and avoid much anti-malware program detection. The Equation Group demonstrated the potency of these attacks with its GrayFish attackon hard drive firmware, which allowed it to record system data in a nearly inaccessible portion of machine memory for remote extraction at a later point. Removing the data cache was nearly impossible short of destroying the physical system, and even detecting the infection was generally infeasible.

Proprietary firmware, too, is more frequently discovered to be insecure. In August 2019, McAfee researchers uncovered a vulnerability in Avaya firmware for the 9600 series desk phone, which could have been present at 90 percent of Fortune 500 companies. The bug resulted from the inclusion of unmaintained open-source code and would have allowed attackers to crash a system, run code with root access, and record or listen in on the phone’s audio.

From these general patterns across the 115 incidents in this dataset we observed five more specific trends:

Deep Impact: State actors target the software supply chain and do so to great effect.
Abusing Trust: Code signing is a deeply impactful tactic for compromising software supply chains as it can be used to undermine other related security schemes, including program attestation.
Breaking the Chain: Hijacked updates are a common and impactful means of compromising supply chains and they recurred throughout the decade despite being a well-recognized attack vector.
Poisoning the Well: Attacks on OSS were poplar, but unnervingly simple in many cases
Downloading Trouble: App stores represent a poorly addressed source of risk to mobile device users as they remain popular despite years of evidence of security lapses.

2.1 Deep impact: States and software supply chain attacks

States have used software supply chain attacks to great effect. Hijacked updates have routinely delivered the most crippling state-backed attacks, thanks in part to a continued failure to secure the code-signing process. And while concerns about the real-world ramifications of attacks on firmware, IoT devices, and industrial systems are warranted, these are far from novel threats. Stuxnet and other incidents have had physical impacts as early as 2012. Several of these incidents, like NotPetya and the Equifax data breach in 2017, impacted millions of users, showcasing the immense potential scale of software supply chain attacks and their strategic utility for states. For Russia, these attacks have meant access to foreign critical infrastructure, while for China, they have facilitated a massive and multifaceted espionage effort. This section discusses trends in known state software supply chain attacks supported by publicly reported attribution, focused on four actors: Russia, China, Iran, and North Korea. The data in this report also include incidents linked to Egypt, India, the United States, and Vietnam, for a total of 27 distinct attacks.

Russia

Russian actors were responsible for the 2017 NotPetya attack, one of the most destructive software supply chain attacks to date. Four of the five attacks attributed to Russia in our dataset involved initial insertion of malicious code into a third-party app, made possible by gaining access to an account with editing permissions. After inserting a malicious payload, Russia relied on diverse means to distribute this code, including hijacked updates, a worm component, phishing, and a hardware component. Notably, every attack involved multiple vectors for distribution.

Interestingly, three of the five attacks involved downstream targets in the energy sector. For instance, the 2015 Dragonfly 2.0 attack relied on a variety of vectors—including spear-phishing, watering-hole-style attacks, and Trojanized software updates—to obtain network credentials from targets in the US, Swiss, and Turkish energy sectors. Launched by Russian APT Energetic Bear, attackers were able to gain operational control of interfaces that power company engineers use to send commands to equipment like circuit breakers, giving them the ability to stop the flow of electricity into homes and businesses in the United States. Russian attackers similarly compromised Ukraine’s power grid in 2015, interrupting service to 225,000 customers in a complex infrastructure attack that involved spear phishing, credential stealing, malware insertion, distributed denial-of-service (DDoS) attacks on call centers, and firmware attacks. Russia has repeatedly engaged in software supply chain attacks against Ukrainian entities or programs since 2015, in line with its practice of testing cyber war tactics in Ukraine.

China

Of the state actors featured in the dataset, China has conducted the most software supply chain attacks (eleven) and demonstrated the greatest level of consistency in attack and distribution methods. The earliest case attributed to Chinese actors was in 2011, suggesting that China has been targeting software supply chains earlier than other state actors. Most Chinese attacks relied on a third-party application for their initial insertion point; in the majority of cases, the affected code was found in an update server. Chinese attacks were notably consistent in the method of distribution: eight of eleven cases relied on hijacked updates to distribute malicious code, while several cases relied on supply chain service providers. For instance, in the 2017 Kingslayer attack, Chinese attackers (likely APT31) targeted a Windows IT admin application to include malicious code under a valid signature, which could spread either by updating or downloading the application. The attack compromised a huge list of higher-education institutions, military organizations, governments, banks, IT and telecom providers, and other enterprises, as the malware installed a secondary package that could up- and download files, execute programs, and run arbitrary shell commands. With respect to impact, Chinese attacks tended to be of vast scale, gaining access to the personal data of millions of users, or impacting hundreds of companies.

Chinese software supply attacks are aimed more at corporate entities; eight attacks had companies and dependent users as their downstream targets. Given that all Chinese attacks resulted (or could have resulted) in data extraction, this data is consistent with continuing US concerns about Chinese intellectual property theft and economic espionage. The 2020 GoldenSpy malware notably targeted a multinational tech vendor servicing Western defense sectors by requiring it to install tax-paying software embedded with sophisticated malware while operating in China. We found that the greatest number of attacks occurred in 2017. The timing may have been influenced by the conflicting, but often hostile, moves taken against China by US President Donald J. Trump’s administration in its first year in office.

North Korea

The dataset features one software supply chain attack likely linked to North Korea—the 2013 compromise of two file-sharing services’ auto-update features in order to launch a DDoS attack on South Korean government websites. The attack was launched by the cyber adversary responsible for the “DarkSeoul” attack on South Korean banking and media in March 2013 and is consistent with other attacks by the group in the past. This group has previously launched cyberattacks on days of historical significance in the United States and South Korea. The attack featured in the dataset occurred on June 25, the anniversary of North Korea’s invasion of South Korea in 1950, which marked the start of the Korean War. In early 2013, North Korea also conducted an underground nuclear missile test and, in response to tightening sanctions by the United Nations in March, cut off communications with South Korea, threatened to launch a preemptive nuclear strike against the United States and South Korea, and pledged to restart its Yongbyon nuclear plant to provide material for its weapons program. The high-profile nature of the software attack on June 25 and the extensive damage it caused may accordingly be seen in the context of North Korea’s escalation of military provocations at the time.

Technical elements of the attack are also indicative of methods attributed to the adversary and North Korea more generally. The attack targeted a third-party app and was distributed through a hijacked software update. The dropped malware also allowed for remote code execution and established a botnet to carry out a DDoS attack, consistent with North Korea’s history of launching DDoS attacks (e.g., by North Korean APT Hidden Cobra). It is important to note that the adversary’s targeting of IP addresses that serve as DNS name servers demonstrates careful research into the target in order to maximize damage, an approach also seen in the March 2013 “DarkSeoul” attack.

Iran

The dataset features one software supply chain attack weakly attributed to Iran—the 2020 Kwampirs malware campaigntargeting companies in the industrial control systems sector, especially the energy industry. The attack initially targeted supply chain software providers through exploitation of default passwords. The attackers distributed the Kwampirs Remote Access Trojan (RAT) through supply chain software vendors who would install infected devices on the target’s network. The attack resulted, or likely resulted, in backdoor access and data extraction. The Kwampirs RAT was previously deployed in 2018 by a group called Orangeworm in similar attacks against supply chain software companies in the healthcare sector, and different entities feeding into the healthcare supply chain. While these attacks and the current campaign have not been directly attributed to Iran, the Kwampirs malware was found to contain numerous similarities to the Shamoon data-wiping malware used by Iranian-linked APT33, and also employed in multiple attacks against the energy sector. FireEye, a California-based cybersecurity firm, noted that targeting of organizations involved in energy and petrochemicals reflects a common interest and continuing thread among suspected Iranian threat groups. Previous reports suggest Iranian actors have targeted energy sector organizations headquartered in the United States, Saudi Arabia, and South Korea in an attempt to gain insight into regional rivals and potential competitors.

Other state attacks

Other state actors have also engaged in software supply chain attacks; this dataset features incidents attributed to the United States, India, Egypt, and Vietnam. Stuxnet—widely attributed to the United States and Israel—was one of the earliest examples to use stolen certificates and potentially one of a handful to leverage a hardware vector to compromise. Two campaigns were attributed to the US-attributed Equation Group (PassFreely and EquationDrug & GrayFish). In 2013, PassFreely enabled bypass of the authentication process of Oracle Database servers and access to SWIFT (Society for Worldwide Interbank Financial Telecommunication) money transfer authentication. In 2015, the EquationDrug & GrayFish programs used versions of nls_933w.dll to communicate with a C&C server to flash malicious copies of firmware onto a device’s hard disk drive, infecting 500 devices. Both attacks involved a supply chain service provider as a distribution vector.

The United States is generally distinguished from several of the other states highlighted here by formulation and operation of due process constraints on how attacks like these are developed, targeted, and deployed. One former senior US national security official reflected of Stuxnet, “If a government were going to do something like this, a responsible government, then it would have to go through a bureaucracy, a clearance process… It just says lawyers all over it”. The operational constraints imposed by democratic accountability and the trend toward what Peter Berkowitz labeled the “lawyering of war” offer some meaningiful distance between the United States and several of the other states on this list, though those distinctions blur where legal protections are ignored or interpreted beyond the bounds of accepted logic.

The attacks attributed to the other three states notably all involved attacker applications uploaded to a proprietary app store, leading to data extraction and often remote code execution. A January 2020 attack involving three malicious apps on Google Play Store was linked to APT SideWinder (previously attributed to India). The attack exploited a serious zero-day vulnerability through which the CallCam, Camero, and File CryptManager apps, once downloaded, could extract extensive machine data, including screenshots, and send them to a C&C server. The Egyptian government is believed to have been involved in a hacking campaign against Egyptian human rights activists, in which attackers crafted applications that used OAuth Phishing, generating fake requests for access to Google, Yahoo, Hotmail, and Outlook accounts before stealing emails. The attack also led to 5,000 downloads of malicious mobile apps from the Google Play Store that would enable attackers to view call log information. Finally attackers connected to Vietnam-linked APT 32 (OceanLotus), used a variety of techniques to sneak malware into various browser cleanup apps on the Google Play Store; the attack sent device specs to a C&C server, allowing the attackers to download custom-designed malware onto target devices, likely for espionage. Three attacks from 2011 and 2012 (Duqu, Flame, Adobe code signing hack) have not been attributed to a particular state, but likely involved state actors based on the highly sophisticated and targeted nature of the attacks. These attacks relied on a variety of attack and distribution vectors, and were some of the most destructive attacks in the dataset.

As discussed in the introduction, this report’s findings constitute a lower bound on the total population of supply chain attacks and disclosures. The dataset’s contents are shaped by the limitations of publicly available research on software supply chain security—both in the scope and geographical focus of research efforts. Accordingly, the dataset focuses on incidents involving state actors traditionally covered in cybersecurity research, namely, China and Russia, North Korea, and Iran while understating those from countries in the developing world and Global South.

2.2 Abusing trust: Code signing

Code-signing issues were among the most prolific attack vectors in our analysis, with many attacks stemming from self-signed certificates, broken signing systems, and poorly secured account access as Figure 6 shows. A significant portion of this dataset deals with code signing and how attackers bypass its protections. They occur in both the development and design stage as well as at deployment with hijacked updates and compromised deployment servers, a sub-set discussed in detail in the next section.

Code signing is crucial to analyzing software supply chain attacks because, used correctly, it ensures the integrity of code and the identity of its author. Software supply chain attacks rely on the attacker’s ability to edit code, to pass it off as safe, and to abuse trust in the code’s author in a software environment full of third-party dependencies (so many that vendors are usually unaware of the full extent of their dependencies). If code signing were unassailable, there would be far fewer software supply chain attacks as applications could assert code was unmodified and coming straight from the authentic source without concern.

But there are issues with code signing, so there are software supply chain attacks, and understanding the mechanism is crucial. Code signing is an application of public key cryptography and the trusted certificate system to ensure code integrity and source identity. When code is sent to an external source, it usually comes with a signature and a certificate. The signature is a cryptographic hash of the code itself that is encrypted with a private key. The consumer uses the public key associated with the code issuer to decrypt the hash and then hashes their copy of the code. If their hash matches the decrypted hash, they know their copy of the code is the same as the code that was hashed and encrypted by the author. The certificate is a combination of information that generally includes the name of the certificate authority (CA), the name of the software issuer, a creation and expiration date, and the public key associated with their private key. It provides the CA’s assurance to the consumer that the issuer of the code has the private key that is cryptographically connected to the listed public key. The software issuer alone possesses the private key. The system’s cryptography is similar to that of the certificate system behind TLS/SSL encryption (HTTPS connections), but distinct in its application. (Read more on the difference between code-signing certificate and SSL certificate here).

There are several ways attackers can bypass these systems. The above description is a simplification. There is a chain of certificate authority dependencies: certificates can expire; there are a variety of algorithms used to sign code, some good and others bad; authors can fail to secure their private keys; vetting certificate requesters is challenging; and more. These complexities add vulnerabilities to the system. Attackers can modify code before it is signed by the issuer, meaning the code would be legitimately signed and still malicious. Attackers can compromise weak cryptography, which would allow them to forge a digital signature without needing to steal private keys. Attackers can even steal or buy private keys, allowing them to validly sign malware themselves. Sometimes organizations simply leak the private key by accident. Finally, some parts of computer architecture, like certain firmware drivers, were not designed with security in mind and do not even use code signing. All of these options are reflected in the dataset’s attack vector variable.

For the purpose of this dataset, the difference between stealing private keys and certificates is negligible. The private key is the part of a certificate that is kept secret by the software issuer, and the part that is stolen when the phrase “stolen/purchased certificate” is used. The two phrases are interchangeable in most literature as well. A more technical breakdown can be found here, but an attacker obtaining a legitimate certificate means that they got its associated private key.

Attacks that compromise the code signing system are extremely potent—they get a victim’s system to run malicious code from an apparently legitimate source with significant authority to modify system files. As such, they have been on the rise recently and are a fundamental dimension of software supply chain attacks. (Read more about stolen certificate trends here and here).

Code-signing vulnerabilities are troubling because, if used successfully, they let attackers impersonate any trusted program and bypass some modern security tools. They also sow uncertainty about the authenticity of the very same patches and updates software developers use to fix security holes in their code. In January 2020, the United States’ National Security Agency (NSA) broke with precedent and disclosed CVE-2020-0601 to Microsoft. The bug is lodged in the Windows cryptographic libraries and allows attackers to forge the digital certificates that attest to an object’s identity. Developers sign their code to authenticate it as their own. This gives users a way to identify known and authentic code from that which is unknown and possibly malicious. Browsing online to a bank? There is a digital certificate at the other end of the connection which validates the bank’s website is what it purports to be. Running a software program from a company like Adobe or Microsoft on your computer? The operating system can compare that software’s digital signature with the developers’ to determine whether it is authentic or a malicious derivative. Code signing is an important process for establishing trust in the software supply chain.

The abuse of code signing is also not a recent phenomenon. In 2012, Adobe publicly warned about an attack on its systems that allowed attackers to create malicious files digitally signed with a valid Adobe certificate. A malicious actor had compromised an internal Adobe build server, giving it access to internal code-signing infrastructure and the ability to create malware indistinguishable from legitimate Adobe software. One of the earliest examples of using code signing to disguise malware as legitimate software, the Adobe compromise begat a trend. Attacks using stolen or altered code signatures are littered throughout this paper’s dataset.

In addition to stealing or forging certificates, attackers can also buy them from vendors online. These certificates could have been obtained through system access, but they can also come from mistakes (certificate authorities, or CAs, can be tricked into giving attackers legitimate certificates), insiders (employees with access to keys can sell them), or resellers (intermediate certificate issuers who require far less due diligence). The marketplaces are limited by the number of legitimate certificates issued, but they have been growing. The more expensive the certificate, the more trusted it is. The cost of a certificate is anywhere up to approximately $1,800 for an Extended Validation certificate issued by Symantec in 2016. CAs can revoke certificates that have been compromised and issue new ones, but the systems of reporting, intermediaries, and automatic revocation checks are slow to close security gaps. Moreover, without purchasing them off the black market and risking being defrauded, it is hard to know when certificates have actually been compromised until they are used in an attack. (Read more about certificate marketplaces here and here).

2.3 Breaking the chain: Hijacked updates

This section explores trends in where attackers targeted the software supply chain, focusing on the use of hijacked software updates. Across both attacks and vulnerabilities, supply chain service providers, third-party app stores, and hijacked updates are popular distribution vectors. Supply chain providers are instances where attackers insert their code in software used by a vendor who pass it on to customers, for example, HVAC climate control services, firmware providers, or maintenance and service firms. These providers enable malicious code to spread by connecting malware to targets via intermediary services: from 5G providers to creators of intermediary software running PDF viewers to the authors of mobile apps, ICS systems, and car media player programs. Figure 7 shows the change in distribution vector for attacks over time.

Software updates are a major trust mechanism in the software supply chain and they are a popular vector to distribute attacks relying on compromised or stolen code-signing tools. Hijacking update processes is a key component of the more complex and harmful software supply chain attacks. The majority of hijacked updates in this report’s dataset were used to spread malicious code to third-party applications as new versions of existing software and open-source dependencies spread malware inserted into open-source libraries. One example is GOM Player, a free media application. On January 2, 2014, suspicious activity was detected in the reactor control room of the Monju fast breeder reactor facility in Tsuruga, Japan. A routine software update for the free media player GOM Player, a popular substitute for Windows Media Player, especially in parts of Asia, had been compromised to include malware, which gave the attacker access and the capability to exfiltrate information. In the case of the Monju reactor facility, this information was more than 40,000 internal emails.

The Monju attack demonstrated the pernicious ease of a compromised update. Attackers were able to capitalize on the trust users placed in updates. Compromise required little more than the press of a button on a seemingly legitimate update to spread the attack. Despite likely not being an intentional target, the Monju reactor facility fell victim to an attack on a widely popular but simple media player—underlining how the tangled nature of software supply chains can easily bring innocuous code to high-consequence targets. Figure 8 illustrates the frequency of different attack and distribution vector combinations in our dataset.

Hijacking updates generally requires accessing a certificate or developer account, versus app store and open-source attacks which can rely on unsigned attacker-made software. CCleaner is a great example. In September 2018, Cisco Talos researchers disclosed that the computer cleanup tool had been compromised for several months. Attackers had gained access to a Piriform developer account and used it to obtain a valid certificate to update the CCleaner installer to include malicious code that sent system information back to a command and control (C&C) server. The attack initially infected more than two million computers and downloaded a second, stealthier payload onto selected systems at nearly two dozen technology companies.

Across the data we collected, hijacked updates were most commonly used to target third-party applications like CCleaner. While attackers targeting CCleaner penetrated its developers’ networks and stole their signing certificates, there are other examples of brute force abuse. The Flame malware, discovered in 2012, leveraged an MD5 hash collision to forge semi-valid code signatures. Code-signing certificates are also available on underground markets. The most trusted, secure certificates go for as little as $1,600—a drop in the bucket for nation-state attackers, and not prohibitively expensive for criminal enterprises. Figure 9shows this distribution vector by targeted codebase relationship changing over time across this report’s dataset. The relationship in third-party code remains consistent but this shows a more episodic pattern with first-party OS/applications and open-source software.

Figure 9. Changes in targeted code by distribution vector over the years

Hijacked updates rely on compromising build servers and code distribution tools. Rarely do attacks involve brute force assaults against cryptographic mechanisms. The implication is that many of the same organizational cybersecurity practices used to protect enterprise networks and ensure limited access to sensitive systems can be applied, if only more rigorously, here to address malicious updates. The update channel is a crucial one for defenders to distribute patches to users. Failure to protect this linkage could have dangerous ripple effects if users delay applying, or even begin to mistrust, these updates.

2.4 Poisoning the well: Open-source software

As software continues to spread at an unprecedented pace, developers are under pressure to create new products and services ever faster and at lower cost. Open-source software is a crucial layer in the software ecosystem that needs more effective protection and is under-addressed especially as many vulnerabilities are hidden under layer after layer of dependencies. Looking across the software supply chain, there are a variety of types of codebase interleaving in a complex web of dependencies. Even larger-scale proprietary projects like the Windows operating system integrate large amounts of open-source code. How these projects are built and managed can shed light on the feasibility of widely adopting best practices for things like code integrity and long-term updates.

There are two significant, and distinct, cultures of software development: open-source and proprietary. Both shaped by the principles of their communities and the legal status of their products. Proprietary software is code owned by a single individual or organization. Some of the most well-known examples of proprietary code are Microsoft Windows, Adobe Flash Player, Skype, and Apple’s iOS. Apple’s iOS is developed in house, a product of the Cupertino giant’s design, market research, and myriad development teams. Thus, the vast majority of software produced for iOS is controlled, updated, licensed, and sold by Apple without outside development.

In contrast, an open-source community is defined as “an interacting, self-governing group involved in creating innovation with members contributing toward a shared goal of developing free/libre innovation.” Open-source developers voluntarily collaborate to develop software that is valuable to them or their organization. Open source has become the bedrock of technological innovations like cloud computing, software-as-a-service, next generation databases, mobile devices, and a consumer-focused Internet. Figure 10 aggregates this evolving attack surface by looking at just attacks and vulnerabilities targeting proprietary versus OSS codebases.

Most open-source projects do not follow strict organizational structures, instead relying on self-organization and a collaborative approach to drive software innovation and development. Open-source projects “give away” part of their intellectual property in order to create and benefit from a larger marketplace of ideas. Open source has given rise to a complex social web, with some supportive of limited and general copyrights even for code which is never sold, and others objecting to anything less than free software. Richard Stallman, founder of the GNU project and co-founder of the League for Programming Freedom, is famously quoted as saying “free software is a political movement; open source is a development model.” Stallman believes that, like speech, people should be free to code whatever and whenever they want.

The left-pad affair

Despite the destructive potential of software supply chain attacks, little has been done to impose a cost on even the most basic; some attacks happen purely by accident. An npm publisher, Azer, removed 273 packages from the online JavaScript repository, including left-pad, a simple but commonly relied on program that pads a string with zeros on its left. So many programs relied on Azer’s left-pad, or programs that relied on left-pad, or programs that relied on programs relying on left-pad (ad nauseam) that hundreds of failures per minute occurred before npm republished the package two hours later, leading some users to claim that Azer “broke the Internet.”

There are two major types of OSS. Project or community-based OSS is the most common example: a distributed community of developers who continuously update and improve a codebase.

Ruby is a classic example of open-source development. It is a community-based open-source codebase created in 1995 by Yukihiro “Matz” Matsumoto with a focus on “simplicity and productivity.” Twitter, Hulu, Shopify, and Groupon are just a few well-known sites built with Ruby. Individuals can manage their own packages and dependencies on a day-to-day basis to ensure their quality. Using a collection of package, version, and gem managers, as well as the web framework Ruby on Rails, the Ruby codebase is diverse and constantly growing. Attacks on Ruby feature in four different incidents in the dataset including a March 2019 attack on the “strong_password” gem which inserted a backdoor into code used to evaluate the strength of passwords on websites. The gem was downloaded more than 500 times before a single developer auditing the code noticed the change.

The second, less intuitive type of open-source project is commercial open-source software (COSS). The major difference between the two is that COSS has an owner with full copyright, patents, and trademarks despite its development by a broader community. Up until its purchase by IBM in 2019, Red Hat was the largest COSS entity in the world. The company runs and operates an eponymous distribution (version) of the Linux operating system. Linux has existed since 1991 and is found in everything from cars and home appliances to supercomputers. Red Hat maintains profitability by giving away its OSS, but charging customers for support, maintenance, and installation.

While proprietary code is owned by a single entity code and generally sold for profit, it can include open-source elements either directly or as part of a network of software around the product. MacOS is famously based in large part on the FreeBSD (Berkeley Software Distribution) version of Unix, and Windows 10 now includes a Microsoft-developed version of the full Linux kernel.

The open-source development model is extremely flexible and can achieve all sorts of software functionality through a multitude of different development communities. Apache software is developed and maintained by the Apache Software Foundation and is the most widely used free web server in the world, running 67 percent of all web servers. OpenSSL is a software toolkit that implements the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols The project is maintained by designated management and technical committees, and all development is meant to follow a set of established bylaws. OpenSSL does emphasize security bug reporting. Large-scale vulnerabilities in OpenSSL have been disclosed in the past—most notably, Heartbleed. Although Heartbleed was a serious vulnerability that gave malicious individuals access to hundreds of computers, it did have one positive side effect—OpenSSL received more than $300,000 in funding from major tech companies to hire new full-time developers. After years of operating while severely underfunded and understaffed, this kind of funding was an important first step for the open-source project. Figure 11 illustrates the distribution of targeted code types, including open-source software, by different types of attackers.

Attacks on OSS have grown more frequent in recent years. In February 2020, two accounts uploaded more than 700 packages to the Ruby repository and used typosquatting to achieve more than 100,000 downloads of their malware, which redirected Bitcoin payments to attacker-controlled wallets. Many of these attacks remain viable against users for weeks or months after software is patches because of the frequency with which open source projects patch and fail to notify users. Repositories and hubs can do more to help, providing easy to use tools for developers to notify users of changes and updates and shorten the time between when a vulnerability is fixed and users notified.

2.5 Downloading trouble: App hubs/stores under attack

App hubs/stores were a popular means of disseminating two-factor authentication. Still more provide a window to massively popular platforms like Facebook, Instagram, and Snapchat, which are sometimes onlyaccessible from mobile devices. As a consolidated venue, app stores simplify the user’s search for software that maximizes the value of their devices. However, as a high-traffic download center that connects end users to third-party developers, app stores have become a popular way to attack the software supply chain. Figure 12 shows the number of incidents we observed for different app stores.

Improving the security of software available through major app hubs like Google Play Store and Apple’s App Store must be a priority for developers and the software industry. The vulnerability of these hubs has long been recognized. It is an increasing source of risk to the national security enterprise as relatively innocuous services like Strava can be used to compromise the location, health, and welfare of military personnel. The app store model continues to weather a storm of attacks due to the difficulty of vetting the third-party products at its heart. Malware obfuscation techniques have continued to evolve, and the volume of apps that need screening has also increased.

App store attacks generally unfold in one of three ways. Attackers can build their own apps, designed to appear legitimate, perhaps providing wallpapers, tutorial videos, or games. Hidden in those applications, which might function as advertised, is malicious software. Sometimes when attackers create their own apps, they try to impersonate legitimate ones either through typosquatting or by posing as updates (the difference being that the latter will not provide functionality to the user). One example is the ExpensiveWall attack, named after one of several apps that attackers uploaded to the Google Play Store, Lovely Wallpaper, which provided background images for mobile users. The malicious software in the apps evaded Google Play’s screening system using encryption and other obfuscation techniques. The malware, once downloaded, charged user accounts and sent fraudulent premium SMS messages, driving revenue to the attackers. It could also be easily modified to extract sensitive data and even microphone recordings from victims’ machines. The malware was eventually found in more than 50 apps cumulatively downloaded between 1 and 4.2 million times before they were removed from the store (installed apps remained on devices until users opted to remove them).

Attackers can also repackage apps, meaning they take a legitimate app, add their own malicious code, and then bundle it as a complete item for download, usually on third-party sites. In one case, attackers repackaged Android versions of Pokémon Go to include the DroidJack malware, which could access almost all of an infected device’s data and send it to an attacker C&C server server by simply asking for extra app permissions. The attackers placed the malware-infested app on third-party stores to take advantage of the game’s staggered release schedule, preying on users looking for early access to the game.

There is also publicly available evidence that groups compromise the software used to build apps, also known as software development kits (SDKs), allowing them to inject malware into legitimate apps as they are created. Whatever the model, malicious actors make an effort to obfuscate their malware to evade detection by app store curators. Compromising development tools used to build apps for those stores provides tremendous scale in a software supply chain attack. One example is the XcodeGhost malware, first detected early in the fall of 2015. Xcode is a development environment used exclusively to create iOS and OS X apps. Typically, the tool is downloaded directly from the App Store, but it is available elsewhere on the web outside Apple’s review. A version of Xcode found on Baidu Yunpan, a Chinese file-sharing service, came embedded with malicious logic that modified apps created in the development environment. Each app created with XcodeGhost relayed information about a customer’s device once the app had been downloaded, such as time, location, name of device, and network type. It also allowed attackers to phish credentials, open URLs, and access a device’s clipboard, which can often contain password and payment information. This version of Xcode was later dubbed XcodeGhost.

Multiple apps created with XcodeGhost were accepted into Apple’s App Store, including malicious versions of WeChat, WinZip, and China Unicom Mobile Office, eventually impacting more than 500 users. XcodeGhost aptly demonstrates the significance of app stores as a distribution method. While Apple’s App Store is generally more rigorously policed, we recorded four successful attacks targeting it compared with more than a dozen against Google Play Store and other third-party distributors. These venues are attractive targets as the sheer scale of the attack’s blast radius demonstrates.

Recommendations

Software supply chain attacks remain popular, impactful, and are being used to great effect by states. The sustained growth of software supply chain attacks is caused at a technical level by continued failure to secure code integrity. Attackers continue to find ways to access accounts and bypass code signing, app stores struggle to verify the innocuity of all their software, developers embed insecure design choices at the lowest level of computing, and vendors have difficulty fully grasping the scope of their software dependencies and reliance on supply chain service providers. These are complex technical challenges with neither easy nor immediate solutions, and they further complicate the lapse in policy progress to secure a supply chain that has grown critical to industry and national security.

The most disconcerting trend of this entire dataset is the consistency with which these attacks occur against sensitive portions of the supply chain—this is not a new problem. A 2010 report from Carnegie Mellon University’s Software Engineering Institute profiled the DoD’s concern that “security vulnerabilities could be inserted into software.”

Progress to improve the security of these supply chains has been halting for a multitude of reasons. Open-source projects continue to play a central role in enabling new software products and services, and fill critical gaps in the security architecture of the Internet. Despite this, efforts to better resource and secure these projects, like the Linux Foundation’s Core Infrastructure Initiative, remain too few and under-resourced relative to the problem. Standards and existing security tools are too often applied with a “check-once-at-one-point-in-time” mindset. Scanning for vulnerabilities and working to remediate them is a constant process. Auditing the trust of an update channel, verifying the integrity of new code in a production environment, and assessing risks from third parties and open-source packages must be ongoing activities.

Policy efforts which proliferate practices, protocols, standards, and codes of conduct which can’t be automated or which are not straightforward to implement at compile or commit time are insufficient to the problem. Software developers thrive on tools and dynamic means to implement controls on their code. Some public sector agencies have begun to better acknowledge this. The NSA recently open sourced a well-featured reverse engineering tool called Ghidra alongside a host of small programs to ingest and analyze large security datasets. This is far from the norm, however, and more can be done both to tie security standards efforts to automation and tooling as well as push for more DoD, Department of Homeland Security (DHS), and NSA tools to be open sourced and made publicly useful.

Many of these recommendations focus on the role of DHS’ Cybersecurity and Infrastructure Security Agency (CISA) and could be improved through CISA’s collaboration with the NSA’s still new Cybersecurity Directorate. While there are flashes of sibling rivalry between the two, together they would leverage a significantly deeper pool of technical expertise and security acumen than alone. Failure to collaborate would impact not only efforts to improve open-source security but also the proposed improvements to baseline software supply chain security and efforts to counter systemic threats. In many cases we advocate for a CISA or NSA role in particular efforts but there is substitutability.

The United States and its allies cannot afford drive-by reforms. Sustained improvement is necessary. The power of the software supply chain is how it enables rapid and often low-cost change in the functionality of complex systems. This same rapidity can be the undoing of users and organizations. Policy makers should focus on supporting industry efforts to improve the supply chain security baseline and collaborate to reduce the impact of state attacks. Risk is the name of the game—not bought completely away or mitigated through whiz bang technology but managed deliberately, thoughtfully, and consistently. In this the report owes an intellectual debt to numerous prior efforts but particularly three reports, the New York Cyber Task Force’s Building a Defensible Cyberspace, MITRE’s Deliver Uncompromised, and the Carnegie Endowment Cyber Policy Initiative’s ICT Supply Chain Integrity: Principles for Governmental and Corporate Policies.

Software will continue to “eat” the world and these recommendations are meant to support that—enabling more effective risk management and improved security practices broadly to raise the baseline cost of software supply chain attacks and reduce the impact of the most consequential:

3.1 Improve the baseline

Software supply chain attacks and disclosures that exploit vulnerabilities across the lifecycle of software in this dataset are too cheap relative to the harm they can impose. For example, while software updates are the critical channel to bring updates and patches to software users, they have been hijacked consistently over the past decade. The problem is generally not developers brewing their own cryptographic protections or poorly implemented accepted protocols but failing to rigorously implement basic protections for their networks, systems, and build servers.

This cluster of recommendations is intended to reduce the complexity and burden of implementing secure software supply chain practices across organizations and software projects of all sizes. The central pillar is a new “Life Cycle Security Overlay” for Special Publication (SP) 800-53 developed by the National Institute of Standards and Technology (NIST), which integrates other identified industry best practices. SP 800-53 is one of the most complete bodies of security controls and has global visibility through the Cybersecurity Framework. SP 800-53 is not perfect; it locks in an impact-centric model of auditing and assurance and often trades compliance for risk management, but it is a tool in hand and far more useful today than an as-yet undeveloped specification many years out.

Raising the cost of software supply chain attacks should center on providing the whole of industry, from SAP and Microsoft down to a three-person LiDAR startup, easy-to-use tools and well-defined reference implementations for major cloud and IT vendors that make rigorous security as low-effort and cheap as possible. Efforts to build an assessable maturity model , identify reference implementations for this Overlay, and build an open-source tooling to support these implementations all build from the Overlay itself. These would provide resources to developers as well as a framework to measure software supply chain security performance in federal contracting, opening the possibility that such measures could trickle down into the private sector and be enforced within segments of the technology marketplace. These steps also support implementation of recommendations made by others on improving operational coordination and developing security metrics necessary to “build solutions that scale at least cost for greater security.” Finally, this section calls for an organization to maintain the value of these tools over time, collecting, curating, and caring for the most useful long into the future.

FIRST

1. Life cycle security overlay [NIST and Industry]: Develop a software supply chain security Overlay to NIST SP 800-53, wrapping in controls from existing families, the new supply chain family in 800-53 rev5, and best practices collected in the Secure Software Development Framework (SSDF) and related industry and open-source publications like the BSA Framework for Secure Software.³ This recommendation builds on the strong network and expertise of NIST and follows on previous recommendations to anchor technical security obligations in standard-setting organizations.

a. Sector-specific agencies implement overlay [NIST and SSA Working Groups]: The NIST Overlay team should support appropriate sector-specific agencies to set up implementation working groups with industry partners focused on using this Overlay in their own development and contracting with third parties. NIST should feed requests for more specific controls or guidance into an 18-month revision cycle, producing additional guidance or changes to the Overlay as needed, for example, for industrial control systems in the energy sector.⁴

2. Bring the overlay to the cloud [Industry, Especially Cloud Service Providers]: Many software developers rely in whole or in part on cloud vendors to host, distribute, and maintain their codebases. Industry can assert moral leadership on software supply chain security issues and realize practical financial advantages by offering public reference implementations of the Overlay in their services and lower the complexity of secure life cycle practices for customers. Major cloud providers, namely Amazon, SAP, Microsoft, Google, Dell, and IBM, should build on existing industry organizations and collaboration to lead joint development of these reference implementations and make them freely available on government and industry partner websites.

a. Integrate and grow the SBOM [NIST and the National Telecommunications and Information Administration]:NIST and NTIA should integrate the draft Software Bill of Materials (SBOM) standard developed by the NTIA multi-stakeholder process into this reference implementation material. NTIA should continue to evangelize on the role and utility of software transparency, leading a standing multi-stakeholder working group on SBOM.

3. Release the tools! [DoD and Industry]: Companies and open-source projects, including the cloud providers above, should commit to release tooling to help implement the Overlay. These industry efforts should be joined in parallel by the office of the DoD Chief Information Officer, the Defense Digital Service, and the Defense Information Security Agency as well as any other significant software development efforts within the federal government. An encouraging sign of the DoD’s commitment to this policy would be a new instruction from the secretary of defense modifying and updating DODI 8500.01 accordingly.

4. Harmonize the overlay [NIST, DHS CISA, and ENISA]: NIST, DHS CISA, and ENISA should work with industry partners and the international standards community to map this Overlay to appropriate ISO controls and the EU Cybersecurity Certification Framework to harmonize standards across the transatlantic community.

5. Recognize software is part of 5G [State Department and NSC]: The State Department and the NSC’s efforts to shape a like-minded coalition for the United States on 5G security issues has produced variable results but is driving strong industry, and some international, pressure for a more open telecommunications technology marketplace. Much of that push is a result of industry trends towards virtualizing complex hardware functions in software. Starting with the EU, the State Department and NSC should work with civil society and industry to make software development and supply chain security principles a core part of the 5G coalition-building process.

OVER THE HORIZON

6. Measure overlay maturity [NSA and Industry]: NSA’s Cybersecurity Directorate should work with an appropriate industry consortium to develop a software supply chain security maturity model based on this control Overlay and make it publicly available.

a. Tie overlay to CMMC [DoD]: The DoD should integrate this supply chain maturity model as part of its Cybersecurity Maturity Model Certification (CMMC) program and establish a level of performance required for prime contractors. The DoD should further implement these performance measures as new contracting requirements for information technology procurement.

b. Assess overlay performance in IT contracting [General Services Administration]:GSA should establish similar performance measures against this maturity model and implement them as part of evaluating new federal information technology contracts.

3.2 Better protect open source

One of the popular distribution vectors for software supply chain attacks in this report’s dataset was open-source packages and libraries. These are rarely the most consequential attacks, but they are often exploited through trivial effort, pointing to a concerning trend given the wide dependence on open-source code in commercial and national security applications. Continuing efforts by the White House to incorporate open-source software as a means of sharing code across different agencies and with the technical public raise the stakes of securing open-source software development.

This cluster of recommendations aims to support more effective and consistent security practices across open-source projects and in the governance of repositories and code registries. Policy makers should not endeavor to “fix” the open-source community. There is no one open-source community and effective change comes from resources, tools, education, and time—not trying to upend cultures.

These recommendations provide additional resources for security in the open-source community, including grant funding, public sector support and policy evangelism for best practices, and industry incentives to build in tools for supply chain security to hubs and repositories.⁵ Executed together, these changes should improve the health of open-source software, use federal funding to support private sector leverage over attackers, and help raise the bar for secure supply chain practices at important points of industry and community concentration. These policies should also help improve the stability of open-source security efforts and the long-term viability of other recommendations in this report by supporting channels between the public and private sectors. They should also help account for the rapidly growing use of containers in cloud service deployments, including registries and hubs for container and other cloud images.

FIRST

7. Pay up [US Congress and DHS CISA]: Open-source software constitutes core infrastructure for major technology systems and critical software pipelines. The absence of US public support to secure these products, at a cost point far below what is spent annually on other domains of infrastructure security, is a striking lapse. The US Congress should appropriate suitable funds, no less than $25 million annually, and unambiguous grant-making authority, to DHS CISA to support baseline security improvements in open-source security packages through a combination of spot grants up to $500,000 administrated in conjunction with the US Computer Emergency Response Team (US-CERT), and an open rolling grant application process.

8. Stand and deliver [DHS CISA]: In line with the identification of open-source projects as core infrastructure, DHS CISA should create a small (six to eight-person) open-source security evangelism and support organization. This group should help administer funds in the previous recommendation, drive collaboration with US allies and others in the private sector to support priority open-source packages, and act as community liaison/security evangelists for the open-source community across the federal government. The first project for such a group should building a dependency graph of as much of the open source ecosystem as feasible, identifying priority projects for investment and support.

9. Curate and maintain tooling [CMU’s SEI and Linux Foundation]:TheDoD should create a new nonprofit entity in the public domain supported by Carnegie Mellon University’s Software Engineering Institute (SEI) and Linux Foundation’s staff and networks. SEI should support the organization as a principal contractor funded via indefinite delivery/indefinite quantity contract from the DoD, at an amount not less than $10 million annually. The Linux Foundation should manage a priority list of software tools and open-source projects to invest in and support.This entity should support the long-term health of the software supply chain ecosystem by maintaining, improving, and integrating software tools released as part of the Overlay effort, making them freely available with expert integration assistance and other appropriate resources.

10. Transatlantic infrastructure initiative [DHS CISA and the State Department]: Software security is not a single-jurisdiction issue. DHS CISA and the State Department’s Office of the Cyber Coordinator should work with US allies in Europe to establish a Transatlantic Infrastructure Initiative (TII) modeled on the DHS open-source security funding program. Working with ENISA and cooperative partners in the region, the TII could establish a consensus collective security mechanism to support the security of critical open-source packages and help validate the global significance of effective trust in the supply chains for this software.

OVER THE HORIZON

11. Bring lawyers, guns, and money [US Congress/Federal Trade Commission]: The US Congress should extend final goods assembler liability to operators of major open-source repositories, container managers, and app stores. These entities play a critical security governance role in administering large collections of open-source code, including packages, libraries, containers, and images. Governance of a repository like GitHub or an app hub like the PlayStore should include enforcing baseline life cycle security practices in line with the NIST Overlay, providing resources for developers to securely sign, distribute, and alert users for updates to their software. This recommendation would create a limited private right of action for entities controlling app stores, hubs, and repositories above a certain size to be determined. The right would provide victims of attacks caused by code, which failed to meet these baseline security practices, a means to pursue damages against repository and hub owners.⁶ Damages should be capped at $100,000 per instance and covered entities should include, at minimum, GitHub, Bitbucket, GitLab, and SourceForge, as well as those organizations legally responsible for maintaining container registries and associated hubs, including Docker, OpenShift, Rancher, and Kubernetes.

3.3 Counter systemic threats

While there is much progress to be made in providing better tools, incentives, and resources to secure software supply chains, the United States and its allies can also take positive action to call out and counter systemic supply chain threats. This final cluster of recommendations works to broaden existing US partnerships to better reflect a consensus coalition on cybersecurity issues, widen the basis of cooperation to include regular operational collaboration as well as political coordination on law enforcement and intelligence issues, and provide better information to the public on software supply chain risks. Many of these recommendations build on existing relationships and informal partnerships with allies and the private sector.

The abuse of software supply chains undermines trust in the technology ecosystem. Where new or exotic techniques are identified to attack the supply chain, the United States and allies should work to interdict malicious actors and blunt the consequences of these attacks. This section addresses potential actions from shifts in alliance composition to reshaping the focus of interagency equities. The goal of these recommendations is to provide a more concrete basis for statecraft to counter the highest-consequence software supply chain attacks and improve the quality of information available to decision makers and the public on systemic software supply chain threats and the activities of major state actors.

FIRST

12. Know Your enemy [Office of the Director of National Intelligence]:Acting on behalf of the director of national intelligence, the assistant director of the Supply Chain and Cyber Directorate and the national intelligence officer for cyber, with appropriate members of the Intelligence Community and interagency, should produce a study on the nexus between state adversary groups and criminal organizations in any major software supply chain security attack from the past decade. This study should be shared in its entirety with key US allies, including the United Kingdom, Japan, Australia, the Netherlands, Poland, and Estonia, and should include a limited public component released within six months of the study’s conclusion.

13. Trust busters [UK National Cyber Security Centre, DHS CISA, NSA, and DoJ]: Building on existing collaboration between CISA, the NSA, and the UK’s NCSC, an expanded international group should work to share information on systemic software supply chain attacks and disclosures, cooperate on investigations against responsible groups, and define policies for collective attribution of state actors. NCSC, in particular, offers well-established relationships with telecommunications providers and a strong base of talent to collaborate on such a joint effort.

a. Broaden the tent [DHS CISA and NSA]: DHS CISA and the NSA should work to include, and routinize with, a broader array of US allies in regular security collaboration, investigation, and joint attribution on software supply chain security events. These allies should include the same states as in recommendation twelve above.

14. Work for IT [US and allied governments]: The root of most software supply chain security protections is strong cryptography. Efforts by the United States and other governments to incentivize adoption of weak or compromised cryptographic standards work at cross-purposes with widespread industry practitioner and policy maker consensus. These efforts also present systemic threats to an already porous software supply chain. The legacy of US attempts to block the sale of “strong cryptography” is recurring attacks on weaker encryption standards and widespread access to previously controlled technologies. The United States and its allies should work in support of strong and accessible cryptographic standards and tools for developers.

15. Know Thyself [Cybersecurity Tech Accord or Charter of Trust]: Industry, working through the Cybersecurity Tech Accord or the Charter of Trust, should annually survey and publish public instances of software supply chain attacks which undermine trust in software updates, code integrity, or distribution channels like public open-source repositories. Each group has an opportunity to assert meaningful leadership on software supply chain security issues with such an effort. These attacks are the evidentiary basis for motivating new investment in supply chain security. Transparency around their frequency and cost are important inputs to public debate.

16. SBOM Squeeze [State Department Cyber Coordinator and Department of Commerce NTIA]: The Departments of Commerce and State should collaborate to further internationalize the SBOM effort. Commerce has worked effectively to drive bottom-up engagement, while State should support with a top-down advocacy effort. The transparency associated with SBOM will help surface vulnerabilities and weaknesses which support broader US alliance efforts on cybersecurity. State and Commerce should focus on Germany, the Netherlands, the United Kingdom, Japan, South Korea, and Australia—leading with the German Federal Office for Information Security (BSI) and Japanese Ministry of Economy, Trade and Industry (METI) to start.

OVER THE HORIZON

17. Security for a Common Good [NSA, NCSC, other Vulnerabilities Equities Process ]: The NSA and the United Kingdom’s NCSC should encourage more frequent and fulsome disclosure of known vulnerabilities, or attractive primitives, in key mechanisms of trust for the software supply chain, particularly code signing and means to bypass firmware protections and hardware roots of trust. The process of determining whether to disclose or keep secret an impactful software vulnerability is inherently a tradeoff between different government agencies and as well as divergent conceptions of the public good. This recommendation aims to further tip the scales in favor of disclosure where the subject software vulnerability is principally useful for impersonating legitimate software updates and developer-signed code—the kind whose use, and potential theft or rediscovery, risks further corroding a critical linkage of trust between users and code maintainers.

Conclusion

Supply chain security risk is growing and increasingly manifesting as harm to software users. There are many steps between the codebase they first compromise and their final targets, so the distribution vectors of attack—how they ripple across the supply chain—are just as varied as the first point of impact, though the two are often connected. Popular methods of attack include taking advantage of automated updates, compromising software development applications, and sneaking into mobile app stores. Even the act of infiltrating the supply chain with malware is intricate, involving stealing or forging code-signing certificates, breaking into developer accounts, or unearthing hardcoded default passwords.

Software supply chain attacks are first and foremost about variety—a variety of attackers ranging from undergraduate students to the world’s most sophisticated state offensive cyber groups, of targets that range from uranium enrichment centrifuges to mobile video games, and of impacts that can result in multi-billion-dollar losses, rampant data interception, or absolutely nothing. The supply chains underlying final products grow longer and less linear over time. In this interconnected software environment, successful attacks migrate away from the final targets that harden their own vulnerabilities and toward the weakest links in those chains. The soft spots that software supply chain attacks target remain minimally protected because of the technical challenges of recognizing the full scope of a product’s code dependencies and the policy challenges of coordinating disclosure and patching.

A consistent pattern of attacks and disclosures target software supply chains. Despite this, these supply chains remain poorly secured and policy maker attention on supply chain issues is distracted by the 5G debate. This ignores a critical national security risk posed by insecure software supply chains, namely: the accumulated harm to private sector firms impacted by untrustworthy code and a generation of defense systems reliant on commercial software. Software supply chain attacks are popular, they are impactful, and they have been used to great effect by major US adversaries. This report surveyed a decade of software supply chain attacks and disclosures—115 incidents in all—to develop a picture of the problem and develop five trends as software supply chain attacks are used to big effect, break the chain, abuse trust, poison the well, and download trouble. Building on these trends, the report recommends the policy community improve the baseline of software security for all organizations, better protect open source, and counter high-consequence supply chain threats.

It would be a grave mistake to equate software supply chain attacks to a new weapon system in an opponent’s arsenal—they are a manifestation of opportunity as much as intent, attacking secure targets by compromising weaknesses in connected neighbors and vendors. Existing gaps in best practices, and poor adoption of these best practices, have granted these software supply chain attacks unnerving sustainability. There are even signs that the most fruitful software supply chain targets in firmware and at the heart of major cloud service providers have yet to peak in popularity.

The implication of this for the technology industry and cybersecurity policymaking community is a crisis in waiting. For the national security establishment, attacks on the software supply chain threaten a generation of technology acquisitions and undermine the COTS model of development. As the recommendations of this report bear out, change is necessary and feasible but it will require concentrated purpose and clarity of outcome at a time when both are in short supply. This report finds evidence that the past decade has seen software supply chain attacks become only more common and effective. Without action, the next decade may be worse.

Staff

Trey Herr

Senior Director

Cyber Statecraft Initiative Digital Forensic Research Lab

Cybersecurity Digital Policy

Fellow

Will Loomis

Nonresident Fellow

Cyber Statecraft Initiative Digital Forensic Research Lab

Cybersecurity

Staff

Stewart Scott

Associate Director

Cyber Statecraft Initiative Digital Forensic Research Lab

Cybersecurity Disinformation

Breaking trust

This report evaluates a dataset of 161 software supply chain attacks and vulnerability disclosures collected from public reporting over the past 10 years to show that software supply chain attacks are popular, impactful, and used to great effect by states. Software supply chain attacks provide huge value for attackers and remain popular.

These attacks are impactful, giving attackers access to critical infrastructure like electrical power generation and nuclear enrichment systems. States like Russia, China, North Korea, and Iran attack the software supply chain as part of their offensive cybersecurity efforts.

This dataset is open and freely available for download.

Return to Project Home Explore the dataset

Issue briefs and reports Jul 26, 2020

Breaking trust: Shades of crisis across an insecure software supply chain

Software supply chain security remains an under-appreciated domain of national security policymaking. Working to improve the security of software supporting private sector enterprise as well as sensitive Defense and Intelligence organizations requires more coherent policy response together industry and open source communities.

Feature Jul 26, 2020

App stores in focus

By Trey Herr, June Lee, Will Loomis, and Stewart Scott

App stores and hubs are a popular target for software supply chain attacks on large numbers of users, exploiting trust in proprietary app ecosystems and the security of storefronts like Play Store and App Store.

Cybersecurity Technology & Innovation

Feature Jul 26, 2020

Deep impact: States and software supply chain attacks

By Trey Herr, June Lee, Will Loomis, and Stewart Scott

China Cybersecurity

The Atlantic Council’s Cyber Statecraft Initiative, under the Digital Forensic Research Lab (DFRLab), works at the nexus of geopolitics and cybersecurity to craft strategies to help shape the conduct of statecraft and to better inform and secure users of technology.

learn more

Issue briefs and reports

Fast Thinking

New Atlanticist

Inflection Points

UkraineAlert

MENASource

Econographics