When Supply Chain Attacks Become a Competition: What UK Businesses Need to Pay Attention to

A lot of cyber risk is still framed as if attackers get a cork board, some photos and a spool of red string out, before planning exactly which company to hack with the type of precision needed to pull off a bank heist. (We presume. We’re an MSP, not seasoned robbers.)

The reality is that it just doesn’t work this way. At least, not anymore.

We became aware of a threat advisory last week that highlights an increased risk of software supply chain compromise, including reports of a so-called underground “competition” encouraging participants to target software supply chains for scale and downstream impact. Now, this should make you sit up and take note for one reason: it reflects something bigger than a single tool or a single forum post. It suggests a model of attack that rewards reach.

In other words, why go after one business when you can tamper with - and deploy - something that could potentially reach hundreds?

For anyone reading this, whether you’re a UK SMEs, a mid-market organisation, or even an enterprise-level business, you should be paying attention to this.

What is a software supply chain attack?

In simple terms, a software supply chain attack happens when an attacker compromises something upstream that other organisations trust.

That could be anything from:

• a software update

• an open-source package

• a build pipeline

• a developer account

• an automation token

• a third-party supplier with access into production systems

• your payroll provider

It’s easiest to think of it as a digital equivalent of contaminating ingredients before they’re used, rather than trying to ruin a cake after it’s been baked. All it takes is one rotten egg, a dash of spoiled milk or some contaminated butter to make it into the mix unknowingly, and the cake is ruined. But the best part is you won’t know until it’s too late.

The same principle applies in a supply chain attack. Instead of attacking every end customer individually and coming in all guns blazing at your defences, the attacker looks for the shared dependency in the middle and slips through unnoticed.

Why this advisory matters

The advisory doesn’t just describe a possible technique; rather, it describes a shift in behaviour.

According to the source material, the activity appears to gamify supply-chain compromise by measuring success based on downstream reach and download volume. That is worth noting because it may encourage more opportunistic actors to focus on scalable methods, even if their technical sophistication is mixed.

Now, it’s also important to note that this doesn’t mean every business is suddenly in immediate danger from this specific campaign. What it does mean, however, is that the broader direction of travel is clear and attackers are increasingly interested in leverage.

And supply chains provide much of it.

“We don’t build software, so is this really our problem?”

Yes, although not always in the way people first assume.

Many SMEs and mid-market organisations hear “software supply chain risk” and picture large SaaS vendors, development houses, or open-source maintainers. Those groups are certainly in the firing line. But for the average business, the risk usually shows up in a more indirect way.

You may be exposed through:

• business applications that rely on third-party components

• IT providers or software partners with privileged access

• integrations between cloud tools

• automation accounts and scripts that no one has reviewed in a while

• updates pushed from trusted vendors into your environment

So even if you never publish a package or manage a public code repository, you still rely on a chain of trust to stay efficient and operational.

And that very chain, which is crucial to you, is now a more attractive target than ever.

What tends to go wrong

In our experience, supply-chain risk rarely comes down to one dramatic failure. More often, it seems to be a pile-up of smaller assumptions.

A specific package or piece of hardware is trusted because… “It’s always been trusted?”

A service account keeps broad permissions because it’s always had them, and changing feels risky.

A build or deployment workflow gets created quickly during a busy period and is never revisited.

A third-party integration is approved once and treated as permanently low-risk.

We’ve said it before, and we’ll keep saying it: this, usually, is how exposure builds. It snowballs quietly over time, with little friction.

It may not even be something you pay much attention to until a comparable security story, such as the M&S or JLR breaches in 2025, hits the headlines, and then everyone realises how much of their environment depends on systems they do not directly control.

What should software suppliers and internal development teams do now?

If your organisation develops software, manages internal applications, or publishes packages, this advisory is a prompt to properly sense-check the basics.

The source material specifically points to a few control areas worth reviewing:

1. Tighten dependency management

