The SolarWinds attack changed how the security industry thinks about trust. A software update from a trusted vendor became the delivery mechanism for one of the most significant espionage campaigns in recent memory. The lesson was uncomfortable: your supply chain is part of your attack surface, whether you manage it or not.
Supply chain attacks work because they exploit existing, trusted relationships. The target organisation’s defences are not breached directly. Instead, attackers compromise a supplier, a software component, or a build pipeline and use that foothold to reach their actual target.
How Supply Chain Attacks Work
Software supply chain attacks are the most technically complex. Attackers target the development or distribution process of legitimate software. They inject malicious code into a legitimate product, which then gets distributed through the vendor’s normal update channels. Every organisation running that software becomes a potential victim.
Managed service provider (MSP) compromises follow a similar logic. MSPs typically have deep access to their clients’ networks for monitoring and management purposes. An attacker who compromises an MSP can leverage that access across dozens or hundreds of client environments simultaneously.
Third-party web content is a less dramatic but more common vector. Analytics scripts, chat widgets, and advertising networks all introduce third-party JavaScript into web applications. A compromised CDN or analytics provider can inject malicious code into thousands of websites with a single change.
The Assessment Gap
Most organisations do not assess their suppliers the same way they assess their own environments. Security questionnaires are sent, compliance documents are returned, and the relationship proceeds on the basis that the supplier has answered honestly. That process catches very little.
Web application penetration testing of your own applications should include examination of third-party components. Outdated libraries, vulnerable dependencies, and insecure API integrations with third-party services are all in scope. What your application pulls in from the outside world is your responsibility.
Contractual security requirements matter. Organisations that include security testing obligations, incident notification timelines, and audit rights in supplier contracts are better positioned to manage third-party risk. Few do this consistently.
Managing Third-Party Risk Practically
Start with a supplier inventory. Know who has access to your network, your data, and your systems. Prioritise suppliers by the access they hold and the sensitivity of the data they touch.
Internal network penetration testing can help you understand how an attacker might move through your environment if they gained access via a third-party connection. Understanding the internal blast radius of a supplier compromise shapes how you design access controls.
Software composition analysis (SCA) tools can automate the identification of vulnerable open-source components in your own applications and pipelines. Running SCA as part of your CI/CD process ensures you catch issues before they reach production.
Implement network segmentation for third-party connections. MSP and supplier access should be restricted to the systems they specifically need to reach, with logging and alerting on that activity.
A Shared Responsibility
Supply chain security is a shared problem. Individual organisations cannot solve it alone. But the steps that improve your own resilience strong access controls, tested software pipelines, and active supplier risk management meaningfully reduce your exposure. The organisations caught out by supply chain attacks are rarely those that had these fundamentals in place.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
“Supply chain attacks are effective precisely because they exploit trust. We encourage clients to treat every third-party integration as a potential entry point and to test accordingly. Your attack surface does not end at your own perimeter.”
