Several modalities: vendor itself compromised (firmware with backdoor), build-process compromise (the vendor's CI/CD), open-source library injection (typosquatting, dependency confusion, maintainer takeover), SaaS service compromise, or attacks on outsourced IT providers.
What a supply chain attack is
A supply chain attack is a technique where the attacker compromises a vendor, a software library, a development tool or an external service trusted by the victim, and uses that trust relationship to reach the target organization. Rather than attacking the victim directly (who may have good defenses), the attacker compromises an upstream link that the victim already authorizes and that distributes updates, code or services into the corporate environment. SolarWinds (2020), 3CX (2023) and the XZ Utils incident (2024) are contemporary examples.
Why it matters
Supply chain attacks multiply scope: a single compromised vendor can become an entry point into thousands of organizations at once. They are extraordinarily hard to detect because the malicious component arrives signed and verified by the legitimate vendor, passes regular controls without issue, and executes authorized actions. The EU NIS2 directive explicitly makes organizations accountable for the risk of their technology supply chain, which turns supply chain risk management into a legal duty, not just good practice. For entities under DORA, diligence over critical technology providers is an inspection control.
Key points
SBOM (Software Bill of Materials) is the key technical tool to manage the risk: if you know exactly which components are in your software, you can cross-reference against emerging vulnerabilities and react in minutes.
Effective defense combines prior diligence (vendor assessment before contracting), post-contract control (monitoring the behavior of signed software), segmentation (least privilege for the vendor's agent in your environment) and tested response for when the next public case lands.
Not a risk to eliminate at 100%: a risk to manage. The question for leadership is not 'can we be attacked through the supply chain?' but 'how fast can we detect and respond when it happens?'.
Example: SolarWinds Orion (2020)
Attackers (attributed to a nation-state APT group) compromised the build process of the Orion monitoring software from SolarWinds. They injected malicious code into a legitimate update which SolarWinds signed and distributed to its 18,000 enterprise and government customers. The update passed antivirus, monitoring and policy controls because it came signed by a trusted vendor. Once executed on victim networks, the malware (Sunburst) opened C2 channels and enabled selective access to a shortlist of high-value targets. Detection came nine months after the first infection, when FireEye (a victim) discovered anomalous internal activity. It is the modern textbook case of supply chain attack and what triggered much of the subsequent legislation (US Executive Order 14028, EU NIS2 reinforcement).
Common mistakes
- Assuming an ISO 27001-certified vendor is risk-free. Certification assesses controls, it does not immunize against compromise. Continuous diligence doesn't stop when the contract is signed.
- Not having an up-to-date inventory of technology providers with access to your environment. When the next public case lands and the question is 'do we have this product / this library?', without an inventory the answer takes days.
- Confusing supply chain risk with software-only cybersecurity. The supply chain also includes IT service providers, MSPs, consultancies with environment access, integrators — anyone with authorized access is a potential vector.
- Not exercising the response. A public case like SolarWinds or XZ Utils is a forced tabletop opportunity. Practicing before the incident reduces reaction time when one hits you.
Related terms
Related services
This concept may relate to services such as:
Frequently asked questions
Does NIS2 require auditing all my technology providers?
NIS2 requires supply-chain risk-management policies proportional to organization size and criticality. It does not require auditing all providers; it does require identifying them, classifying them by risk and applying proportional controls: higher scrutiny when the provider has more access or handles more sensitive data.
How do I detect a supply chain attack in my environment?
Detection rarely happens at the moment of entry (the component arrives signed and verified). What can be detected is the post-entry behavior: software that opens unexpected connections, agents that escalate privileges, processes that touch resources they shouldn't. That is why EDR, NDR and threat hunting are critical tools, together with rigorous segmentation that limits what a compromised agent can do.
How does SBOM relate to supply chain attacks?
SBOM is the technical tool that lets you know exactly which components and dependencies live in each software product. When a case lands (critical CVE, compromised library, malicious package in a public repository), a well-maintained SBOM lets you answer in minutes whether you are affected. Without SBOM, the answer takes days or weeks.