A supply chain cyber attack compromises something a victim already trusts, such as a software vendor, an open source package, a service provider or a build pipeline, and uses that trust to get in. Because the access looks authorized, perimeter controls rarely flag it. MITRE ATT&CK describes the technique as manipulating products or delivery mechanisms before consumers receive them. See also the tj-actions GitHub Action compromise and Axios npm package compromise incident pages.
The perimeter model of cybersecurity assumes that threats come from outside the organization trying to get in. Supply chain attacks break that assumption at the foundation. They enter through a vendor you already trust, a software component your developers already depend on, a service provider whose access you already granted. By the time the attack is visible, it has been inside for months, using credentials and pathways the organization itself established.
Supply chain compromise is now a standing concern for security teams. ENISA’s Threat Landscape 2025 reports that cybercriminals have intensified their efforts to abuse critical dependency points, for example in the digital supply chain.
This blog examines what is driving this trend, how the most significant supply chain attacks of 2024 and 2025 actually worked, why traditional security controls are structurally unable to stop them, and what a credible response looks like.
What Is a Supply Chain Cyber Attack?
A supply chain cyber attack targets a victim indirectly by first compromising something the victim trusts: a software vendor, a managed service provider, an open source component, a build pipeline, or a support portal. The attack exploits the trust relationship between the victim and the third party, using that trust as the entry path that bypasses the victim’s own security controls.
The defining characteristic is that the victim organization did not make the mistake that created the vulnerability. The compromised software update was signed by the legitimate vendor. The malicious package carried the same name as the legitimate one. The service provider credentials were valid. From the perspective of every security control the victim had in place, the traffic looked authorized, the files looked legitimate, and the access looked normal.
This is what makes supply chain attacks categorically different from other threat vectors and why the security industry’s traditional response, build higher walls and better filters, cannot address them. The attack enters through a door the organization deliberately left open.
| Attack Type | Entry Mechanism | Why Traditional Controls Miss It |
| Software update hijack | Attacker compromises a vendor’s build or update infrastructure; malicious code is signed with the vendor’s legitimate certificate and distributed as a routine update | Code signing verification passes because the attacker used the real signing key; the update arrives through the expected channel |
| Open source package compromise | Attacker publishes a malicious package under a legitimate package name (typosquatting), takes over an abandoned package, or inserts malicious code into a maintained package | Package managers install whatever the dependency file specifies; no signature mismatch, no network anomaly |
| Managed service provider (MSP) pivot | Attacker compromises an MSP’s administrative access to customer environments and uses legitimate management tools to move laterally across all customer networks simultaneously | MSP access is pre-authorized; lateral movement uses legitimate administrative tools that generate no malware detections |
| Vendor support portal compromise | Attacker uses stolen credentials to access a vendor’s customer support platform and extracts data on all customers or uses the access to push malicious configurations | Access uses valid credentials; no vulnerability exploitation, no malware deployment |
| CI/CD pipeline injection | Attacker gains access to a target’s or vendor’s build pipeline and injects malicious code that is compiled into the application before it ships | The malicious code is built and signed by the legitimate build process; delivered as a legitimate application update |
How Is a Supply Chain Attack Executed? Three Landmark Cases
Case Study 1: XZ Utils (2024): The Two-Year Long Game
The XZ Utils backdoor is one of the most technically sophisticated supply chain attacks publicly documented. Beginning in 2021, a threat actor operating under the identity ‘Jia Tan’ spent approximately two years contributing legitimate, high-quality code to the XZ Utils open source project, a data compression library present in virtually every Linux distribution. Over that period, the actor built trust with the existing maintainer, gradually assumed co-maintainer status, and systematically worked toward inserting a backdoor.
The backdoor itself, inserted in early 2024, was concealed in test files attached to the repository rather than in the primary source code. It targeted SSH authentication specifically, bypassing the standard authentication mechanism for connections made by the attacker’s key. The attack was discovered accidentally by a Microsoft engineer who noticed that a system running a pre-release version of the compromised library had slightly higher CPU utilization than expected during SSH connections.
Had it not been discovered, the backdoor would have shipped in stable releases of Debian, Fedora, Red Hat, and other major Linux distributions, providing the attacker with unauthorized access to an effectively uncountable number of systems. The attack required no vulnerability. It required trust, patience, and a two-year investment in building a legitimate reputation.
- Build trustThe actor contributes legitimate code to the project for about two years.
- Become co-maintainerThe actor works alongside the existing maintainer and gradually takes on the role.
- Hide the backdoorIt sits in test files and targets SSH authentication.
- DiscoveryA system shows slightly higher CPU use during SSH connections.
| What XZ Utils Demonstrates About Modern Supply Chain Threats The XZ Utils attack did not exploit a zero-day. It exploited the open source contribution model itself. The attacker became a trusted contributor. The code passed code review. The commits looked legitimate because they were, until the final stage. No perimeter security control, no endpoint detection tool, and no vulnerability scanner would have identified this attack before deployment. The only detection that worked was behavioral: something about the system’s performance was slightly wrong. That anomaly, noticed by a developer who was paying close attention to system behavior, is the only reason the attack became public knowledge. |
Case Study 2: MOVEit (2023/2024): One Zero-Day, Many Organizations
The MOVEit campaign executed by the Cl0p ransomware group began in May 2023 and reached a very large number of organizations. It is among the best-known supply chain breaches because one flaw exposed so many downstream victims. The attack exploited a SQL injection vulnerability in MOVEit Transfer, a managed file transfer platform used by organizations to exchange sensitive data with partners, vendors, and customers.
The structural reason for the scale is what makes MOVEit a supply chain attack rather than a conventional breach: MOVEit sits at the intersection of multiple organizational networks by design. It exists specifically to exchange data between organizations. A single vulnerability in MOVEit granted Cl0p access to every organization that used the platform to exchange data, with the breach propagating downstream to any organization that received files from a compromised MOVEit installation.
The campaign operated through exfiltration only, no encryption, no ransomware deployment. Cl0p stole data and threatened public release. This meant that backup strategies and incident response playbooks designed around encryption-based ransomware were irrelevant. The data was already gone before most organizations were aware of the vulnerability.
| The MFT Problem Is Structural Managed file transfer platforms are a recurring target. MFT platforms are specifically designed to sit at the boundary between organizations, which means a single vulnerability in an MFT product grants access to every organization in its network simultaneously. The attacker gets multiplicative returns on a single investment. The downstream victims in MOVEit, organizations that received files from a compromised installation, had no vulnerability in their own systems. They were breached because they trusted a partner who trusted MOVEit. That chain of trust, which is precisely what makes file transfer workflows function, is what made the breach propagate. |
Case Study 3: PowerSchool: One Stolen Login, One Missing MFA
The PowerSchool breach is the clearest example of how supply chain attacks do not require sophisticated technical exploits. PowerSchool provides student information systems to school districts across North America. An attacker used stolen credentials to access PowerSchool’s customer support portal, a tool designed to allow support staff to access customer data.
The portal lacked multi-factor authentication. The stolen credentials were sufficient for full access. From that single support portal login, the attacker was able to access data on students and teachers across a very large number of school districts. Not one of those districts had a vulnerability in its own systems. Every one of them trusted PowerSchool with their data, and that trust was the attack surface.
The breach is also notable for what it demonstrates about the downstream impact of vendor incidents. School districts are not security organizations. They cannot audit PowerSchool’s internal security controls. They have no visibility into whether the vendor’s support portals have MFA enabled. They trusted a vendor that failed them, and the students and teachers in their systems paid the cost.
| Question | XZ Utils | MOVEit | PowerSchool |
|---|---|---|---|
| Entry point | Trust built as an open source contributor | SQL injection in a file transfer product | Stolen credentials on a support portal |
| Needed a vulnerability | No, it relied on trust and patience | Yes, a SQL injection flaw | No, the portal lacked multi-factor authentication |
Why Can Traditional Security Controls Not Stop Supply Chain Attacks?
The failure of conventional security controls against supply chain attacks is not a question of implementation quality. Organizations with mature security programs, strong perimeter controls, and comprehensive endpoint detection have been breached through their supply chains. The failure is structural: the controls are designed to detect and block activity that is unauthorized, but supply chain attacks enter through authorized channels.
| Security Control | What It Is Designed to Stop | Why It Fails Against Supply Chain Attacks |
| Firewall and network perimeter | Unauthorized inbound connections, known malicious IPs, unexpected outbound traffic | Supply chain attacks use authorized vendor connections, legitimate update channels, and pre-approved remote access. The traffic is expected and permitted. |
| Endpoint detection and response (EDR) | Malware signatures, suspicious process behavior, known attack patterns | XZ Utils carried malicious code inside a trusted library. MOVEit exploited a legitimate web application. PowerSchool used valid credentials. None of these generate EDR alerts. |
| Vulnerability scanning | Known CVEs in the organization’s own systems and applications | The vulnerability in MOVEit was in the vendor’s product, not the organization’s. The backdoor in XZ Utils is now tracked as CVE-2024-3094, but it was planted deliberately and was not a known flaw. Vendor systems are not in scope for most vulnerability scans. |
| Penetration testing | Weaknesses in the organization’s own infrastructure and applications | Penetration tests assess what the organization controls. They do not assess vendor build pipelines, open source dependencies, or MSP security posture. |
| Security questionnaires and audits | Documented vendor security practices at a point in time | The XZ Utils backdoor was inserted after any reasonable audit would have assessed the project as trustworthy. PowerSchool’s questionnaire responses presumably did not include ‘our support portal lacks MFA.’ |
| SIEM and log correlation | Known attack patterns and anomalies in the organization’s own log sources | Vendor-side events, open source repository compromises, and support portal breaches do not generate logs in the customer’s SIEM. The attack is invisible until it manifests inside the customer environment. |
How Big Is the Supply Chain Attack Problem in 2025 and 2026?
The supply chain attack surface is expanding faster than organizational monitoring programs are designed to track. Three structural forces are driving the acceleration.
The Open Source Ecosystem Has Become an Attack Surface at Scale
Modern software is not primarily written by the organizations that deploy it. It is assembled from open source components, and those components have their own dependencies. The typical enterprise application has hundreds of direct and transitive dependencies. Recent npm cases in our incident library include the Keyv maintainer account takeover and the Nx Console compromise, and MITRE describes CanisterWorm as using stolen npm tokens to publish itself across packages.
Attackers have recognized this and publish malicious packages to public registries such as npm. In September 2025, CISA described the Shai-Hulud worm as self-replicating: it spread across npm by authenticating as compromised developers, injecting code into other packages and publishing compromised versions. CISA reported that more than 500 packages were affected.
The Vendor Support Portal Is the New Attack Surface
PowerSchool was not an isolated incident. The vendor support portal pattern, in which an attacker uses stolen credentials to access a platform that was designed to give vendor staff visibility into customer environments, has become a recurring attack vector. These portals exist precisely because vendors need access to customer systems to provide support. That necessity creates an access point that sits outside the customer’s control and is frequently less well-secured than the customer’s own environment.
The attacker does not need to breach the customer directly. They need to breach the vendor’s support infrastructure, which is typically smaller, less well-resourced, and less scrutinized than the customer’s production environment.
AI Coding Tools Add a New Package Risk
AI coding assistants add a further risk, often called slopsquatting: attackers register package names that assistants are known to suggest or invent, then wait for developers to install the malicious package. ENISA’s Threat Landscape 2025 notes that cybercriminals have intensified their efforts to abuse critical dependency points, for example in the digital supply chain.
What Actually Works: Building a Defense for the Supply Chain Era
Defending against supply chain attacks requires accepting that the perimeter model is insufficient and rebuilding the security program around a different assumption: that the most significant threats will enter through trusted relationships, and that detecting them requires visibility into those relationships from the outside, not just controls at the boundary.
Continuous External Monitoring of Your Vendor Ecosystem
- Monitor the external attack surface of your critical vendors, not just your own; if a vendor’s internet-facing infrastructure is compromised, that exposure will appear externally before it manifests in your environment
- Track vendor credential exposure in dark web markets and infostealer logs; a vendor’s credentials appearing in a breach dump is a signal that their support portal or administrative systems may be accessible to attackers
- Set alert thresholds for your most critical vendors so that any change in their external security posture, new exposed services, expired certificates, or newly discovered vulnerabilities, triggers an immediate review
Software Supply Chain Visibility
- Maintain a Software Bill of Materials (SBOM) for your critical applications so that when a malicious package is identified in a registry, you can determine within minutes whether you are affected
- Pin dependency versions in production environments and review changes to pinned versions through a formal approval process; automatically accepting the latest version of any package is the software equivalent of unlocked perimeter access
- Monitor package registries for newly published versions of your critical dependencies, especially in the hours immediately following publication when malicious versions are most likely to go undetected
Structural Changes to Third-Party Risk Management
- Replace annual questionnaire cycles with continuous monitoring; the XZ Utils backdoor was inserted between any reasonable audit cycle, and PowerSchool’s MFA gap was not captured by its customers’ vendor assessments
- Map your fourth-party dependencies: the vendors your vendors depend on. The MOVEit breach affected organizations that had no direct relationship with MOVEit but received files from organizations that did
- Build contractual requirements for vendor breach notification timelines into all critical vendor contracts; the gap between a vendor discovering a breach and informing customers is where the most damage accumulates
How Brandefense Addresses Supply Chain Risk
| Capability | How It Addresses Supply Chain Attack Risk |
| External Attack Surface Management for vendors | Continuously discovers and monitors the external security posture of your critical vendors, identifying exposed services, expired certificates, and newly discovered vulnerabilities before they become incident triggers |
| Dark web credential monitoring for vendor accounts | Tracks vendor employee and service account credentials appearing in infostealer logs and breach dumps, surfacing indicators that a vendor’s internal systems may be accessible to attackers |
| Ransomware and threat actor targeting intelligence | Monitors threat actor activity for campaigns targeting your vendors’ sectors and technologies, providing early warning of supply chain-focused attack campaigns before they activate |
| Vendor breach and leak site monitoring | Tracks ransomware leak sites and dark web forums for data associated with your vendors, providing early detection of vendor incidents that may have downstream consequences for your organization |
| Shadow IT and asset discovery | Identifies unauthorized vendor relationships and SaaS services in use across your organization that represent unmonitored supply chain risk |
| Continuous 24/7 monitoring | Provides the real-time detection cadence that quarterly questionnaires and annual audits structurally cannot match |
| RELATED READING Third-Party Risk: How Your Supplier’s Vulnerability Becomes Your Breach: brandefense.io/blog/third-party-risk-management-vendor-breach-cascade/ : the operational risk mechanics behind supply chain compromise Why Vendor Security Questionnaires Do Not Work: brandefense.io/blog/why-vendor-security-questionnaires-dont-work/ : why point-in-time assessments cannot detect supply chain attacks in progress |
