Software Supply Chain Attacks: A Practical Defence Checklist

A software supply chain attack happens when an attacker compromises a vendor, an open source package, or a build system you rely on. They then use that trusted relationship to reach your business, without ever touching your own network directly. You do not get breached. Something you already trust gets breached, and you inherit the consequences the moment you install it.

For a UK business, the practical question is not whether a software supply chain attack can happen. It already has, repeatedly, to organisations far bigger than most SMEs. The useful question is what you can actually check and change this quarter to reduce the odds it happens to you.

Where a Software Supply Chain Attack Actually Gets In

Three entry points account for almost every reported case:

• A compromised build or update system. The vendor’s own software factory gets breached, and malicious code rides out in a signed, apparently legitimate update.
• A poisoned open source package. Sonatype’s 2026 State of the Software Supply Chain report puts the average application at around 180 dependencies. Attackers now routinely upload malicious packages under names that look like popular libraries.
• A breached supplier or contractor. Think of an IT provider, a payroll processor, a software contractor. Whoever has legitimate remote access to your systems becomes the attacker’s access too, the moment their environment is compromised.

Two well-known cases still explain why this route works so well. The 2020 SolarWinds breach ran through a compromised build system. A routine Orion software update reached an estimated 18,000 organisations. NotPetya spread the same way in 2017, through a hijacked update to the M.E.Doc accounting package. It cost Maersk alone $200 to $300 million, once the attack forced a rebuild of roughly 45,000 machines.

Why a Software Supply Chain Attack Is Now a Weekly Occurrence

Sonatype recorded more than 454,600 new malicious open source packages in 2025, a 75% increase on the year before. Over 800 of those packages were tied to North Korea’s Lazarus group, and almost all of that activity sat on npm. Two npm incidents on Aardwolf’s own radar this year fit the pattern exactly: the self-replicating Shai-Hulud worm, and a Lazarus-linked attack on the Rollup project. Both started with a familiar-looking package and a quiet compromise, and both reached thousands of downstream projects before anyone flagged it.

Verizon’s 2025 Data Breach Investigations Report found something stark. Third-party involvement in confirmed breaches doubled in twelve months, from 15% to 30%. That is not a rounding change. It is a sign that attackers have worked out where the weak points sit.

A Practical Checklist for Reducing Software Supply Chain Attack Risk

Do this month

• List every third-party vendor, contractor and managed service provider with access to your systems or data, and note what that access actually allows.
• Ask any supplier building custom software for you whether they can produce a software bill of materials. That is the itemised list of components CISA now recommends as a baseline. If they cannot answer, that is itself useful information.
• Check whether your team auto-updates open source packages without review. If so, turn that off for anything running in production.

Do this quarter

• Commission a secure code review of your most business-critical application. Focus it specifically on dependency handling and build pipeline access, not just your own code.
• Segment supplier and contractor access so a single compromised vendor cannot reach your entire network. Least privilege applies to third parties just as much as staff.
• Set up alerts for security advisories on the specific packages and platforms you actually run. Do not rely on general news coverage to catch a relevant flaw.

Keep doing, always

• Follow the National Cyber Security Centre’s four-stage approach: understand your risks, establish control over suppliers through contracts, check that those arrangements hold up in practice, and keep improving as your supply chain changes.
• Treat vulnerability management as an active discipline, not a dashboard you check once a quarter. A new advisory about a package you use should get a same-week response.
• Revisit the list you made this month. Suppliers change, contracts lapse, and access nobody remembers granting tends to be the access nobody is watching.

What to Do If a Software Supply Chain Attack Might Have Hit You

Suppose a vendor or package you use turns up in a breach notification or a security advisory. Treat the response as time-sensitive, not something to schedule for next week. Identify every system that uses the affected component first. Then isolate it from anything sensitive. Check for signs of compromise while you do: unexpected outbound connections, new accounts, or configuration changes nobody on your team made.

Do not wait for the vendor to confirm the worst case before you act. In both the SolarWinds and NotPetya incidents, businesses that moved quickly on the first advisory fared noticeably better. Those who waited for a fuller picture lost weeks they did not have. Speed matters more than certainty in the first 48 hours.

Once the immediate exposure is contained, feed what you learned back into your supplier list. A component that was compromised once is worth watching more closely afterwards, not treating as resolved the moment a patch appears.

What This Does Not Fix

None of the above stops a determined, well-resourced attacker from ever succeeding. What it does is close the easy routes: the auto-updated package nobody reviewed, the contractor access nobody revoked, the build pipeline nobody tested. Most reported incidents exploit exactly those gaps, not some novel technique. That is also why closing them is worth the effort.

Want an independent check on where a software supply chain attack could exploit your build environment or supplier relationships? Aardwolf Security’s penetration testing team can scope a test around exactly that. Get in touch to talk through a sensible first engagement.

Frequently Asked Questions

How is a software supply chain attack different from a normal cyberattack?

The target is different. A normal attack goes after your network directly. A software supply chain attack goes after something you trust first: a vendor, a package, an update. It uses that trust as the way in. The consequences can look identical once the attacker is inside.

We are a small business. Are we really at risk?

Yes, and size rarely matters here. Most incidents hit every user of a compromised package or vendor at once, regardless of how big each victim is. If you use the affected software, you are in scope.

What should we actually ask a software supplier?

Ask whether they maintain a software bill of materials. Ask how they vet third-party dependencies, and whether their build environment has been independently tested. A supplier that cannot answer any of those questions has not thought about this seriously yet.

Can antivirus software catch a supply chain attack?

Rarely, at least not straight away. The malicious code usually arrives signed, from a legitimate-looking source. That is exactly what antivirus tools are built to trust. Detection tends to come from noticing unusual behaviour afterwards, not from blocking the file on arrival.

Is this only a problem for software companies?

No. Every business that runs software, which is every business, has a supply chain of vendors, packages and updates behind it. Retailers, law firms and manufacturers have all been affected by incidents like these. Each one started with a supplier or a package, not their own code.