What is a supply chain attack?

Supply chain attacks in plain English

A company’s supply chain includes everyone who delivers something to it or works on its behalf: software vendors, IT service providers, cloud providers, and the many freely available open-source components that modern software is built from. An attack that exploits one of these links to reach the company is called a supply chain attack.

An everyday comparison: a burglar would have to break into many houses one by one. It’s easier to break into the property management company that holds the keys to every house on the street. That’s exactly how perpetrators proceed in a supply chain attack. They compromise a supplier that many companies trust – and exploit that trust.

The insidious part: for the victims, everything looks normal. The update comes from the familiar vendor, the remote access from the trusted service provider.

How a supply chain attack works

Typical routes include:

1. Manipulated software updates: The perpetrators break into a vendor’s development environment and smuggle malicious code into a regular update. The update carries the vendor’s genuine digital signature – a kind of tamper-proof seal – and customers install it without suspicion.
2. Compromised open-source packages: Attackers publish packages with confusingly similar names, take over developers’ accounts, or spend a long time gaining a project’s trust. That’s how a back door made its way into a widely used compression library for Linux in 2024. A developer discovered it more or less by chance before it was widely deployed.
3. IT service providers with remote access: Anyone who compromises a service provider that supports many customers via remote maintenance can use its tools to access all of those networks.
4. Compromised supplier mailboxes: From a supplier’s real email account, perpetrators send invoices with changed bank details.

Closely related, but not an attack in the strict sense, are vulnerabilities in widely used components. In 2021, the Log4Shell vulnerability in a Java library showed how many products depend on a single component.

A practical example

A mid-sized machinery manufacturer has its IT managed by a regional service provider. The provider manages all its customers via a central remote maintenance tool. Attackers steal the credentials of a technician whose account isn’t protected with multi-factor authentication.

Overnight, they use the tool to distribute ransomware to several of the provider’s customers at once. The next morning, design engineering and order processing at the manufacturer have ground to a halt. Its own firewall didn’t raise the alarm – after all, the access came through a permitted, trusted channel. Had the service provider’s access been restricted to specific systems and time windows and monitored, the damage could have been reduced significantly.

Why does this matter for businesses?

Hardly any company builds its IT entirely in-house. Every supplier with access to your network or software running in it enlarges your attack surface. Classic safeguards are of little use here, because the attack comes through a permitted channel.

Regulators are responding, too. The NIS2 Directive explicitly requires companies within its scope to address the security of their supply chain. Among other things, the Cyber Resilience Act obliges manufacturers of products with digital elements to identify and document the components their products contain – including in a software bill of materials, or SBOM – with deadlines phasing in gradually. For financial entities, DORA also governs how to handle risks from ICT third-party service providers – external providers of information and communication technology.

How to protect your organization

• Know your suppliers: Keep an overview of which service providers and software products have access to your systems or data.
• Limit access: Allow remote access only with MFA, only to the systems needed, for limited periods, and with logging.
• Agree on requirements: Set out security requirements and incident reporting obligations in your contracts.
• Keep track of components: An SBOM and automated dependency checks show whether a newly disclosed vulnerability affects you. Prompt patch management closes it.
• Verify integrity: Install only signed software from official sources. If you develop software yourself, give special protection to the systems on which it is built and signed (the build environment).
• Verify bank details: Always confirm changed bank details by phone using a known number.
• Rehearse the worst case: Plan what to do if a service provider is compromised – including contacts and the ability to cut off access immediately.

How Rootsektor can help

With Code Review & Reverse Engineering, we check the libraries your software includes for known vulnerabilities, create and review SBOMs, and assess how well your build pipeline – the path from source code to finished update – is protected against tampering. We also examine purchased software through reverse engineering, even without source code. A Network & Infrastructure penetration test shows how well service provider access and remote maintenance are secured. If a supplier has been compromised, a Compromise Assessment determines whether attackers have also gotten into your systems.