Companies put a lot of effort into keeping attackers out, yet every day they willingly install updates pushed by vendors, let IT service providers manage their servers remotely, and pull hundreds of open-source packages into their own code. Supply chain attacks exploit exactly these trusted channels: the attacker tampers with a product or its delivery mechanism before it reaches the end user, anywhere from development tools, build environments and source code repositories to open-source dependencies, software update channels and hardware shipments[1].

These attacks are hard to stop because the malicious code arrives signed by a legitimate vendor through a normal update process, or logs in through a service provider account that already has administrative rights. This article covers the common types of supply chain attack, four cases documented by official sources, and what companies can do in procurement, contracts, access control and monitoring. It is written for IT managers, procurement staff and anyone responsible for managing outsourced IT.

Four common types of supply chain attack

MITRE ATT&CK divides supply chain compromise into three sub-techniques: compromising software dependencies and development tools, compromising the software supply chain, and compromising the hardware supply chain[1]. Add intrusions through the trust placed in IT service providers, and the common entry points fall into four groups.

Tampered software updates

Attackers break into a software vendor's build environment, plant malicious code in an official release, and let the vendor's own distribution and update channels spread it. Sometimes they distribute it widely and then pick out the victims they actually care about[1]. Because the files carry the vendor's signature, endpoint protection and application allowlists usually let them through.

Poisoned open-source packages and developer tools

Attackers insert malicious code into open-source packages or development and build tools, so every piece of software that depends on them is affected too[1]. Modern software relies heavily on open-source components, and a problem in one widely used low-level package can reach far beyond the people who consciously chose to use it.

Compromised IT service providers and MSPs

Managed service providers (MSPs), system integrators and remote support vendors often hold highly privileged accounts and remote management tools in their customers' environments. In a 2022 joint advisory, cybersecurity authorities from the US, UK, Australia, Canada and New Zealand said they expect malicious actors, including state-sponsored APT groups, to step up their targeting of MSPs in order to exploit the network trust between providers and customers[2].

Hardware and firmware

Hardware, firmware or preinstalled software can be tampered with during manufacturing or shipping[1]. These attacks are rarer and hard for an ordinary company to verify on its own; the main countermeasures are buying through trusted channels, checking firmware sources and signatures, and keeping a complete equipment inventory.

Four cases with official documentation

SolarWinds Orion (2020)

According to CISA's advisory, the activity began no later than March 2020. The attackers inserted a malicious DLL into the SolarWinds Orion software build process and had it signed with SolarWinds' legitimate code-signing certificate; the affected builds were specific versions between 2019.4 HF5 and 2020.2 HF1[3]. The backdoor communicated outward with traffic designed to look like normal SolarWinds traffic, and CISA's April 2021 update attributed the activity to Russia's Foreign Intelligence Service (SVR)[3]. CISA also found that the same actors used other ways in that had nothing to do with SolarWinds, such as password guessing, password spraying and SAML token abuse, so removing Orion was not enough: credentials had to be reset and identity systems reviewed thoroughly[3].

Kaseya VSA (2021)

In July 2021, ransomware attackers exploited a vulnerability in Kaseya's VSA remote management software to hit multiple MSPs and their downstream customers at once[4]. CISA and the FBI advised affected MSPs to enforce MFA across the board and to restrict remote monitoring and management (RMM) communications to known IP addresses or put the administrative interfaces behind a VPN or firewall. For customers, the advice included keeping current backups air-gapped from the organizational network, temporarily returning to a manual patching process that follows vendor guidance, and enforcing MFA and least privilege on administrator accounts for key resources[4].

3CX (2023)

The officially distributed 3CX desktop app for voice and video calls was trojanized and reached users' machines. Mandiant's investigation found that the initial entry point was a tampered installer for X_TRADER, a trading application reportedly discontinued in 2020 but still downloadable from the vendor's website in 2022. From there the attackers moved laterally inside 3CX and eventually compromised both its Windows and macOS build environments[5]. Mandiant said it was the first time it had seen one software supply chain attack lead to another, and attributed the activity to UNC4736, a cluster it suspects has a North Korean nexus[5].

xz-utils (2024)

On 29 March 2024, engineer Andres Freund disclosed on the oss-security mailing list that upstream versions 5.6.0 and 5.6.1 of xz, a compression tool widely used on Linux, had been backdoored in a way that could lead to SSH server compromise. He found it by following up on odd symptoms, including SSH logins using a lot of CPU, on Debian's unstable branch (sid). At the time, the two versions had mostly made it only into pre-release versions of distributions rather than wide deployment[6]. CISA's later analysis described it as a multi-year effort by a malicious actor to gain the trust of the package's maintainer before inserting the backdoor, and argued that the burden of security should not fall on an individual open-source maintainer[7].

