What is a Supply Chain Attack? When the Software You Trust Becomes the Threat

In 2020, an IT company called SolarWinds shipped a routine software update to around 18,000 of its enterprise customers. The update contained a hidden backdoor that attackers had embedded in the build process months earlier. Among those customers were the US Treasury, the Department of Homeland Security, and dozens of Fortune 500 companies. None of them were breached directly. They were breached through software they had trusted completely, and updated without question.

That is a supply chain attack. The target is not you. The target is someone you depend on.

What makes it a supply chain attack?

A supply chain attack exploits the trust relationships between an organisation and its vendors, contractors, libraries, or service providers. Rather than attacking you head-on, the attacker compromises something upstream and then waits for their malicious code to reach you through a channel you would accept regardless.

The term "supply chain" comes from manufacturing: if an attacker wants to poison a product, it is often easier to tamper with a component at the factory than to intercept every finished product at the destination. Software and digital services work the same way.

The specific channel varies by attack:

• Software build pipeline: Malicious code is inserted into the build or compilation process (SolarWinds, XZ Utils)
• Package repositories: A popular open-source library is replaced or typosquatted on npm, PyPI, or RubyGems
• Third-party scripts: A JavaScript file served from a vendor's CDN is modified after the vendor is compromised
• Managed service providers: An IT firm with access to many client networks is breached, giving attackers a foothold in all of them

Real examples that changed how security teams work

SolarWinds (2020)

The SolarWinds Orion platform is IT infrastructure monitoring software used by large enterprises and government agencies. Attackers compromised SolarWinds's build pipeline and inserted a dormant backdoor called SUNBURST into routine software updates. The backdoor activated after a delay and communicated with attacker infrastructure.

Because the update was signed by SolarWinds and distributed through normal channels, most security tools treated it as legitimate. The breach was not discovered for months. US intelligence agencies concluded it was one of the most significant cyber espionage campaigns in history.

XZ Utils (2024)

XZ Utils is a standard compression library present in most Linux distributions. Over a two-year period, a sophisticated attacker built trust within the open-source project under a false identity, gradually gaining commit access. Shortly before the malicious version was due to be incorporated into major Linux distributions, a Microsoft engineer noticed unusual CPU usage during an SSH login, investigated, and discovered a backdoor targeting systemd-linked SSH configurations.

The attack was stopped before widespread deployment, but it illustrated how much of modern software infrastructure depends on the work of individual open-source maintainers who receive no funding and have no security review process.

Magecart and compromised third-party scripts

For ecommerce merchants, the most directly relevant supply chain attacks are those targeting JavaScript vendors whose scripts run on checkout pages.

In the British Airways breach, attackers compromised a third-party analytics script. Because British Airways trusted and loaded that script on their payment page, every customer who visited the checkout during a 15-day window had their card details quietly copied and sent to the attacker.

This pattern has repeated across hundreds of Magecart incidents. The common factor is always a third-party script that a merchant trusted, loaded, and had no visibility into after the initial setup.

Why this is particularly hard to defend against

The challenge with supply chain attacks is that the usual defences do not help:

Firewalls and perimeter security do not block code that arrives through a legitimate, expected channel.

Antivirus and endpoint security cannot inspect the internal build pipeline of a third-party vendor.

Code reviews cannot catch code that looks identical to the legitimate version until a backdoor activates.

HTTPS and certificate validation confirm that the script came from the expected domain, but say nothing about whether the content at that domain has been tampered with.

What does help is a different posture: assume that any third-party dependency could be compromised, and build controls that detect or limit the impact when it happens.

Defences for ecommerce checkout pages

Content Security Policy

A Content Security Policy (CSP) header tells the browser which script sources are permitted to run on a given page. A well-configured CSP means that if an attacker serves a new malicious script from an unexpected domain, the browser refuses to execute it.

CSP is not a complete solution on its own. A compromised vendor that modifies a script already on your allowed list can still cause harm. But it significantly raises the bar and blocks the majority of injection attempts that do not come through a trusted vendor.

Subresource Integrity

Subresource Integrity (SRI) lets you specify a cryptographic hash of a specific script file in the <script> tag that loads it:

<script
  src="https://vendor.example.com/analytics.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K..."
  crossorigin="anonymous"
></script>

When the browser fetches the script, it checks whether the file matches the hash. If the vendor's CDN has been compromised and the file has changed, the hash will not match and the browser will refuse to run it.

The limitation is maintenance: you must update the hash every time the vendor ships a legitimate update. For frequently-updated third-party scripts this creates friction, which is why SRI is most practical for scripts that change infrequently.

Reduce the number of third-party scripts on your payment page

Every script you load from an external source is a potential supply chain vector. Review what is actually running on your checkout page. Analytics, advertising pixels, personalisation tools, and heat mapping scripts are rarely necessary on the payment step itself, and removing them shrinks your attack surface considerably.

Monitor for changes

Even with good preventive controls, something may slip through. Change detection on your payment page, whether through a dedicated monitoring service or a continuous scanning workflow, gives you a chance to respond quickly when something unexpected appears.

What to do now

If you want to know immediately how your payment page stands, our free Payment Page Security Checker analyses your checkout URL for CSP configuration, SRI coverage, unexpected script sources, and other indicators of supply chain exposure, in about 30 seconds.

If you want a more thorough assessment, including an audit of every third-party dependency on your payment page and a remediation plan, talk to us. Supply chain risk on checkout pages is something we work on specifically with ecommerce merchants, and the right approach depends on your platform and setup.

The most important thing is to stop thinking of third-party scripts as someone else's responsibility. Once they run on your page, they are yours.