Now more than ever, society depends on software. Whether it is the cloud computing behind an email service, a new fifth-generation (5G) telecommunications deployment, or the system used to monitor a remote oil rig, software has become an essential and pervasive facet of modern society – making software supply chain security remains an under appreciated domain of national security policymaking. Software supply chain attacks are popular, they are impactful, and are used to great effect by a variety of malicious actors.

To dive deeper on this topic – and the recent policy action taken to address this problem – we asked eight experts about these threats and how policymakers can help protect against them:

Two significant changes that we have seen over the course of the last several years when it comes to software supply chain exploits are 1) new, novel attack patterns such as dependency confusion and 2) more sophistication and opportunistic attacks – including supply chain attacks priming another supply chain attack. Dependency confusion attacks exploit the fact that many package managers – including pip, npm, and RubyGems – pull from public code registries for a package before private registries. If a specific package exists in a private registry, an attacker could register a package of the same name with the public registry – thus pulling down the malicious version on the public registry when a new install occurs. These attacks are hard to mitigate and target widely used tools – making them particularly worrisome. Another new trend is using software supply chain compromises to set up and execute other supply chain compromises. The most recent example of this was the 3CX compromise, where the company was initially comprised through the use of a malware-laced version of the X_Trader financial software, and then that initial access was used to compromise the desktop version of their app. These two accelerating trends demonstrate a frustrating reality of supply chain compromises – that malicious actors are always looking to innovate.

William Loomis, Associate Director, Cyber Statecraft Initiative, Digital Forensic Research Lab (DFRL), Atlantic Council

On the one hand, the problem of attacks on accounts of legitimate open source maintainers improved, also thanks to the introduction of 2FA by different package ecosystems. However, there’s an increase of malware campaigns using techniques like typosquatting and dependency confusion, sometimes with hundreds of malicious packages published in short time frames (PyPI even had to suspend the registration of new packages in May 2023). Those attacks will continue, because the marginal costs for attackers to conduct such campaigns is very low – thanks to a high degree of automation and reuse, which renders them profitable even if very few people fall victim to such attacks. Developers need to get used to such attacks, just like we got used to email spam. What will become more critical are social engineering attacks on legitimate projects, e.g. through the submission of malicious pull requests by fake profiles, which are harder to detect than the simplistic malicious code typically contained in a typo-squatting package, for example. Going forward, we will see an arms-race on all of those fronts, as in any other IT security domain.

Henrik Plate, Security Researcher, Endor Labs; Co-author of the Taxonomy of Attacks on OSS Supply Chains and the Risk Explorer

There is more focus on capabilities that test open-source software before it is ingested into an enterprise. Such testing focuses on detecting malicious open-source software rather than just vulnerable code. This is in response to a significant increase in the amount of intentionally malicious open-source software contributed by attackers. This increase is particularly concerning as malicious open-source software is designed to deliver an exploit immediately upon ingestion into an enterprise whereas vulnerable code mainly has the potential to be exploitable and is often more of an issue when in production. 

There is also a lot of emphasis on the security of pipelines within the Software Delivery Lifecycle (SDLC) and ensuring that the basic configuration of these pipelines meets certain, specific guidelines. This ensures that even if an attacker has access to the internal SDLC, it remains protected. More recently we’ve seen a focus on bringing attestations to the SDLC so that it is possible to validate the provenance of a software artefact throughout the SDLC and into production, which makes it more difficult for an attacker to fully exploit the supply chain.

Jon Meadows, Citi Tech Fellow, CITI; Governing Board Member, Open Source Security Foundation

This is an intimidating question with a simple answer: there is no evidence that any U.S. government policies or activities have improved software supply chain security, yet. Despite the talents and efforts of many elected leaders, dedicated public servants, and concerned citizens, there is no data, analysis or you-name-it that links the relatively few concrete software supply chain security initiatives of Uncle Sam to improved software supply chain security. There are, of course, promising initiatives, such as Department of Homeland Security funding for software bill of materials (SBOM) tools or the military’s adoption of low-vulnerability count container images. But broader changes—the type that might happen after Russian intelligence agencies hijack important software updates and ride their way into government networks—have mostly remained the stuff of op-eds and think-tank seminar rooms. Email me at jsmeyers@chainguard.dev if you disagree!  

John Speed Meyers, Nonresident Senior Fellow, Atlantic Council; Security Data Scientist, Chainguard

