The SolarWinds attack reached approximately 18,000 organizations before anyone knew it was happening, and the mechanism was simple: attackers compromised a software update at the source and let customers install it themselves. Since then, supply chain attacks have repeated with 3CX, MOVEit, and XZ Utils, each time exploiting the same trusted relationship between vendor and customer. For most organizations, this is risk that lives entirely outside their perimeter and has never been formally tested.
That was 2020. Since then, the pattern has repeated with 3CX, MOVEit, XZ Utils, and dozens of smaller incidents that did not make headlines. Supply chain attacks are not a new category of threat. They are a maturing one, and the maturity is on the attacker’s side.
For security leaders, the implication is uncomfortable: a significant portion of your organization’s risk lives outside your perimeter, inside systems you do not own, control, or directly test.
What Makes Supply Chain Attacks Different
Most security programs are built around a model of defending your environment. You know what your network looks like. You scan your endpoints, patch your servers, monitor your logs. Penetration tests probe your perimeter and your applications. That model addresses a meaningful portion of your risk profile.
It does not address the risk that enters through the front door in a signed software update.
Supply chain attacks exploit a specific asymmetry: organizations extend significant trust to vendors and software providers while often having limited visibility into the security practices behind that trust. When an attacker compromises a vendor, they inherit that trust. They do not need to bypass your defenses. They are already inside the boundary you drew around your environment.
Three categories account for the majority of supply chain incidents:
Software build and distribution compromise. Attackers target the development or distribution pipeline of a software vendor. Malicious code is introduced before the final product is compiled or packaged, which means it passes signature verification and reaches customers through legitimate update channels. SolarWinds and XZ Utils both followed this pattern.
Third-party service provider compromise. Attackers target managed service providers, IT support firms, or other vendors with privileged access into customer environments. The MSP becomes the pivot. This model scales well for attackers because a single compromise yields access to many downstream targets simultaneously.
Open source dependency injection. Malicious packages are introduced into public repositories such as npm, PyPI, or RubyGems, often with names nearly identical to popular legitimate packages. Development teams pull them in without realizing they have introduced a backdoor or credential harvester into their build.
What these vectors share is that the exploit does not happen in your environment. The malicious code or access is established elsewhere, and you receive it as a side effect of a normal, trusted process.
Why Standard Penetration Testing Does Not Cover This
A traditional penetration test is scoped to your environment: your external IP ranges, your internal network segments, your web applications, your employee workstations. That is appropriate and necessary. But it assumes the threat originates outside your organization and needs to get in. Supply chain attacks invert that assumption.
A pentest will not reveal that your endpoint management platform was compromised at the vendor. It will not detect that a development dependency in your CI/CD pipeline includes a data exfiltration routine. It will not identify that your MSP’s technician account, which has local admin rights on 400 of your workstations, was compromised six weeks ago.
This is not a limitation of penetration testing as a discipline. It is a scope problem. Most organizations scope their tests around the boundary they control, which leaves vendor relationships, software dependencies, and privileged third-party access outside the assessment.
Closing that gap requires a different kind of deliberate effort.
What a Serious Third-Party Risk Program Actually Requires
Security teams that take supply chain risk seriously have moved beyond the vendor questionnaire. A questionnaire tells you what a vendor says about their security program. It does not tell you what is actually true, and it definitely does not detect a compromise that occurred after the questionnaire was submitted.
A more defensible approach combines several practices:
Third-party access inventory. You cannot manage risk you have not mapped. Most organizations lack a complete, current picture of which vendors have privileged access to their environment, what that access looks like technically, and whether it is actively monitored. Building and maintaining that inventory is the foundation of everything else.
Least privilege enforcement for vendor accounts. Vendor accounts with broad administrative rights are one of the most common pivots in supply chain incidents. Enforcing least privilege on third-party access, and reviewing it regularly, significantly reduces the blast radius when a vendor is compromised. This is not a novel recommendation. It is underimplemented at most organizations.
Software composition analysis. For organizations with software development functions, understanding the dependency tree of your own products matters. Open source dependencies carry real risk, and that risk is not visible without tooling designed to surface it. Software composition analysis (SCA) tools are now mature enough to integrate into CI/CD pipelines with reasonable effort.
Supplier security assessments. For vendors with privileged access or integration into sensitive systems, questionnaires should be supplemented with more rigorous assessment. This can include reviewing vendor security reports (SOC 2 Type II is a reasonable baseline for software vendors), requiring evidence of their own penetration testing practices, or, for high-criticality vendors, commissioning direct assessments.
Penetration testing that includes third-party access scenarios. When scoping penetration tests, include scenarios that model what happens if a vendor account is compromised. Can an attacker with MSP-level access pivot to your most sensitive systems? What does that lateral movement look like? What does your detection and response capability see? These questions are answerable through your penetration testing program, but only if you build them into the scope.
The Compliance Connection
Several major compliance frameworks have begun to address supply chain risk directly, which means security teams with compliance drivers now have explicit requirements to meet:
CMMC Level 2 includes requirements around protecting Controlled Unclassified Information (CUI) across the supply chain, including managing the security practices of suppliers who handle CUI. Defense contractors pursuing CMMC certification cannot treat vendor risk as out of scope.
NIST SP 800-161, the Cybersecurity Supply Chain Risk Management standard, provides a structured framework for assessing and managing supply chain risk. For organizations using NIST as their security framework baseline, SP 800-161 is increasingly relevant.
SOC 2 auditors have become more attentive to third-party risk as supply chain incidents have increased. Vendor management controls and the evidence behind them receive more scrutiny than they did five years ago.
The practical takeaway: if your organization operates in a regulated sector, or works with organizations that do, supply chain security is moving from a recommended practice toward an auditor expectation.
The Honest Difficulty of the Problem
Supply chain security is genuinely hard in a way that some security problems are not. You cannot fully control your vendor’s security posture. You cannot prevent a nation-state actor from compromising a software provider you depend on. The XZ Utils incident was discovered by a single engineer who noticed unexpected behavior in a library that most organizations had never heard of before it was in the news.
The goal is not to eliminate supply chain risk entirely. The goal is to reduce your exposure, detect compromise more quickly when it does occur, and limit the blast radius when a vendor relationship becomes an attack vector.
That means building visibility into vendor access, enforcing least privilege, scoping your penetration tests to include third-party scenarios, and making supply chain risk a standing agenda item for your security program rather than a topic you revisit after the next major incident.
Organizations that take this seriously are not guaranteed to avoid supply chain attacks. But they are far better positioned to detect them early, contain them effectively, and recover with minimal impact. That is the realistic standard to hold your program to.
—
Thinking through your organization’s exposure to supply chain and third-party risk? StrikeHaven works with security teams to scope penetration testing engagements that include vendor access scenarios, privileged third-party account abuse, and lateral movement modeling. Our credentialed practitioners (OSCP, CREST, CRTO) design engagements around your actual environment rather than generic checklists. Schedule a consultation to discuss what a supply chain-aware security assessment looks like for your organization.