Supply Chain Attack

In a supply chain attack, attackers compromise a supplier, a software update, or a component and use it to reach the systems of their actual targets. This article explains attack paths through software and service provider supply chains, the role of SBOMs, and the supply chain obligations arising from NIS-2.

Companies are securing their own systems better and better. Attackers therefore turn to a quieter route: they compromise software vendors or service providers and let valid signatures and legitimate access carry them from there to their actual targets. A supply chain attack thus abuses the most valuable asset in any business relationship: trust.

What is a supply chain attack?

A supply chain attack targets a company through its suppliers. Instead of attacking the well-protected target organization directly, the attacker compromises a weaker link in the supply chain and uses the existing trust relationship as an entry point: automatic updates, signed code, remote maintenance access, or data connections.

Two variants can be distinguished. The software supply chain comprises everything that applications are built from: open source libraries, development tools, build systems, and update mechanisms. If malicious code is injected here, it spreads to all customers through regular releases. The service provider supply chain concerns companies with access to systems or data: IT service providers, maintenance firms, cloud providers, or suppliers with a network connection. Here, legitimate access becomes the attack path.

Transparency begins with the inventory: an SBOM (Software Bill of Materials) lists, like a parts list, which components a piece of software consists of. If a vulnerability becomes known in a library, SBOMs make it quick to determine which products and systems are affected. Such parts lists are increasingly being required by regulators too, for example in the European Cyber Resilience Act for manufacturers of connected products. For procurement and operations, the SBOM thus becomes a normal part of tenders and contract annexes.

How such an attack works

Most cases follow a recurring pattern:

Breach at the supplier: The attacker compromises a software vendor or service provider, often through stolen credentials or vulnerabilities in its infrastructure.
Manipulation of the product: Malicious code is injected into build systems, update servers, or code packages. If it carries the vendor's valid signature, it appears trustworthy to verification mechanisms.
Distribution through legitimate channels: Customers install the manipulated update or package in the course of normal operations. Traditional protective measures rarely trigger, because the source and signature are correct.
Selective activation: The built-in backdoor reports back to the attacker. The attacker selects the worthwhile targets from among the affected organizations and begins spreading and exfiltrating data there.
Route via service provider access: Alternatively, the attacker abuses remote maintenance access or standing network connections of a compromised service provider and is thereby directly inside the customer network.

The patience of these attacks is striking: months can pass between the breach at the supplier and activation at the final target. A one-time security assessment of the supplier is therefore rarely sufficient. What matters is the ongoing view of what its software and access actually do within your own network and with whom they communicate.

Why protection against supply chain attacks matters

A single compromised supplier can hit many organizations at once, with the attacker choosing the victims afterwards.
The malicious code comes from a trusted source and therefore passes controls that are designed for external attacks.
Modern applications consist largely of third-party components whose origin and maintenance status are rarely fully known.
Remote maintenance and service provider access often lead deep into internal networks and are monitored less often than external access.
The NIS-2 directive explicitly obliges affected companies to assess and address risks in the supply chain, details are explained in our glossary article on NIS-2 .
Contractual pressure is growing too, because customers increasingly pass security requirements on to their suppliers.

Typical scenarios

A manipulated update of a widely used IT management software installs a backdoor at all customers, and it is exploited at selected targets.
A popular open source package changes maintainer, and shortly afterwards a new version contains code that exfiltrates credentials.
Attackers take over the remote maintenance software of an IT service provider and then encrypt the systems of its customers.
Through the network connection of a logistics partner, attackers gain access to a manufacturer's production network.
A compromised build pipeline signs malicious code with the vendor's official certificate.

Supply chain attack vs. direct attack

In a direct attack, the attacker looks for vulnerabilities in the target's infrastructure, such as exposed services or unpatched systems. Perimeter protection, patching, and your own hardening help against this. The supply chain attack bypasses this defense, because it arrives through a channel that the target trusts both technically and organizationally. For defenders, this means: prevention at the outer boundary is not enough. It requires transparency about dependencies and minimal privileges for third parties, plus an architecture that limits the damage when trusted software or partners are compromised.

Protection against supply chain attacks at KAEMI

The compromise of a supplier from the outside cannot be prevented entirely. This makes an architecture that limits the blast radius all the more important. With Zero Trust Microsegmentation , KAEMI isolates systems and service provider access in such a way that a backdoor in a single piece of software does not open a path through the entire network: every connection requires explicit authorization, and maintenance access remains limited to the bare minimum. In addition, SASE/SSE ensures that external partners reach defined applications rather than entire network segments. This keeps a supply chain incident a limited event instead of a total outage.

Frequently asked questions about Supply Chain Attack

What is an SBOM and why do I need it?

An SBOM (Software Bill of Materials) is a machine-readable parts list that records all components of a piece of software along with their versions, including open source libraries. If a vulnerability becomes known in a component, the SBOM shows immediately which applications are affected. Without this transparency, analyzing exposure after an incident often takes days. Customers and regulators are increasingly demanding SBOMs from vendors.

How do the software and service provider supply chains differ?

The software supply chain concerns the code itself: libraries, build systems, and update paths through which malicious code enters products and spreads to all customers. The service provider supply chain concerns access: IT service providers, maintenance firms, or partners with a network connection whose legitimate connections attackers take over. Both routes bypass the perimeter, but they call for different countermeasures, from SBOM and update control to strictly limited remote access.

What does NIS-2 require regarding the supply chain?

NIS-2 obliges affected companies to actively manage the security of their supply chain. This includes assessing the security levels of direct suppliers and service providers, contractual security requirements, and taking the vulnerabilities of individual providers into account in their own risk management. The obligation has a broad reach: even companies that do not fall under NIS-2 themselves have the requirements passed on to them by their customers.

How do I know whether my company is affected by a publicly disclosed supply chain incident?

The basis is a current inventory: which software, versions, and service provider access are in use? SBOMs considerably speed up the comparison with vendor information. Then check the vendor's advisories and relevant warnings, for example from the BSI, and search your logs for the published indicators of compromise. Without an inventory, what remains is a laborious manual search while the window for attackers stays open.

Which measures limit the damage of a supply chain attack?

Assume that individual components or partners can be compromised, and limit the consequences: network segmentation keeps affected systems isolated, service provider access is granted minimal privileges through controlled transitions, and updates are rolled out in stages rather than everywhere at once. In addition, monitoring for unusual connections and well-rehearsed emergency procedures help so that affected systems can be isolated quickly.