Supply Chain Attacks Defined in Plain Terms
A supply chain attack is a cyberattack that reaches its target indirectly, by compromising a supplier, a software vendor or a code library the target already trusts. The attacker inserts malicious code or steals access at that trusted point, then rides the normal update, login or data flow into every organisation downstream.
The appeal for an attacker is leverage. One compromise at a supplier converts into hundreds or thousands of victims with no extra effort, which is why this technique moved from rare state espionage to everyday criminal work in about five years.
Sweden found out what that means in August 2025. An attack on one HR software supplier disrupted services across most of the country’s municipalities and exposed the personal data of more than 1.5 million people. None of those municipalities were breached. They had simply bought the same system.
The uncomfortable part for a buyer is that your own controls are not at fault. Your patching was current. Nobody clicked anything. The malicious code arrived signed, from a vendor you pay, through a channel you configured to trust.
ENISA’s Threat Landscape 2025 analysed 4,875 incidents across the EU between July 2024 and June 2025 and recorded a clear rise in attackers targeting cyber dependencies. Digital infrastructure and service providers are increasingly attacked for the access they hold to other organisations.
How a Supply Chain Attack Works
Almost every supply chain attack follows the same four steps, whether the target is an open source package or a national IT provider.
- Pick the weak link: The attacker looks for a small supplier whose software or access reaches a large number of organisations
- Take over the publishing route: Phished credentials, a stolen API token or a compromised build server all deliver the same prize, the right to publish something customers will install
- Ship through the trusted channel: The payload travels as a routine update, a new package version or a normal remote-support session
- Harvest downstream: Inside customer environments the attacker steals credentials, deploys ransomware or stays quiet for months
What changed is the amount of software nobody writes any more. A typical business application assembles hundreds of open source packages, each maintained by people the buyer has never heard of and each pulling in further packages of its own. Compromise one of those and you inherit everyone who installs it.
The entry point is usually cheap. In September 2025 an attacker phished a single npm maintainer and republished 18 widely used JavaScript packages with a payload that rewrote cryptocurrency transactions. Those packages account for roughly two billion downloads a week. The malicious versions were live for a couple of hours.
Service providers offer the same leverage without any code. An attacker who takes over a managed service provider inherits its remote-management tooling, which by design has administrator rights on every customer network it touches.
Types of Supply Chain Attacks
The term covers several different attacks that share one shape. Knowing which type you are exposed to decides which control actually helps.
- Software update compromise: Malicious code is added to a legitimate product and shipped through the vendor’s signed update mechanism, which gives the attacker code execution on every customer that updates
- Open source dependency compromise: A package in a public registry such as npm or PyPI is poisoned, so the code runs during installation on developer machines and build servers
- Service provider compromise: An IT supplier, hosting partner or managed service provider is breached and its privileged access to customer environments is reused
- Build pipeline compromise: The attacker never touches the source code and instead subverts the CI/CD system that turns it into a shipped artefact, so the published build differs from the reviewed code
- Hardware and firmware compromise: Malicious components or modified firmware are introduced during manufacture or distribution, below the level most security tooling inspects
- Third-party data breach: No code is tampered with at all. A supplier holding your data is breached and your customers, employees or citizens are the ones exposed
The last two are the ones most Swedish organisations meet first. Very few buyers will ever be hit by a poisoned npm package directly. Almost all of them hand personal data to a processor.
The Business Impact of a Supply Chain Attack
The costs land in four places and only one of them is technical.
Downtime you cannot fix. When your supplier is encrypted, your recovery plan is a phone call. Coop could not open its shops because a supplier two steps removed had lost its systems. No amount of internal preparation would have shortened that wait.
Data you never held. Personal data sitting in a supplier’s system is still your responsibility to the people it belongs to. The Miljödata breach published sick-leave and rehabilitation records for more than 1.5 million people. Every affected municipality then had to notify its own staff.
Regulatory exposure that does not transfer. In November 2025 the Swedish data protection authority IMY opened audits into Miljödata and also into three of its customers, the City of Gothenburg, Älmhult Municipality and Region Västmanland. Outsourcing the processing did not outsource the accountability.
Concentration risk. Swedish public sector procurement has been efficient at consolidating suppliers, which means one HR platform can sit under roughly 80 per cent of municipalities. Efficiency and blast radius are the same number viewed from opposite ends.
Real-World Cases
Five incidents cover the whole range, from a national outage to a backdoor that was caught by luck.
Miljödata and the Swedish Municipalities
On Saturday 23 August 2025 Miljödata, a Swedish supplier of HR and work-environment systems, detected an attack on its IT environment. Its Adato system handles sick leave, medical certificates, rehabilitation cases and work-injury reporting for roughly 80 per cent of Swedish municipalities.
The company’s chief executive said around 200 municipalities and regions were affected. Swedish authorities later confirmed 164 municipalities and four regions as directly hit. The attackers demanded 1.5 bitcoin, were refused and published the stolen data, which covered more than 1.5 million people. CERT-SE supported both the supplier and its customers.
The control that mattered here was never a firewall. It was scoping. Some municipalities had run a documented supplier risk assessment under GDPR Article 28 and challenged how much sensitive health data the platform needed to retain. They had far less to notify when the files appeared online.
Coop and the Kaseya Attack
On Friday 2 July 2021 the REvil group compromised Kaseya VSA, a remote-management product used by IT service providers, and pushed ransomware disguised as an update. Kaseya reported that fewer than 60 of its direct customers were compromised, all running the on-premises version, with fewer than 1,500 downstream businesses affected.
One of those downstream businesses was Coop Sweden. Its checkouts stopped and it closed most of its roughly 800 stores over a July weekend. Coop said the attack targeted its supplier and that a majority of its stores were shut.
Note the distance. Coop bought point-of-sale services from a Swedish provider, that provider used Kaseya and Kaseya was the one attacked. Coop had no contract with Kaseya at all. Time-boxing supplier remote access and holding an offline way to cut supplier tooling is what shortens this kind of outage.
SolarWinds and the Trojanised Update
In December 2020 CISA issued Emergency Directive 21-01, ordering US federal civilian agencies to disconnect or power down SolarWinds Orion network management products immediately.
The joint US government coordination group later stated that of the approximately 18,000 public and private sector Orion customers that received the affected build, a much smaller number were compromised by follow-on activity. Official accounting put that group at nine federal agencies and around 100 private companies.
That distinction is worth holding on to, because the figure is routinely misquoted. Eighteen thousand organisations installed a trojanised update. A few dozen were actually targeted afterwards. Nothing at the customer end stops a correctly signed malicious update, so the useful controls are outbound traffic restrictions and treating a monitoring tool’s network behaviour as something to watch.
The XZ Utils Backdoor
On 29 March 2024 CISA published an advisory on malicious code embedded in XZ Utils versions 5.6.0 and 5.6.1, a compression library present in most Linux distributions and reachable from OpenSSH. Tracked as CVE-2024-3094 and scored 10.0, it could allow unauthorised remote access to affected systems.
It was found by a developer called Andres Freund, who noticed that SSH logins were taking about half a second longer than they should and kept pulling the thread. The backdoor had been contributed by someone who spent roughly two years building credibility in the project before being handed maintainer rights.
It never reached stable releases. That was luck and everyone involved has said so. The durable lesson is that critical infrastructure runs on packages maintained by one or two unpaid volunteers, which makes patience a viable attack strategy.
The npm Worm Waves
On 23 September 2025 CISA published an alert on a widespread compromise of the npm ecosystem. A self-replicating worm known as Shai-Hulud had compromised over 500 packages. It scanned infected environments for credentials, took GitHub personal access tokens and cloud API keys for AWS, Google Cloud and Azure, uploaded them to a public repository and then republished poisoned packages as the maintainer whose token it had stolen.
A second wave in November 2025 backdoored several hundred more packages and moved its code to the preinstall stage, so it executed before any test or check ran. The same worm family returned in repeated waves through 2026 and spread to PyPI as well as npm.
Development teams stop this with lockfiles, exact pinned versions, hash verification and by disabling install scripts. Publishing credentials should be short-lived and scoped. A long-lived npm token in a developer’s home directory is an unattended key to everyone who installs that package.
Supply Chain Attacks and Compliance
Supplier security stopped being good practice and became a legal duty. Four regimes matter for Swedish organisations and they overlap.
NIS2 and Cybersäkerhetslagen. Sweden’s Cybersäkerhetslag (SFS 2025:1506) came into force on 15 January 2026 and transposes NIS2 into Swedish law. Article 21.2(d) of the directive requires supply-chain security, including the security of the relationship between an entity and its direct suppliers. Under Article 20 the management body approves and oversees these measures and can be held personally accountable.
Incidents go to MCF (formerly MSB) and the sector authority within 24 hours, with a full notification at 72 hours and a final report within a month. Fines reach €10 million or 2 per cent of global turnover for essential entities. Our NIS2 compliance guide covers the full obligation set.
GDPR. Article 28 allows you to use a processor only where it provides sufficient guarantees of appropriate technical and organisational measures. Article 33 then gives you 72 hours to notify IMY of a personal data breach. The Miljödata audits show how this lands in practice, with the regulator examining the municipalities alongside the supplier. More detail sits on our GDPR compliance page.
DORA. For financial entities, Chapter V governs ICT third-party risk. Article 28 requires a register of information covering every ICT arrangement, pre-contract due diligence, concentration risk analysis and a documented exit strategy. Article 30 sets mandatory contract clauses including audit rights, and Articles 31 to 44 place designated critical ICT providers under direct European supervision.
The rule underneath all of it is that the financial entity keeps full responsibility for what it outsources. Finansinspektionen supervises in Sweden and our DORA compliance page covers the detail.
The Cyber Resilience Act. Regulation (EU) 2024/2847 applies to anyone placing a product with digital elements on the EU market. From 11 September 2026 manufacturers must report actively exploited vulnerabilities and severe incidents through the Single Reporting Platform to their national CSIRT and ENISA, with a 24-hour early warning.
From 11 December 2027 the full requirements apply. Annex I, Part II obliges manufacturers to draw up a software bill of materials in a commonly used machine-readable format covering at the very least the top-level dependencies. Penalties run to €15 million or 2.5 per cent of worldwide annual turnover.
If you buy software rather than build it, the CRA is still your lever. From September 2026 you can reasonably ask a supplier what its reporting process is and from December 2027 you can ask for the bill of materials it is already required to hold. An ISO 27001 certificate with supplier relationships in scope gives you a second anchor in procurement.
How to Spot a Supply Chain Attack
Detection is genuinely hard here, because the traffic is authorised and the software is signed. These are the signals that do show up.
- A trusted application starts making outbound connections to domains it has never contacted before
- Package installation or a build job generates network traffic, which a normal dependency install has no reason to do
- A supplier’s remote-support session opens outside agreed hours or from an unfamiliar location
- New package versions appear outside the project’s usual release rhythm
- Repositories, workflow files or publishing tokens change without a matching ticket or pull request
- Service accounts belonging to a supplier suddenly enumerate systems they have never touched
Be honest about the limits. Most organisations do not discover a supply chain attack themselves. They learn about it from the supplier, a national CERT or an advisory, which is why the readiness that counts is how fast you can answer three questions.
- Which of our systems does this supplier touch
- What access does it hold right now
- How quickly can we revoke it
An organisation that can answer those in an hour is in a completely different position from one that starts by hunting for the contract.
How to Defend Against Supply Chain Attacks
You cannot audit your way out of this. Nobody has the capacity to inspect every supplier and every transitive dependency, so aim for a smaller blast radius instead of a perfect perimeter.
People. The credentials that publish your software and administer your supplier tooling are the crown jewels. Train the people who hold them on the targeted phishing that goes after maintainers and administrators, not the generic invoice-fraud material. Make sure procurement and legal know which security clauses actually matter.
Process. Keep a live inventory of suppliers, what data each holds and which systems each can reach. Write breach notification windows into contracts so you are not waiting on a press release. Rehearse the supplier-down scenario the way you rehearse a fire drill.
Technology. Assume any supplier connection can turn hostile and build so that it does not cost you the estate.
- Inventory every supplier with access to your data or network and record what each one can reach
- Give supplier accounts the minimum privilege they need, with time-limited access and phishing-resistant multi-factor authentication
- Segment supplier tooling away from domain controllers, backups and identity systems
- Pin dependencies to exact versions with lockfiles, verify hashes and disable install scripts in build environments
- Issue short-lived scoped publishing tokens, rotate them and keep long-lived credentials off developer machines
- Require a software bill of materials from suppliers and store it where you can query it when the next advisory lands
- Monitor outbound traffic from vendor software and alert on connections to new destinations
- Keep backups your suppliers cannot reach and test a restore that assumes the supplier is unavailable
- Write a 24-hour notification duty into supplier contracts, with audit rights and a defined exit plan
Then rehearse it. Pick your most critical supplier, assume it was encrypted this morning and walk the room through the first four hours. The gaps that exercise exposes are the ones the next attack will use.