No organisation operates in isolation. Businesses rely on third-party software, cloud providers, managed services and suppliers to keep operations running smoothly. But that reliance comes with risk. Supply chain attacks exploit trusted relationships, allowing attackers to breach an organisation not by targeting it directly, but by compromising one of its vendors instead. The result? Even the most mature security programmes can be undermined by a single weak link.
Over the past few years, high-profile supply chain breaches have shown just how far-reaching the impact can be, from operational disruption and data loss to regulatory fallout and reputational damage. What makes these attacks particularly dangerous is their stealth, attackers hide within legitimate updates, tools or services, often remaining undetected for months while moving laterally across networks.
In this blog, we’ll break down what a supply chain attack is, explore real-world examples that demonstrate their scale and sophistication, and outline steps organisations can take to reduce risk. Because when trust is the attack vector, understanding and preparation become your strongest defences.
How a supply chain attack works
Modern software is not built from scratch, it’s assembled. Developers routinely reuse existing components to save time, reduce cost and avoid reinventing the wheel. These components, known as libraries or dependencies, handle everything from encrypting data to communicating with APIs. It’s a smart and efficient approach, but it also introduces hidden risk.
Because libraries themselves rely on other libraries, software quickly becomes a layered stack of interdependent code. One application might directly include dozens of libraries, each of which quietly pulls in dozens more. This creates a dependency chain that is largely invisible to the people building and maintaining the software.
A supply chain attack takes advantage of this complexity. Instead of attacking an organisation head-on, an attacker compromises a trusted component somewhere upstream, often a widely used library or vendor tool. When that compromised component is distributed downstream, every piece of software that relies on it inherits the vulnerability, often without any obvious warning signs.
Imagine an application that uses a library called CatCounter, which in turn relies on CatDetector and CatMaths. From the developer’s perspective, only CatCounter is visible. But if a vulnerability is later discovered in CatMaths, the application is still affected, even though CatMaths was never explicitly installed or reviewed. Scale that scenario up to a real-world enterprise environment with 50 direct dependencies, and you could be unknowingly exposed through hundreds or even thousands of indirect ones.
That is what makes supply chain attacks so dangerous. They exploit trust, obscure visibility, and expand the impact of a single compromise across countless organisations. All through software that was assumed to be safe.
This risk is perhaps best illustrated by xkcd-2347, which humorously depicts a vast stack of critical infrastructure resting on a tiny, under-maintained personal project.
Example 1 – Log4Shell
In November 2021, a critical vulnerability was discovered in Log4J, one of the most widely used logging libraries in the world. Dubbed Log4Shell, the flaw allowed attackers to execute arbitrary code on a system simply by getting a malicious string recorded in a log file. The severity was unprecedented, a rate of 10/10 with potential impact across billions of devices, websites and services worldwide. Many of those affected organisations did not even realise they were using Log4J. The Director of the US Cybersecurity and Infrastructure Security Agency (CISA) described it as “one of the most serious vulnerabilities I’ve seen in my entire career, if not the most serious”. Making matters worse, exploitation was trivial; even novice attackers were able to weaponise it quickly.
The real-world impact was vast and immediate. Estimates suggested that around 93% of cloud environments (wiz.io) were vulnerable, tens of thousands of government websites were taken offline, and everything from enterprise systems to critical infrastructure, and even Minecraft servers was affected. While the exact financial cost is hard to quantify, the global damage almost certainly ran into the billions, if not tens of billions, of dollars.
Perhaps the most troubling aspect of Log4Shell was how difficult it was to assess exposure. Many organisations never directly included Log4J in their code yet remained vulnerable because it was embedded deep within other libraries and commercial products they relied on. The name “Log4J” might not have appeared anywhere in their codebase, but the risk was still there. This perfectly illustrates why supply chain attacks are so challenging to manage. Hidden dependencies obscure visibility, making it incredibly difficult to know what software you truly depend on and where the next critical vulnerability might be lurking.
Example 2 – XZ Utils
Linux underpins much of the world’s digital infrastructure, powering the majority of servers globally. As an open‑source project, its code is publicly accessible and scrutinised by a vast community of contributors and reviewers. That level of oversight makes it extremely difficult for an attacker to successfully introduce malicious code directly into Linux itself, any overt attempt would almost certainly be detected and rejected.
Instead, the attackers aimed lower down the stack. Rather than targeting Linux head‑on, they focused on one of its lesser‑known but critical dependencies, XZ Utils, a compression utility comparable to tools like 7‑Zip or WinRAR. XZ plays an important background role in many Linux systems, yet for years it was largely maintained by a single volunteer, Lasse Collin, who had been supporting the project largely on his own since 2009.
Over several years, a contributor using the name “Jia Tan” gradually embedded themselves in the project. Through persistent contributions and careful relationship‑building, Tan earned the maintainer’s trust and was eventually granted elevated permissions, enough to make changes without oversight. At first, those changes appeared benign, even helpful. But beneath the surface, Tan was methodically laying the groundwork for something far more dangerous.
Piece by piece, seemingly harmless updates were added that, when combined, introduced a sophisticated backdoor. Had it gone undetected, this backdoor could have allowed remote access to vast numbers of Linux systems, even those that never directly interacted with XZ Utils. The potential impact was staggering; critical infrastructure, government environments and enterprise servers worldwide could have been compromised, all via a single, trusted dependency waiting to be deployed in a future Linux release.
Ultimately, the attack was uncovered not by design, but by chance. A minor flaw caused unexpected crashes, prompting an independent developer to investigate more closely. The malicious code was discovered, the maintainer was alerted, Tan’s access was revoked, and the changes were swiftly rolled back.
It is difficult to overstate how close this came to becoming a catastrophic incident. Had the issue been quietly corrected by the attacker before discovery, it may have gone unnoticed for years. Potentially becoming one of the most severe cybersecurity breaches ever recorded. This attack exemplifies the true danger of supply chain compromises, patience, social engineering and technical skill can succeed where brute force cannot. When the roots of the tree are poisoned, even the strongest branches are vulnerable.
As for who “Jia Tan” really was, their identity remains unknown. Some in the security community have speculated about possible nation‑state involvement, but no definitive evidence has been made public. What is clear, however, is just how powerful and how perilous supply chain attacks can be when trust is quietly exploited over time.
Intercede’s approach to supply chain security
Governments and regulators have responded to the growing threat of supply chain attacks with the seriousness it deserves. In May 2021, US President Joe Biden signed Executive Order 14028, aimed at strengthening the security and integrity of the software supply chain. A key requirement of the order is the use of Software Bills of Materials (SBOMs), detailed inventories that list every component, dependency and library used within a software product.
An SBOM provides transparency into what software is really made of. Rather than identifying only the components a developer deliberately adds, it also captures all underlying and transitive dependencies. Using the earlier example, an SBOM would not just list CatCounter, it would also clearly identify CatDetector, CatMaths and any other nested libraries. This visibility makes it far easier to determine whether a product is affected by a newly discovered vulnerability or supply chain compromise. Intercede supplies the US government and complies fully with these requirements.
At Intercede, we go beyond compliance. We use automated tooling to generate, monitor and analyse SBOMs across our products, enabling us to quickly identify vulnerabilities, assess risk and prioritise remediation based on severity. Every third‑party library we use is subjected to a rigorous, multi‑stage due‑diligence process to ensure it is secure, reputable and trustworthy before it ever reaches a customer environment.
If a vulnerability or supply chain attack is disclosed anywhere within our dependency chain, we know immediately. That early visibility allows us to act fast, containing, remediating and communicating clearly to minimise risk to our customers. Where trust itself is the target, proactive transparency and disciplined dependency management are essential to staying secure.
Where supply chain security goes from here
Supply chain attacks remind us that cybersecurity is no longer just about protecting what we build ourselves, it is about understanding, monitoring and securing everything we depend on. From widely used open‑source libraries to niche tools maintained by a single individual, any component can become an attack vector if left unchecked. The examples we have explored show how trust, convenience and opacity can be exploited at scale, often without immediate detection. By investing in visibility, rigorous dependency management and proactive security practices, organisations can reduce risk and respond faster when the inevitable vulnerabilities emerge. Resilience is not built by eliminating risk entirely, it is built by knowing where it lives and being prepared to act when it is exposed.
See how MyID helps organisations manage credentials and dependencies with confidence. Book a demo today.