Supply-chain attacks: when the supplier becomes the entry point
Supply-chain attacks do not target the organisation directly but a service provider, a software update or a library in the supply chain. Cases such as SolarWinds, 3CX or XZ-Utils show that attacks often take effect weeks to months later, simultaneously across many target environments. For Swiss organisations, detection in their own SOC matters most, alongside prevention through vendor risk management, SBOM and signature verification. The SOC detects suspicious activity from legitimate software and segments third-party access. During an incident, it identifies which impacts trigger notification duties under revFADP (revised Federal Act on Data Protection), FINMA and ISG.
Scope: supply chain vs ransomware vs incident response
This page covers supply-chain attacks as an entry path: compromised software, libraries, managed service providers or cloud suppliers. If an attack encrypts data or disables systems, consult Ransomware and backup strategy and the Incident response plan. For trends in how AI scales supply-chain attacks, see AI-driven cyber attacks. For continuous visibility into your attack surface, see Attack Surface Management.
A supply-chain attack provides the entry path. Ransomware or data exfiltration is the effect. The SOC and reporting processes must address these aspects separately.
Typology: four ways into your environment
| Type | Example | What the victim often does not see |
|---|---|---|
| Compromised software update | SolarWinds Orion 2020, 3CX 2023: signed update with backdoor. | The binary is correctly signed; conventional signature checks raise no alerts. |
| Compromised open-source library | XZ-Utils 2024 (CVE-2024-3094): backdoor smuggled into a compression library over months. | Without an SBOM and dependency tracking, organisations can overlook the affected version in their own stack for a long time. |
| Compromised managed service provider | Kaseya 2021: MSP tool became a ransomware distributor for end customers. | The MSP holds legitimate admin rights; actions look like routine maintenance. |
| Compromised cloud or SaaS supplier | Compromised identity provider, ticketing vendor or monitoring SaaS with broad permissions. | Data exfiltration uses legitimate API paths; organisations often learn about it only through vendor notification. |
Regulatory framework in Switzerland
- revFADP (revised Federal Act on Data Protection): if a supply-chain incident makes access to personal data likely, the controller must notify the FDPIC as soon as possible where a high risk to the persons concerned is likely. The controller remains accountable even if the processor was compromised. See revFADP and SOC.
- ISG notification duty: affected critical infrastructure operators report cyber incidents to the National Cyber Security Centre (NCSC) within 24 hours. This also applies to attacks that enter through a supplier. See SOC and ISG reporting.
- FINMA: institutions report material cyber attacks under Art. 29 para. 2 FINMASA (Guidance 05/2020, refined by Guidance 03/2024): initial notification within 24 hours of discovery, full report within 72 hours. These duties cover vendor compromises that affect critical processes. See SOC and FINMA requirements.
- DORA: for financial entities within EU scope, Articles 28 to 44 govern ICT third-party risk management. They cover registers, exit strategies and oversight of critical ICT providers. Supply-chain detection in the SOC provides the evidence. See DORA SOC requirements.
- Cyber insurance: exclusions and deductibles for third-party cases differ; without solid vendor evidence coverage can shrink. See SOC and cyber insurance.
Effective defence: prevention plus SOC detection
- Vendor risk management: contractual security assurances (SOC 2, ISO 27001, notification windows to the customer), regular reviews, documented criticality per vendor.
- SBOM and dependency inventory: track libraries and their versions in your own and purchased software. This enables you to respond within hours to incidents such as XZ-Utils.
- Segmentation of third-party access: dedicated admin accounts, just-in-time rights, separate account per vendor, no shared login.
- SOC detection on behaviour, not signature: legitimate software with anomalous network, process or identity behaviour must stand out. A mature SOC correlates EDR, SIEM and ITDR signals. See Threat hunting Switzerland and ITDR.
- Continuous view of the attack surface including vendor-integrated assets, see Attack Surface Management.
- Recovery capability: define immutable backups and recovery targets; see Ransomware and backup strategy.
Notification duties under revFADP (revised Federal Act on Data Protection), FINMA and ISG remain with the accountable organisation. The supplier provides facts; the customer submits notifications. Organisations cannot meet the deadline without reliable telemetry of their own and documented processes, even if the vendor cooperates.
Supply-chain detection in SOC operations
The SOC as a Service Switzerland pillar page explains how detection of third-party and vendor events fits into continuous 24/7 operations. It covers threat hunting, correlated playbooks and notification processes.
Legal basis and sources
- FINMA Guidance 05/2020 on reporting cyber attacks (Art. 29 para. 2 FINMASA): finma.ch
- FINMA Guidance 03/2024 refining the reporting duty: finma.ch
- ISG (SR 128), Art. 74a-74f: Fedlex
- ISG reporting duty at the National Cyber Security Centre (NCSC) including routing: bacs.admin.ch
- Reporting data security breaches to the FDPIC: edoeb.admin.ch
Frequently asked questions
How does this differ from a conventional ransomware attack?
The difference is the entry path. Conventional ransomware often comes via phishing or an exposed service. Supply-chain attacks come via trusted software or a legitimate service provider. The effect can be identical but detection and notification logic differ. See [Ransomware and backup strategy](/en/soc/ransomware-backup-strategy).
Who is liable when the supplier is compromised?
Under revFADP (revised Federal Act on Data Protection), the controller remains accountable; a compromised processor does not remove the notification duty. The organisation may have contractual rights of recourse, but it retains the notification duty under public law. See [revFADP and SOC](/en/soc/revdsg-and-soc).
Is a vendor SOC 2 report a sufficient safeguard?
A SOC 2 report is one important part of your safeguards. SOC 2 documents controls at a point in time; it does not detect an ongoing compromise. You also need contractual deadlines for notifying customers, your own detection capabilities and a rehearsed incident procedure.
How does a SOC detect a supply-chain attack when the software is signed?
The SOC detects suspicious behaviour even when software is signed. Correlated detection flags legitimate software with unusual C2 traffic or new persistent services. It also flags atypical permissions in the identity provider or unexpected data exfiltration. Threat hunting is the most important method here. See [Threat hunting Switzerland](/en/soc/threat-hunting-switzerland).
Which vendor events should immediately trigger an internal case?
Trigger a case when a vendor reports a security incident, you suspect a compromised update, or a library in use has a high-severity CVE. Unexpected MSP configuration or permission changes and anomalies in vendor account login patterns also require immediate cases. Log each event directly in the SOC ticketing system with a defined SLA.
Related terms
- Supply Chain Attack A supply chain attack targets an organisation through a trusted supplier, software, or service provider with access.
- CVE CVE is the global directory of publicly known security vulnerabilities where each vulnerability receives its own identifier.
- Vulnerability Management Vulnerability management is the ongoing process of finding weaknesses, assessing them by risk, and verifying their remediation.
- IOC An Indicator of Compromise (IOC) is a technical characteristic that indicates a potential security breach.