A supply chain attack is a breach in which attackers compromise a trusted supplier, such as a software vendor, open-source component, managed service provider or cloud service, and use that trust to reach the supplier’s customers. Instead of attacking each target directly, the attacker gets in once upstream and lets the normal relationship, such as a software update or remote support connection, carry the attack downstream. It is one kind of third-party breach, a broader term that also covers incidents where a supplier is breached and customer data it holds is exposed without the attacker reaching customers’ own systems.
At a glance
- The attack enters through something you trust: an update, a library, a provider’s remote access or an integration.
- One compromised supplier can affect many customers at once.
- Common paths include tampered software updates, malicious open-source packages and breached IT service providers.
- Defenses focus on limiting supplier access, vetting suppliers and detecting unusual behavior from trusted tools.
- Customers and regulators increasingly ask how you manage your own suppliers’ risk.
What problem it solves
As a term, it names a risk that ordinary perimeter thinking misses. Most organizations rely on dozens or hundreds of suppliers: software vendors pushing updates, an MSP with admin access, SaaS apps connected to email and file storage, and open-source code inside nearly every application. Each of those connections is trusted by default, often with broad permissions and little monitoring.
Attackers know that. Compromising one widely used product or provider can give them access to many organizations at once, through channels security tools are often configured to allow. Several well-publicized incidents have followed this pattern, from tampered update servers to compromised remote management tools used by service providers. Understanding the attack type helps buyers ask the right questions of vendors and design access so a supplier compromise does less damage.
How it works
Compromise the supplier. Attackers break into a vendor’s build systems, code repository, update infrastructure or support tools, or publish a malicious package under a name developers are likely to use.
Ride the trusted channel. The tampered update is signed and distributed normally, the malicious library is pulled into builds, or the provider’s remote tools are used to connect to customer systems.
Act inside customers. Once in, attackers steal data, deploy ransomware, create persistence or move laterally, often looking like legitimate vendor activity.
Defenses usually combine:
- Supplier vetting: security questionnaires, certifications and contract terms covering breach notification and security obligations, as part of vendor management.
- Limiting access: least privilege for vendor accounts and integrations, MFA, time-limited access and separate admin credentials.
- Visibility: an inventory of suppliers, software and components, sometimes with a software bill of materials (SBOM).
- Detection: monitoring for unusual behavior from trusted tools and accounts, not only from unknown ones.
- Response: a plan for when a supplier announces a breach, including how to cut off its access quickly.
When it matters for buyers
- When a supplier or peer is breached. You’ll need to know quickly what that vendor can reach and how to revoke it.
- When onboarding an MSP or remote support provider. Their tools and accounts are among the most powerful in your environment.
- When connecting SaaS apps. Each integration’s permissions to email, files and identity are a potential path in.
- When customers send their own supplier questionnaires. You’re part of their supply chain, and they will ask how you manage yours. Our governance, risk and compliance and vulnerability management overviews cover the programs that track this.
Questions to ask vendors
- What access will your staff, tools or software have in our environment, and can it be limited?
- How do you secure your software build and update process?
- How quickly will you notify us of a breach that could affect us, and is that in the contract?
- Do your remote access tools require MFA, and are sessions logged and available to us?
- Can you provide a software bill of materials for your product?
- Which of your own suppliers have access to our data?
How it differs from a zero-day exploit
A zero-day vulnerability is a flaw that is unknown to the vendor or has no fix available yet; it describes the weakness. When attackers use such a flaw, that is a zero-day exploit or attack. A supply chain attack describes the route: getting in through a trusted supplier. The two can overlap, since a supply chain attack may begin with a zero-day exploit against the supplier’s systems, but many supply chain attacks use stolen credentials or tampered code instead, and many zero-day exploits are used directly against their targets.