What Is a Supply Chain Cyberattack?
A supply chain cyberattack enters an organisation not through a direct attack on its own systems, but through a trusted third party. A software vendor, a managed service provider, a hardware supplier, a contracted partner with privileged access to the target's environment.
The SolarWinds attack in 2020 demonstrated what this vector can produce at scale. Attackers compromised the software build process of a widely-used IT management platform and distributed a backdoored update to approximately 18,000 customer organisations, including government agencies and large enterprises. The malicious code was signed with legitimate certificates and delivered through the vendor's normal update channel, exactly the kind of trusted path that security controls are typically configured to allow through.
What made SolarWinds significant was not just its scale but its mechanism. It exploited the implicit trust organisations place in their software supply chain. Security teams had no reason to distrust a signed update from a vendor whose integrity they had no independent means to verify. The attack succeeded because the failing was not technical. It was organisational and behavioural.
How Should Organisations Train for Supply Chain Attacks?
Build workforce capability across three distinct phases: recognition of the risk vectors, response when a compromise is suspected, and recovery discipline that limits blast radius.
Recognition training must address the specific indicators that distinguish supply chain compromise from direct attack. Staff responsible for vendor management, software procurement, software engineering, and security operations need to understand how trust is exploited in their specific domain. A developer who does not question a dependency update pulled from a package repository and a procurement manager who does not scrutinise access permissions granted to a new supplier represent different but equally significant risk points.
LimitedView research across 847 organisations found that 73% of security incidents involve a human decision point, compared to 12% attributable to purely technical failures. Supply chain attacks illustrate this finding sharply. In most SolarWinds-affected environments, the technical controls were functioning correctly. The gap was in the human decisions made at the boundary where trusted third parties enter the organisation.
Response training needs tabletop exercises designed specifically around the supply chain scenario, not adapted from direct-attack playbooks. The response calculus is different. When the compromise vector is a trusted supplier, the immediate questions concern isolation of supplier access, identification of all systems and data the supplier could have reached, and external communication to the supplier and potentially to affected customers. Teams that have not rehearsed this sequence will default to direct-attack protocols that do not map to the problem.
What Lessons Can Teams Learn From Past Supply Chain Incidents?
The incidents worth studying, SolarWinds, the Kaseya VSA ransomware attack, the Codecov breach, the 3CX compromise, share structural lessons that apply directly to training and resilience programme design.
Supplier trust is not the same as supplier verification. Organisations routinely onboard suppliers and grant access without establishing ongoing verification that the supplier's security posture has not changed since initial due diligence. Training should build habits of periodic re-assessment, not just intake process discipline.
Access privilege tends to expand and is rarely reduced. Managed service providers in particular accumulate access that was originally scoped narrowly and becomes broadly permissive as engagements evolve. Staff responsible for supplier relationships should treat access creep as a routine risk management concern, not an edge case to handle eventually.
Detection depends heavily on human alertness to anomalies in trusted channels. The Codecov breach was discovered because a customer noticed a hash mismatch in a script they had downloaded many times before. A small deviation from expected behaviour in a trusted context. That kind of anomaly recognition is a trainable skill, and it is one of the higher-value capabilities an organisation can develop in technical staff.
Response speed matters enormously. In supply chain attacks affecting multiple downstream customers, the window between public disclosure and active exploitation narrows fast. Organisations with rehearsed response capabilities contained damage more effectively than those improvising. LimitedView's research across over 650,000 employees found measurable correlation between training programme depth and time-to-containment following incidents.
How Do You Build a Third-Party Risk Training Programme?
Structure it around the roles with the most consequential supplier interactions: procurement, IT and security operations, software engineering, and senior leadership who sign off on vendor agreements.
Each audience needs content calibrated to their specific decision points. Procurement staff benefit from training on what security questions to ask during onboarding and how to interpret supplier security posture evidence. Software engineers need training on dependency management risks, code integrity verification, and the security implications of open-source package consumption. Security operations staff need playbooks and exercises for supply chain-specific detection and response scenarios.
Key training elements:
- Supplier access audit exercises that train staff to identify and challenge excessive permissions in existing supplier relationships
- Tabletop scenarios modelled on SolarWinds, Kaseya, and similar incidents, adapted to the organisation's actual supplier ecosystem
- Anomaly recognition modules that build the habit of questioning unexpected behaviour from trusted systems and communications
- Incident communication drills that rehearse the multi-party coordination supply chain breaches require, with the supplier, with affected internal teams, and potentially with regulators and customers
- Software supply chain hygiene for engineering teams: dependency pinning, checksum verification, and build pipeline integrity controls
Supply chain attack training does not replace technical controls. It builds the human layer that technical controls depend on. That layer is where the majority of supply chain incidents ultimately find their entry point.