If production builds still rely on unpinned dependencies or loosely controlled versioning, that’s a risk worth addressing. Lockfiles, dependency pinning, and controlled update processes help reduce the risk of pulling in unexpected dependencies.

The question isn’t just whether you stay on top of your dependencies and keep them up to date. You simply have to do so. But, crucially, it has to happen in a controlled, visible way.

2. Review publishing and automation permissions

Publishing credentials, CI/CD workflows, tokens, and repository automations deserve the same scrutiny as user accounts. In some environments, they deserve more.

Least-privilege access matters here. So does understanding exactly who or what can trigger builds, publish packages, or modify workflows.

3. Protect developer and repository access properly

The advisory recommends reviewing high-risk credentials and ensuring MFA is enabled for developer and repository access. That’s not glamorous advice, and is something that should have long been in place - as of 2026’s updates, you can’t be Cyber Essentials certified without MFA in place.

It’s typically the difference between a contained risk and a very expensive one, so if access into development or publishing systems still depends on reused credentials, shared accounts, or inconsistent MFA, then it’s better late than never, and now would be a good time to fix that.

4. Monitor for the quiet warning signs

Whether it’s unexpected dependency version changes, unauthorised workflow edits or something as big as anomalous publishing activity, these are the sorts of indicators that can be missed when teams assume “trusted” parts of the estate do not need the same attention as the perimeter.

What if you are not a software company?

Let’s face it, most of us aren’t. But you can’t take your foot off the gas. You still have work to do, it just looks a little different.

For most UK businesses, the practical response is less about package publishing and more about supplier visibility, access control, and resilience, which means asking sensible questions such as:

• Which suppliers or platforms have privileged access into our environment?

• Which business-critical systems depend on third-party software we rarely review?

• How quickly would we know if a trusted application behaved unexpectedly?

• Do we have any legacy service accounts, automations, or integrations with more access than they need?

• If a supplier issue affected us tomorrow, what would our response actually look like?

That last point matters more than you may perhaps think, as supply-chain incidents can create a strange kind of paralysis because the problem often starts outside your business, but the impact lands inside it. When that happens, organisations need enough visibility and process to respond quickly, even if they are not the ones investigating the root cause.

This is really a trust issue

At its core, supply-chain security boils down to one thing: trust. Not some vague, human sense of trust, but in fundamental operational trust.

What do you trust to run in your environment?
Who approved it?
How is that trust maintained?
And how quickly would you notice if it no longer should be trusted?

All of this falls under the scope of governance, and they definitely don’t require a complex technical background to know and understand.

That’s also why supply-chain security shouldn’t be siloed as “something for developers or IT to worry about”. For many organisations, it belongs in the same conversation as cyber hygiene, supplier management, identity controls, and incident readiness.

A practical place to start

If you think this feels like a big topic, don’t start by trying to solve software supply-chain security in one sweep. Most organisations don’t need a grand programme on day one - if at all ever. What they do need is a realistic first pass, from a sensible starting point like:

• identifying critical suppliers, platforms, and integrations

• reviewing privileged third-party and automation access

• checking whether MFA is consistently enforced for high-risk accounts

• confirming who owns software update and dependency decisions internally

• make sure suspicious changes in key systems would actually be noticed

• testing how you would respond if a trusted supplier became the source of an incident

Now, it’s not a perfect or comprehensive list, sure. But equally, it doesn’t need to be, and it’s a much better place to be than assuming this is only a problem for someone else upstream.

Final thought

If you take nothing else away from this blog (or the advisory), don’t let it be the name of the tool mentioned in the reporting, or the spectacle of cybercriminals turning attack methods into a leaderboard - although that is a first from my perspective.

Instead, use this as a reminder that modern cyber risk often spreads through trust, scale, and dependency. For many UK SMEs and mid-market organisations, that means the real question is no longer “Could we be targeted?” - we’ve established this time and time again, you can, and will be.

With that said, ask yourself this one question: “How many things do we already trust, and how closely are we paying attention to them?”