What Is a Software Supply Chain Attack? How Vendors Become Entry Points

You can patch every laptop, train every employee and still get breached through software you trusted. That is what makes supply chain attacks so unsettling. The attacker doesn’t break into your network directly. They compromise a vendor, an update server or a code library you already rely on, and your own systems invite them in.

These attacks hit large enterprises and government agencies, but small and mid-size businesses are often caught too, usually through a managed service provider, a widely used app or an open-source package buried inside a product they bought.

This guide explains how software supply chain attacks work, the main entry points, real examples and a practical way to vet the vendors and dependencies you rely on.

What a software supply chain attack is

Your software supply chain is everything that goes into the tools you run: commercial applications, cloud services, open-source libraries, update mechanisms, build systems and the IT providers who manage it all. A supply chain attack compromises one of those links so the attacker can reach everyone downstream.

The key difference from a typical attack is trust. The malicious code arrives signed, through an official update or a normal package install. Security tools and people are more likely to let it through because it comes from a source they already approved.

CISA and NIST describe the problem in their joint resource Defending Against Software Supply Chain Attacks, released in April 2021. They recommend treating software purchases as part of a formal risk management program, not a one-time buying decision.

How vendors and dependencies become entry points

Most supply chain attacks use 1 of these routes:

• Hijacked software updates. Attackers break into a vendor’s build or update system and slip malicious code into a legitimate release.
• Compromised open-source packages. Attackers take over a maintainer’s account, publish a malicious version of a popular package or trick a project into accepting backdoored code.
• Typosquatting and lookalike packages. A package named almost like a popular one waits for developers to make a typo.
• Managed service providers (MSPs) and remote tools. An attacker who compromises an IT provider’s remote management platform can push malware to every client at once.
• Stolen developer credentials and tokens. Access to a code repository or build pipeline lets attackers change what gets shipped.
• Third-party scripts and SaaS integrations. A compromised analytics script, plugin or connected app can read data or redirect users.

Real-world examples

SolarWinds Orion (2020). Attackers inserted malicious code into updates for SolarWinds’ Orion IT monitoring software released between March and June 2020. CISA issued Emergency Directive 21-01 in December 2020 ordering federal civilian agencies to disconnect or power down affected Orion products. SolarWinds told the SEC that fewer than 18,000 customers may have installed the affected updates.

Kaseya VSA (2021). In July 2021, a ransomware group exploited Kaseya’s VSA remote management software, which many managed service providers use. CISA and the FBI issued guidance for MSPs and their customers, because a single compromised tool reached many downstream small businesses.

XZ Utils (2024). In March 2024, malicious code was found in versions 5.6.0 and 5.6.1 of XZ Utils, a compression library included in many Linux distributions (CISA alert, CVE-2024-3094). CISA later described it as a multi-year effort by an attacker to gain a maintainer’s trust before inserting a backdoor. It was caught before it spread widely.

npm “Shai-Hulud” worm (2025). In September 2025, CISA warned of a self-spreading compromise in the npm JavaScript registry. The malware stole developer credentials, then used them to publish infected versions of other packages, compromising more than 500 packages.

Key takeaway: In a supply chain attack, your trust in a vendor is the vulnerability. You can’t eliminate that trust, so manage it: know who your suppliers are, limit what they can reach and watch for anything unusual.

Types of supply chain risk at a glance

How to vet vendors and dependencies

You don’t need a full third-party risk team. A consistent, proportionate process covers most of the risk.

Step 1: Build an inventory

List every vendor and tool with access to your systems or data: software, SaaS apps, IT providers, payment processors, plugins and integrations. Note what each can reach. For companies that build software, this includes open-source dependencies.

Step 2: Rank by risk

Not every vendor needs the same scrutiny. Focus on suppliers that have admin access, touch sensitive data or run code inside your network. An MSP with remote access to every computer matters far more than a design tool.

Step 3: Ask the right questions

For high-risk vendors, ask:

• Do you have an independent security report, such as a SOC 2 Type II or ISO 27001 certification?
• How do you secure your build and update process?
• Do you require MFA for all staff with access to customer systems?
• Can you provide a software bill of materials (SBOM) listing the components in your product?
• How and how fast will you notify us of a security incident?
• How do you handle vulnerabilities, and do you publish advisories?

CISA and NIST specifically recommend requiring a software component inventory, such as an SBOM, from vendors.

Step 4: Put it in the contract

Add security requirements, breach notification timelines, right-to-audit or report-sharing clauses and data return or deletion terms at the end of the relationship.

Step 5: Limit access

Give each vendor only the access it needs, using zero trust principles. Use separate accounts for vendors, require MFA and turn off access when it isn’t in use.

Step 6: Monitor and review

Watch for unusual behavior from vendor tools, such as unexpected network connections or new admin accounts. Review high-risk vendors at least once a year.

Extra steps for teams that build software

If you develop software or run websites, your own code depends on hundreds of packages:

• Generate SBOMs for your applications so you can answer “are we affected?” within hours.
• Scan dependencies automatically for known vulnerabilities and malicious packages.
• Pin versions and review updates rather than pulling the latest release automatically into production.
• Protect developer accounts with MFA and short-lived tokens, and rotate secrets after any suspected exposure.
• Follow a secure development framework such as NIST’s Secure Software Development Framework (SP 800-218). Our guide to DevSecOps covers how to build these checks into your pipeline.

For broader governance, NIST’s SP 800-161 Revision 1, updated in November 2024, is the main US guidance on cybersecurity supply chain risk management. It maps well to the supply chain category in the NIST Cybersecurity Framework.

Where to start this quarter

1. List your top 10 vendors by access, starting with your MSP, identity provider, email, accounting and payment tools.
2. Confirm MFA is required on every vendor account that can reach your systems.
3. Request security reports from your 3 highest-risk vendors.
4. Remove unused integrations and connected apps from Microsoft 365, Google Workspace and your CRM.
5. Check your backups are isolated, so a compromised vendor tool can’t delete them. See our guide to ransomware protection.
6. Add vendor compromise as a scenario in your incident response plan, including who to call and how to cut off vendor access fast.

Conclusion

Supply chain attacks work because modern businesses run on trust: in vendors, in updates and in code written by strangers. That trust is necessary, but it shouldn’t be blind. Know who your suppliers are, give them only the access they need, ask for evidence of their security and plan for the day one of them is compromised. Those habits won’t stop every attack, but they shrink the damage when one gets through.

Sources

• CISA and NIST: Defending Against Software Supply Chain Attacks — attack vectors, risk management and SBOM recommendations (April 2021)
• NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices — supply chain risk management guidance (updated November 2024)
• CISA: Reported Supply Chain Compromise Affecting XZ Utils, CVE-2024-3094 — affected versions and response
• CISA: Widespread Supply Chain Compromise Impacting npm Ecosystem — Shai-Hulud worm, more than 500 packages
• CISA and FBI: Guidance for MSPs and Customers Affected by the Kaseya VSA Attack — MSP supply chain incident and mitigations