Imagine your company investing millions in firewalls, EDR, SIEM and security training. Then an attacker gains access via the IT management software you use, software to which you inherently had to grant administrative rights over the entire infrastructure. This is precisely how the 2020 SolarWinds attack worked, affecting over 18 000 organisations including US government agencies.
Supply chain attacks are insidious precisely because they exploit trust. The attacker does not need to breach your defences; they pass through the gates you opened yourself for a legitimate supplier.
Anatomy of a supply chain attack: How they work
A supply chain attack is the compromise of software, hardware or a service that is subsequently used to attack the supplier's customers. There are several basic patterns:
Compromise of the software update mechanism (SolarWinds)
The Russian APT29 group (Cozy Bear) infiltrated the SolarWinds build pipeline and inserted malware (the Sunburst backdoor) directly into a legitimate update for the Orion platform. Customers who automatically applied the updates, as recommended, inadvertently installed the backdoor. The malware remained undetected in systems for months, giving attackers unrestricted access to the victims' critical infrastructure.
Key finding: the update's digital signature was valid because the malware was inserted before signing. Traditional security checks failed to detect it.
Intentional sabotage of an open-source project (XZ Utils 2024)
The XZ Utils case from 2024 revealed another dimension of the threat. An attacker (operating under the pseudonym JiaT75) spent nearly two years systematically building trust within the open-source project community for XZ Utils: a compression library present in practically every Linux distribution. They then deliberately inserted an obfuscated backdoor into the release version, which would have enabled unauthorised SSH access to systems running installed versions 5.6.0 or 5.6.1. The attack was discovered by chance just before mass deployment into distributions.
Compromise of open-source packages (typosquatting, dependency confusion)
Less sophisticated but very widespread attacks target npm, PyPI and other package registries. Attackers upload a package with a similar name (typosquatting: requests location requests) or exploit dependency confusion by uploading a public package with the same name as the company's internal private package but with a higher version number.
Third parties as an attack vector: What threatens you
It is not just about software. Supply chain risks come from many directions:
- Managed Service Providers (MSP)IT companies with administrative access to your infrastructure are extremely attractive targets: an attacker compromises one MSP and gains access to hundreds of its customers at once (the Kaseya case, 2021).
- Third-party SaaS applicationsCRM and HR systems, accounting software, these applications access sensitive company data and their APIs are connected to your infrastructure.
- Hardware and firmwarecompromise of router or server firmware at the manufacturing process or supply chain level. Chinese regulations require manufacturers to cooperate with the government, creating a geopolitical risk.
- The human factorconsultants, temporary workers or supplier employees with access to your systems.
NIS2 and supply chain security
The NIS2 Directive explicitly addresses supply chain risks in Article 21. Obligated entities must implement security measures including security of the supply chain and third-party relationships. This is not a recommendation. It is a legal obligation.
Specifically, this means:
- Identify and document dependencies on third parties (software, hardware, services).
- Conduct security level assessments of key suppliers.
- Contractually anchor safety requirements towards suppliers.
- Monitor security incidents at suppliers and be informed of their occurrence.
Failure to meet these requirements may result in fines of up to 10 million EUR or 2% of global turnover, with liability that cannot be delegated to suppliers. It is your risk.
How to assess a supplier: A practical guide
Supplier categorisation by criticality
Not all suppliers carry the same level of risk. Start with classification:
- Critical suppliers (Tier 1)direct access to your infrastructure, process sensitive data or are essential for operational continuity. Examples: SMEs, cloud platforms, ERP systems.
- Important suppliers (Tier 2)indirect data access, SaaS applications, developer tools.
- Other suppliers (Tier 3)minimal access to systems or data.
Security due diligence
For Tier 1 and Tier 2 suppliers, carry out:
- Security Level Questionnaire (SIG: Standardized Information Gathering Questionnaire or CAIQ).
- Request for security certifications: ISO 27001, SOC 2 Type II, Cyber Essentials Plus.
- Review of penetration tests and security audit results (under NDA).
- Review of vulnerability management and patch management policies.
- Verification of how the supplier handles security incidents and whether they have their own IR plan.
Contractual safety requirements
Every contract with a critical supplier should include:
- Obligation to report security incidents within 24–72 hours of their detection.
- Right to an audit or a third-party security assessment.
- Requirements for minimum security standards (data encryption, access management, MFA).
- Conditions for subcontractors: passing your safety requirements through the entire supply chain.
- Procedure for terminating cooperation: data deletion, access revocation, handover of documentation.
- Contractual penalties or the right to terminate the contract in the event of a serious security failure.
Technical measures for protection against supply chain attacks
Contractual and procedural measures are not enough. You also need technical safeguards:
- Software Bill of Materials (SBOM)Demand an SBOM: a list of all components and dependencies: from software suppliers. This enables quick identification of whether the software you use contains a vulnerable component (such as Log4Shell in 2021).
- Code signing and integrity verification. Verify digital signatures for all software updates. For critical systems, implement detailed hash verification of delivered binary files.
- Dependency monitoringtools such as Dependabot, Snyk or OWASP Dependency-Check continuously monitor your open-source dependencies and alert you to CVEs.
- Zero Trust architectureand trustworthy suppliers should have access only to what is strictly necessary. Micro-segmentation, just-in-time access, and continuous identity verification.
- Monitoring of third-party activitylog and analyse external access activity, anomalies (access outside working hours, unusual data volumes) may indicate compromise.
Compiling a comprehensive third-party security management programme is a complex project. SecureOn.cz assists organisations with supplier inventory, their assessment and the implementation of contractual and technical measures in compliance with NIS2.
Conclusion: Security is only as strong as its weakest link.
Supply chain security is not an extra. It is a basic requirement for managing the modern threat landscape. Attackers are pragmatic: they strike where resistance is lowest. If your direct suppliers do not have an adequate security level, they become your weakest link.
Start with what is feasible: map critical dependencies, request security certifications from key suppliers, and incorporate basic requirements into new contracts. Gradually build a comprehensive programme. NIS2 provides both the obligation and the framework to do so.