What these four cases have in common is that the victims did nothing obviously wrong: they installed updates and used their service providers as normal. The point of defence is therefore not to distrust every vendor, but to add verification, restrictions and monitoring on top of trust.

Vendor risk management starts with procurement and contracts

NIST SP 800-161 Rev. 1 is the main reference for cybersecurity supply chain risk management (C-SCRM). It calls for building supply chain risk into risk management at every level of the organization, rather than checking once at the point of purchase[8]. Most companies can start with the following:

  • Tier vendors by access: vendors that can log in to your environment remotely, hold your data or supply core software are high risk and should be reviewed regularly
  • Spell it out in the contract: incident notification deadlines and methods, division of responsibilities, whether subcontracting is allowed, audit rights, and how accounts are disabled and data returned when the contract ends. The five-country advisory also recommends contracts that require the MSP to implement baseline security measures, provide security event monitoring and agree how incidents will be notified[2]
  • Ask for evidence, not just promises: for example third-party certification, a vulnerability remediation process, and a product security incident response (PSIRT) contact

In Taiwan, Article 10 of the Cyber Security Management Act, as amended in 2025, requires government agencies and specified non-government agencies that outsource the building or operation of information systems or information services to choose suitable contractors, require them to run effective cybersecurity management and supervise it. The contractor's procedures and environment must have sound security controls or be certified by an impartial third party, and the two sides must sign a written contract setting out rights, obligations and liability for breach[9]. Even if your company is not covered by the Act, these requirements make a practical baseline; for who is covered and what they must do, see Taiwan's Cyber Security Management Act.

SBOM: know what you are running

CISA describes a software bill of materials (SBOM) as "a nested inventory, a list of ingredients that make up software components"[10]. When an event like the xz-utils backdoor is disclosed, the first question is "do we have an affected version, and on which systems?" With SBOMs and a complete software inventory you can check directly; without them you are left logging in to machines one by one.

In practice:

  • Ask vendors for an SBOM at procurement, or at least a commitment to say whether their products are affected when a major vulnerability is announced
  • Generate SBOMs automatically in the build pipeline for software you develop in-house, and keep them with each release
  • Link SBOMs to your asset inventory so that new vulnerabilities in security advisories can be matched quickly

Restrict vendor access and watch the update channels

  • Least privilege: keep MSP accounts out of internal administrator groups and limit them to the systems the MSP manages[2]; disable them when not in use
  • MFA and connection limits: enforce MFA on every vendor account; allow remote management tools to communicate only with known IP addresses, and put administrative interfaces behind a VPN or firewall[4]
  • Staged updates: roll out updates to important software on a test environment or a small group of hosts first, then deploy widely after observation. This is not a reason to stop patching; fixes still need to land within a reasonable time (see patch prioritization)
  • Monitor the network behaviour of privileged software: allow monitoring, backup and remote management software to reach only the external destinations it needs, and investigate any new outbound connection; the SolarWinds backdoor relied on outbound connections to talk to the attackers[3]
  • Keep records of vendor activity: require service providers to give you visibility into what they do in your environment, and store key logs centrally[2]
  • Be ready to search quickly: when a vendor publishes indicators of compromise, you should be able to search your own environment for them fast; see using IOCs

Action checklist

  1. List every vendor and MSP that can connect remotely to your environment, including the tools, accounts, scope of access and the internal owner for each.
  2. Check whether vendor accounts sit in domain admin or other highly privileged groups; replace them with dedicated accounts limited to the systems each vendor manages, and enable MFA.
  3. Disable vendor accounts and remote management tools for contracts that have ended or that have not been used for a long time.
  4. Add contract terms for high-risk vendors: incident notification deadlines, limits on subcontracting, access to activity records, and how data and accounts are handled when the contract ends.
  5. Build or update your software inventory, and start producing SBOMs for core systems and in-house software.
  6. Restrict outbound connections from monitoring, backup and remote management servers to the destinations they need.
  7. Move important software to staged updates, and follow vendor security notices and this site's supply chain category.
  8. Run a tabletop exercise: assume a core vendor has been breached, and check how quickly you can identify affected systems, cut off the vendor's access and notify the relevant parties.