What Jaguar Land Rover, Salesloft and one bad week in the software world should tell every business leader about supply chain risk
Just last week, news broke that the FBI had been hacked. The way in? Reportedly, weaknesses in services provided by Amazon and Oracle – two of the biggest technology suppliers in the world.
Over the last decade, most businesses have moved their everyday software into the cloud, renting it as a subscription rather than owning and running it themselves. Project management, invoicing, customer records, HR, expenses, file storage, payroll, procurement – all of it now runs somewhere else, on someone else’s systems, updated on someone else’s schedule. In almost every case it was the right commercial call: quicker to roll out, cheaper to run, no servers to replace and someone else on call at night. For many, it wasn’t really a choice anyway – software vendors simply stopped selling one-off licences and moved everyone onto subscriptions.
But when we moved the work, we also moved the risk – somewhere we can no longer see it.
What’s Missing From the Business Case
When you sign up with a software provider, you check them out. You look at their security certifications (ISO 27001, perhaps SOC 2), send them a security questionnaire and get a reassuring PDF back. Box ticked.
What you can’t check are the hundreds of ready-made software building blocks the vendor’s engineers used to build their product. Rather than custom-coded, modern software is usually assembled from freely available components, many of them maintained by unpaid volunteers who have no contract with anyone in this story.
So, your real supply chain is realistically every component software you are using is built with, plus every component those components rely on, repeated for every software product you use. For a mid-sized business running forty applications, that easily adds up to tens of thousands of parts. You have no list of them. You have no right to one. In most cases, your vendor doesn’t have a complete list either.
This isn’t theoretical. Here is what it looks like in practice.
In September 2025, a piece of self-spreading malicious software nicknamed Shai-Hulud tore through npm – the world’s largest online library of these software building blocks. It needed no human to guide it. Once it had broken into one developer’s account, it stole passwords and access keys, planted poisoned versions of every other component that developer looked after, and then used the newly stolen keys to keep spreading. Hundreds of components were infected in the first wave, including one downloaded more than two million times a week. A second, stealthier wave in November hit components published by well-known technology firms including Zapier, Postman and PostHog, and created tens of thousands of malicious copies along the way.
Then, on 14 July 2026, attackers planted a hidden backdoor in four components from a project called AsyncAPI – downloaded roughly three million times a week between them – designed to steal passwords and give the attackers remote control of affected computers. It was the same project that had lost 36 components in the November wave eight months earlier: hit twice, through two different routes, by two unrelated groups.
What makes it particularly worrying:
- The attackers didn’t need to steal anyone’s password. Instead, they found a weakness in the project’s automated publishing process and let the project’s own, legitimate release system send out the malware for them.
- Because the release came through the official channel, the poisoned components carried valid digital seals of authenticity. Those seals prove where software came from – not that the source could be trusted at the time.
- The malicious code ran as soon as the software was used, not just when it was installed – so a standard safety setting many teams rely on offered no protection.
- The weakness had been spotted internally 58 days earlier. A fix had been written – but was never put in place.
Every one of those safeguards would have been marked green on a standard supplier questionnaire.
Jaguar MENA, CC BY 2.0 <https://creativecommons.org/licenses/by/2.0>, via Wikimedia Commons
JLR: the £1.9 Billion Worked Example
So, what does this cost in the real world? Jaguar Land Rover gives us the answer.
JLR’s production stopped on 1 September 2025 and stayed stopped for around five weeks. The Cyber Monitoring Centre, an independent non-profit whose technical committee includes a former head of the UK’s National Cyber Security Centre, classified it as a “Category 3 systemic event” and estimated the cost to the UK economy at £1.9 billion (within a range of £1.6bn to £2.1bn), affecting more than 5,000 UK organisations. According to the company, it took until mid-November for production to return to normal. On those numbers, it is the most economically damaging cyber event in British history.
Fun fact: most of that cost wasn’t JLR’s IT clean-up bill. It was lost production – at JLR, and across its chain of suppliers: small and medium-sized engineering firms with thin margins and no way to absorb five weeks of cancelled orders. The government ended up guaranteeing a £1.5 billion loan through UK Export Finance, repayable over five years, specifically to stop that supply chain collapsing. Reports at the time suggested JLR did not hold cyber insurance. Even if it had, standard cyber cover protects the policyholder and rarely extends to the businesses further down the chain that have just lost their only customer for a month.
What hasn’t been mentioned widely in the media:
JLR suffered two cyber incidents in 2025, and only one of them has a confirmed explanation of how the attackers got in.
In March 2025, a criminal group called HELLCAT leaked around 700 internal JLR documents, including software code, development records and employee data. Investigators at the threat intelligence firm CYFIRMA found the breach was made possible by login details for Jira, a widely used project-tracking tool, that had been stolen by password-stealing malware. Days later a second attacker, calling itself APTS, released a further 350GB or so of sensitive data, claiming they had used stolen login details dating back to 2021, belonging to someone at a third-party company who had access to JLR’s Jira system.
The September attack – the one that halted production – was claimed on the messaging app Telegram by a group calling itself Scattered Lapsus$ Hunters, a mash-up of three notorious hacking groups: Scattered Spider, Lapsus$ and ShinyHunters (yes, the same the ones behind the recent FBI hack). CYFIRMA’s assessment linked the attack to the group with medium confidence and noted that the forensic investigation was still ongoing. If the investigations are right, old login details belonging to a third party – which should have been cancelled but never were – played a part.
The March incident sums up the problem perfectly. Criminals are waiting for carelessness and don’t mind playing the long game: A password, stolen by off-the-shelf malware, from a third party, four years before it was used, to get into an online collaboration tool that almost every organisation reading this also uses. It was quite literally “just” an old password nobody had switched off.
Everything Hangs Off One Front Door
The other big change we made without much debate: we connected all these applications to a single login system, so staff sign in once and get access to everything. For most organisations, that is Microsoft’s Entra ID.
This is good practice, and I’d recommend it to anyone. It gives you one place to enforce security checks – such as the codes sent to your phone when you log in – and one place to grant or remove access when people join, move or leave. But it also concentrates risk in a way we rarely acknowledge, and attackers have adapted to it faster than most companies’ checks have.
The Salesloft Drift breach in August 2025 is the clearest example. Rather than attacking Salesforce directly, the attackers broke into Drift, an AI chat tool that hundreds of companies had plugged into their Salesforce customer systems, and stole its digital access passes. These prove that someone has already logged in, so they walk straight past the phone codes and other login checks. Over about ten days, more than 700 organisations had their Salesforce data systematically copied out, and Google’s threat intelligence team later widened the warning to every other system connected through Drift, including Google Workspace and Slack. The attackers then combed the stolen customer-support records for keys to other cloud systems, to get in even further. Victims included Cloudflare, Palo Alto Networks, Proofpoint and Zscaler – companies known for top-notch security teams.
The same pattern repeated in November 2025 through apps published by Gainsight, hitting more than 200 organisations. And in 2026 it has become an industry. Phishing-as-a-Service, offered via a platform called EvilTokens, allowed criminals easily to attack their victims by misusing legitimate verification features on Microsoft’s own login page. Staff were asked to type a short code and complete their usual phone check – unknowingly handing the attacker a live login to their email, files and calendar. Those tokens would also withstand password resets and remain valid for longer periods of time (subject to tenant configuration). Within five weeks of launching in February, it had compromised more than 340 organisations.
But there’s more, such as OAuth client ID spoofing: One campaign used more than 700,000 fake app identities to test stolen passwords against a million accounts across nearly 4,000 organisations – without ever setting off a login alert.
None of these attacks would be caught by security built around one question: “did the right person log in?” The connected app is the trusted relationship. Your third-party connections are effectively digital employees with permanent access – often more access than your real staff – and almost never a review date.
Ask your IT team for the list of apps connected to your company’s Microsoft login, and how many of them anyone recognises. That list is part of your supply chain – one you probably didn’t know you had.
Four Questions I Recommend Asking
1. Could you switch it off tomorrow morning?
A realistic could you. If your project management, invoicing or customer management system were compromised tonight and you had to disconnect it by 9am, what would happen to the business? Which processes would stop dead? Which teams simply couldn’t work? Many organisations have a plan for losing a data centre, and no plan at all for losing a cloud application they can’t fix, can’t isolate and can’t look inside.
2. Where would the data go?
Suppose you decide to move. To what? Is there a clear route to another provider, or would you be exporting 40,000 rows of data into a spreadsheet and rebuilding six years of processes from memory? Have you ever tested getting your data out?
3. Do you have access to your data?
Read the contract. What are you entitled to on demand, in what format and how quickly? And what happens to that right if you’re in a billing dispute, if the vendor is bought by someone else, or if the vendor is the one that has been breached and has taken its service offline? Ask when you last successfully took a complete copy of your data. If nobody can answer, you’re simply hoping for the best.
4. Is it protected, and would you know if it wasn’t?
Would your vendor tell you if one of their own suppliers – or one of the software components they build with – were compromised, not just their own systems? Would they even know? How quickly are they contractually obliged to tell you, and does that fit with the 24-hour deadline for reporting incidents to regulators that you may soon be working to?
For your top ten applications, you need these four answers in writing. Without them, you don’t really have a handle on your third-party risk.
The Regulator Has Noticed
The UK’s Cyber Security and Resilience Bill was introduced in November 2025, passed the House of Commons in June 2026 and is now going through the House of Lords. For the first time, it brings IT service providers, data centres and designated critical suppliers under regulation. It requires serious incidents to be reported within 24 hours, with a full report within 72, and carries fines of up to £17 million or 4% of global turnover, whichever is higher.
The Information Commissioner’s Office, the UK’s data protection regulator, put it plainly in its response to the Bill: serious incidents are increasingly caused by the way digital services depend on one another, and regulating those interconnected supply chains will remain difficult even with new powers.
Supply chain security is moving from good practice to legal duty. And the practical impact will arrive well before the Bill becomes law – in the form of new contract clauses and security questionnaires from your largest customers.
What I Would Do
As soon as you can:
- Build the list you don’t have. Every cloud application you use, how critical it is to the business, what kind of data it holds and – crucially – every other app connected to it. Then ruthlessly remove any connection that can’t be justified.
- Ask vendors for an ingredients list – and a straight answer. Ask for a list of the components their product is built from (known as a Software Bill of Materials). You may not get it. That response is your risk assessment. Ask specifically how, and how quickly, they would tell you if something in their own supply chain were compromised.
- Treat connected apps’ access like passwords. Make sure your IT team limits what connected apps can do, makes their access expire regularly, watches for unusual activity – not just unusual logins – and knows how to cut off every connection at once, even at the worst possible moment.
- Test one exit for real. Pick a single non-critical application, take a full copy of its data, and try to run that process somewhere else.
- Rehearse the loss, not just the breach. Run a boardroom exercise in which a core cloud system is simply gone for three weeks. Who decides? What’s the manual fallback? Who tells your customers? JLR’s suppliers didn’t get a vote, and neither will yours.
Your supply chain is a web, not a list. It is mostly invisible, it changes without telling you, and a meaningful part of it is maintained by people who owe you nothing.
That doesn’t mean going back to running everything in-house. It means the way we check our suppliers was designed for a world of in-house servers and named suppliers – and it no longer reflects reality. Pretending otherwise costs real money: £1.9 billion of it in one case, spread across 5,000 businesses who mostly did nothing wrong except stand next to someone who got hit.
What would break in your business tomorrow morning – and who could tell you?
