A supply chain attack compromises an organization indirectly, by breaching a trusted supplier, software vendor or service provider and using that trust as the path in.
Key facts
- Types span software supply chain (malicious code in a trusted product or update) and business/email supply chain (a compromised supplier''s mailbox used against its customers, i.e. vendor email compromise).
- Regulators now mandate supply chain security explicitly: NIS2 and DORA both require managing third-party and ICT provider risk (verify current text and thresholds against the official sources).
- The trust relationship is the vulnerability: attackers do not need to break your controls if they can enter through a supplier whose messages, software or access you already trust.
The two faces of supply chain attacks
The software supply chain is the headline variant: attackers compromise a widely used product, library or build pipeline, and the malicious update reaches everyone who trusts the vendor. The email and business supply chain is the everyday variant: a supplier''s mailbox is compromised and used to send invoices, contracts or payment changes to that supplier''s customers. Both exploit trust; only the surface differs. Sentaro''s relevance is the email and OAuth dimension, not software supply chain security.
The email supply chain specifically
Vendor email compromise is a supply chain attack: a breached supplier is a breach of everyone who trusts them. The fraudulent invoice arrives from the real supplier''s real mailbox, passes authentication, and lands inside a genuine payment thread. See vendor email compromise and business email compromise. The paying organization typically bears the loss, and increasingly the regulatory obligation to have controlled for it.
Why regulators care
Under NIS2, essential and important entities must include supply chain security in their risk management, including direct suppliers and service providers. DORA requires financial entities to manage third-party ICT risk and maintain a register of ICT third-party arrangements. The cascade means requirements flow down to suppliers, and organizations must be able to evidence how they manage the risk their vendors carry into their environment. Verify current specifics against the official regulatory sources before relying on them for compliance decisions.
How to defend
Vendor risk assessment tied to what each supplier can actually touch; contractual requirements aligned to the regulations you sit under; least-privilege third-party access, especially for OAuth grants that reach mail, files and identities; and continuous monitoring of the trusted communications and integrations suppliers and SaaS tools hold. Third-party risk lives at the intersection of paperwork and runtime evidence; both are needed.
How Sentaro helps
Sentaro detects compromised-vendor email and supplier impersonation in mail flow, and surfaces the third-party and OAuth access held against your Google Workspace or Microsoft 365 environment. That feeds third-party risk registers and the supplier-security evidence NIS2 and DORA both expect, on the email and identity dimension of supply chain risk (not on software supply chain security).