
Supply Chain Attack
In a supply chain attack, criminals don't attack a company directly, but instead manipulate a supplier whose product the company uses. Through a single infected update, thousands of customers can be affected at once.
Almost every company uses software it didn’t write itself. An accounting program, a tool for monitoring servers, a small building block from the internet that a programmer built in. In a supply chain attack, criminals don’t attack the company itself, but rather one of these suppliers. They smuggle malicious code in there, which is then distributed as a completely normal update to all customers. The name comes from economics: the supply chain encompasses all suppliers who contribute to a finished product. Applied to software, this means: whoever cracks the supplier gets straight into all of its customers at once.
The leverage: one break-in, thousands of victims
The appeal for attackers is multiplication. Attacking a company with a good security team directly is laborious. But a tool that this company voluntarily installs and regularly updates is a convenient way in. A single successful break-in at the manufacturer can thus open up several thousand networks.
On top of that, such attacks are extremely difficult to detect. Updates from a known manufacturer are considered trustworthy. Protection programs often let them through without close inspection because they carry a valid digital signature – that is, an authenticity stamp from the manufacturer. Attackers use this very stamp when they already control the manufacturer. The most famous case, the attack on the network software SolarWinds in 2020, went undetected for around nine months.
This affects not only the economy. Among the SolarWinds victims were several US government departments. For states, this form of attack is therefore also a tool of espionage, not just of extortion.
Routes into the supply chain
The classic route leads via the manufacturer itself. Attackers gain access to the system on which the program is assembled. There, they alter the code shortly before delivery. The finished update then looks genuine afterward, because it is genuine – it just contains a few extra lines.
The second route uses free program building blocks, so-called open-source packages. Programmers download such building blocks millions of times from public collections instead of writing everything themselves. Some of these packages are maintained by only a single person in their free time. If someone takes over their access, or kindly offers to help out as a contributor, they can feed malicious code directly into thousands of projects.
Traceability is considered the main countermeasure. Large providers now maintain a kind of ingredient list for their software, listing every third-party component used. Experts call this a Software Bill of Materials. In addition, there are stricter checks of the components and the principle that a program should only get the permissions it really needs. However, there is no way to rule out the risk entirely as long as software is made up of parts from others.
From AI libraries to phone updates
In the news, supply chain attacks usually surface after major incidents. Besides SolarWinds, the Kaseya case from 2021 is well known: via the software of an IT service provider, hundreds of companies were paralyzed at once with ransomware, including a Swedish supermarket chain. Such reports also move stock prices, because they entail liability issues and loss of trust.
In the field of AI, the topic has its own twist. Models and datasets are shared via public platforms and simply downloaded. A manipulated model can execute malicious code upon loading or secretly deliver false answers. Here too, the same applies: the user trusts a file they did not produce themselves.
On a personal level, one encounters this principle with every update of a phone, router, or browser. The advice to install updates quickly remains correct nonetheless, because known security vulnerabilities are the far more common danger. A supply chain attack is no reason to avoid updates – it merely shows that trust in software is always a chain of assumptions. And a chain breaks at its weakest link.