At the Office of the National Cyber Director, our theory of the case is that in order to secure the cyber supply chain, we need to start with the atomic unit of the system. Generally speaking, many cybersecurity issues start with a line of code. That means that the most atomic unit of the cyber supply chain is the programming language itself. If the programming language is not safe, then nothing we build in that language is safe, either. The policy idea I am most excited about right now is driving adoption of memory safe programming languages. Memory safety describes the underlying property of a programming language that allows software developers to introduce certain types of cybersecurity bugs that affect how memory is used, both spatially and temporally. The main memory unsafe languages we are primarily focused on in the U.S. Government are C and C++. 

The problem around memory safety is daunting because of the high proliferation of C and C++ in our critical infrastructure. In fact, several of the big security vulnerabilities we have seen in the past two decades were caused by memory unsafety, including the Heartbleed vulnerability in 2014 and the WannaCry Ransomware attack in 2017. However, I have two reasons to be optimistic that we can succeed here.  

First, the technical solutions already exist. There are many memory safe languages all across the tech stack that we can – and should – use instead. Second, research shows that migrating code from a memory unsafe language to a memory safe language can eliminate up to 70% of the software’s vulnerabilities. This statistic is quite remarkable. Even though there are no silver bullets to securing the cyber supply chain, this is a high-impact example of where good engineering practices are intersecting with good cybersecurity policy. I believe that advocating for the adoption of memory safe languages is one of the most impactful actions the collective ecosystem can take to drive the security of our cyber supply chain. 

Anjana Rajan, Assistant National Cyber Director, White House

Due to lack of evidence it is not clear where Governments can let the free market address the challenge of software supply chain security without engagement. Whilst some vendors and end user organizations are being proactive a significant proportion has yet to mobilize The risk with any Government intervention is organizations look to compliance and the management of legal risk as opposed to addressing the intent. The systemic risk of software supply chains requires our end objective to be more than compliance and instead a life-cycle set of evidenced solutions which quantifiably improve the situation for producers and customers. 

Ollie Whitehouse, Incoming Chief Technology Officer, National Cyber Security Centre (NCSC), UK Government

The answer to this question depends on the level of ambition and available resources of governments – in a recent report, we identified three levels of government efforts. The US and many other Western states will have already covered what we call the basics, like including secure software development practices in software developer education and in workforce development efforts. In some cases, they have also put into practice tried and tested policy instruments, like requiring software-developing government agencies to develop and publish organizational coordinated vulnerability disclosure (CVD) policies and requiring such policies from organizations supplying the public sector through public procurement guidelines.

As a result, to significantly strengthen software supply chain security in the long run, they will need to invest significant resources and implement policy instruments that have not yet been widely put into practice elsewhere. Areas ripe for policy innovation in this field include regulation mandating software-developing entities to implement secure software development practices, national legal frameworks for CVD, the refinement of software bill of materials (SBOM) data formats and technical tools that build on SBOM data and regulation mandating SBOM use, and product liability regimes that cover software (or amend an existing one to include software). In doing so, governments have to assess, among other things, the impact of such interventions on small and medium enterprises and individual software developers, who may be disproportionately affected by regulatory burdens.  

Dr. Alexandra Paulus, Project Director, Cybersecurity Policy and Resilience, Stiftung Neue Verantwortung (SNV)

Most of the open-source software supply chain attacks in the dataset rely on malicious packages masquerading as legitimate open-source packages, often through typosquatting or similar techniques. Some of these impersonations are strengthened by the lack of verification of details on some open-source hosting websites, as in the dataset’s example case of StarJacking. With this technique, attackers can add credibility to malicious packages on npm, PyPI, or Yarn by displaying the GitHub statistics of other packages on the page of their package, since the package manager does not verify the connection between the GitHub link and the package. Another common variation of attacks involving open-source software relies on expired resources or links. In one case, researchers found that thousands of maintainer email accounts on npm are linked to email addresses with expired domains, which could be purchased by malicious actors to take over those accounts without notifying the maintainers. Similarly, in another case in the dataset, a package relied on an expired S3 bucket to download an add-on. A malicious actor took over the bucket and replaced the add-on with malware, which was then included in the widely used package. These cases all emphasize the importance of intentional, comprehensive tracking and management of open-source dependencies, which can help ensure companies are not affected by these relatively trivial but still very impactful techniques. 

Sara Ann Brackett, Research Associate, Cyber Statecraft Initiative, Digital Forensic Research Lab, Atlantic Council