Supply Chain Attacks: From Cold War Espionage to Modern Cybercrime

A Threat That Has Evolved Beyond Nation-State Actors

In the late 1950s, the Soviet embassy in The Hague placed an order for office furniture from a local Dutch company. This was the height of the Cold War, and American intelligence agencies had recently discovered a sophisticated listening device concealed within a gift presented to the US Embassy in 1951. The technology was more advanced than anything they had previously encountered, but once they understood it, they developed their own improved versions. When the Soviet embassy placed its furniture order, American operatives saw an opportunity and installed a listening device within the order before it was delivered. The operation was known as "Operation Easy Chair."

This is a textbook example of a supply chain attack. Rather than targeting the victim directly, the attack is directed at something the victim will receive and use. For decades, operations of this nature were considered the exclusive domain of nation-states, requiring significant resources, sophisticated technology, and the ability to either compromise hardware or infiltrate large software companies. That assumption no longer holds.

The Open Source Vulnerability

Modern software is built on open source foundations. The libraries, packages, and tools that underpin commercial products, enterprise platforms, and critical infrastructure are frequently developed and maintained by individuals volunteering their time, often without formal security oversight or the institutional protections that large organisations can provide. Contributors to these projects are frequently unknown to one another, and maintainers rarely have the time or resources to scrutinise every proposed change for malicious intent.

The result is that the concept of a supply "chain" is itself somewhat misleading when applied to modern software. There is no neat sequence of links to inspect. Instead, modern digital infrastructure resembles a web or tree of interdependent components, many of which are themselves dependent on further components. The full scope of this dependency tree is, in practice, nearly impossible to comprehend in its entirety. This complexity creates a meaningful opportunity: compromising a relatively small, obscure open source project can have consequences that reach into some of the largest organisations in the world.

A Recent and Instructive Example

A recent incident illustrates this clearly. An open source security scanning tool called Trivy was compromised. During a brief window before the issue was identified and resolved, any system that updated and ran Trivy inadvertently exposed credentials stored in environment variables and SSH configuration files.

Among the software configured to run Trivy automatically was LiteLLM, a widely used tool that simplifies access to AI models from multiple providers. By running the compromised version of Trivy, LiteLLM's access credentials were exposed to the attackers.

Those credentials were then used to publish compromised versions of LiteLLM itself. Anyone who installed versions 1.82.7 or 1.82.8 of LiteLLM potentially had AWS, GCP, and GitHub credentials exfiltrated, along with SSH keys and cryptocurrency wallet information across multiple platforms including Bitcoin, Ethereum, Litecoin, and Solana. LiteLLM counts organisations such as Stripe and Adobe among its customers.

This was not a targeted, nation-state operation in the manner of Operation Easy Chair. It was carried out by a cybercriminal group, and it was largely opportunistic. Yet the potential impact was substantial and far-reaching. Further compromises as a result are considered likely. At this point, it is not known how many keys and credentials were exposed through the use of compromised versions of LiteLLM and Trivy. Organizations and individuals running these tools should treat any exposed credentials as compromised and initiate immediate rotation as a precautionary measure.

Defending Against Supply Chain Attacks

Supply chain attacks present a genuine defensive challenge, in part because some effective mitigations run counter to conventional practice. For instance, deliberately delaying the deployment of software updates can reduce exposure to these incidents, since compromised versions are often identified and removed relatively quickly. This sits in tension with the usual guidance to apply updates promptly, and navigating that balance requires careful judgement.

More broadly, no single control is sufficient. A layered, defence-in-depth approach remains the most effective posture, combining technical controls, monitoring, and a clear understanding of the software and dependencies an organisation relies upon.

Understanding your exposure, knowing what software your organisation depends on and how deeply those dependencies run, is a reasonable starting point for any organisation looking to take this threat seriously.