Supply Chain Attacks: How They Happen, Why They Succeed, and How to Stop Them

Supply chain attacks have increased over the years, and as per the Cost of a Data Breach Report 2026, the average cost of a single breach has now reached $4.99 million, a 12% increase over last year. Yet most enterprise security programs still treat supply chain risk as a variation of traditional vulnerability management. It isn’t. A supply chain attack doesn’t target your perimeter. It targets the trust relationships that hold your software development ecosystem together: open-source dependencies, third-party vendors, build tools, and package registries. When an attacker compromises one of those trusted upstream components, they bypass your controls entirely and gain access to your environment with the same legitimacy as a routine software update.

The scale of the problem is staggering. The NPM registry alone holds more than 2.1 million packages, and the September 2025 NPM supply chain attack compromised at least 27 packages through a phishing campaign that targeted maintainers of widely used JavaScript libraries. Attackers registered a lookalike domain, sent convincing 2FA update emails, and within hours had injected malware into packages downloaded billions of times. The attack wasn’t sophisticated in its initial access. It was sophisticated in its understanding of how modern software is assembled and how trust flows through dependency chains.

This article breaks down how supply chain attacks happen, why they keep succeeding despite existing defenses, and what enterprise teams can do to detect and prevent them. We’ll cover the evolution from SolarWinds to the recent NPM attacks, why CVSS-only prioritization leaves you exposed, and how an independent control plane with SBOM management, automated prioritization, and agentic remediation can compress your mean time to remediate from months to hours.

What Is a Software Supply Chain Attack?

A software supply chain attack occurs when an attacker compromises a trusted third-party component, vendor, or tool in your development pipeline to gain access to your environment. Instead of attacking your organization directly, they target the software you rely on. That could be an open-source library in your application, the build server that compiles your code, the package registry that distributes your dependencies, or a commercial vendor whose software you’ve installed. The attack succeeds because the compromised component carries implicit trust. It’s already inside your environment, and your security controls were designed to stop threats at the perimeter, not from within the software supply chain itself.

What makes supply chain attacks particularly dangerous is their cascading impact. When attackers compromised SolarWinds’ build environment in 2020, the malicious update reached approximately 18,000 customer organizations, including federal agencies and Fortune 500 enterprises. One compromised build server became a distribution channel for malware at a scale that no direct attack could match.

How Did We Get Here? From SolarWinds to NPM

The evolution of supply chain attacks over the past five years tells a clear story: attackers are getting more targeted, more patient, and more attuned to how software development actually works.

SolarWinds (2020) was the wake-up call. Attackers compromised the build environment of the Orion network monitoring platform and injected a backdoor into digitally signed, legitimate updates. The malware reached 18,000 organizations through normal update channels, and the attack went undetected for months because the compromised software carried SolarWinds’ own digital signature.

Log4j (2021) showed a different but equally devastating pattern. A critical vulnerability in a ubiquitous Java logging library triggered an internet-wide scramble to identify and patch the exposure. Many organizations were impacted, not because attackers compromised a maintainer, but because a single flawed dependency had been embedded in thousands of products across every industry. The vulnerability exposed how deeply interconnected software dependencies are and how quickly a single weak link can cascade.

MOVEit (2023) demonstrated how a single vulnerability in managed file transfer software could cascade across thousands of organizations. The Cl0p ransomware group exploited an SQL injection vulnerability in Progress Software’s MOVEit platform, ultimately affecting over 2,600 organizations and compromising data from approximately 85 to 90 million individuals (Industry Data). The attack showed that you don’t need to compromise a build pipeline to execute a devastating supply chain attack. A single vulnerable upstream component is enough.

XZ Utils (2024) demonstrated a new level of sophistication. An attacker using the identity “Jia Tan” spent two years building trust with the maintainers of a widely used compression library before introducing obfuscated malicious code into test files. The backdoor was discovered by chance before it reached major Linux distributions, but the multi-year social engineering effort revealed how patient and resourceful supply chain attackers have become.

The September 2025 NPM supply chain attack brought the threat into the package registry itself. Attackers registered a lookalike domain (npmjs.help), sent phishing emails to NPM maintainers claiming urgent 2FA updates were required, and compromised at least 27 packages within hours. The injected malware targeted cryptocurrency transactions across multiple blockchains and spread through dependency chains to billions of weekly downloads. The attack exploited the same trust model that makes package registries useful: maintainers publish updates, and downstream developers pull them automatically, often through automated dependency update tools that merged the malicious versions without scrutiny.

Most recently, the August 2026 Shai-Hulud resurgence showed the same playbook works at ecosystem scale. After the attacker hijacked a single maintainer’s GitHub account, the worm poisoned keyv, flat-cache, file-entry-cache, and cacheable-request, then self-propagated to 440+ packages across 2,200+ versions within an hour, reaching an estimated 2 billion-plus monthly installs. Attackers continue to target maintainers through social engineering, exploit the automated trust of package distribution systems (the malicious releases even carried valid Sigstore provenance), and use the cascading nature of dependencies to amplify their reach.

The pattern is clear. Each attack builds on the lessons of the last. Attackers have moved from opportunistic exploitation to multi-year, nation-state-level operations designed to compromise the foundational components of modern software.

Why Do Supply Chain Attacks Succeed Despite Existing Defenses?

If you have SCA tools, SAST scanners, and a vulnerability management process, you might assume your organization is protected. Most aren’t. Supply chain attacks succeed because they exploit three structural weaknesses in how most enterprise security programs operate: tool fragmentation, the CVE-only blind spot, and the absence of business context in prioritization.

Tool fragmentation is the first problem. The average enterprise uses dozens of security tools across its development lifecycle. SCA tools scan dependencies, SAST tools scan code, container scanners check images, and cloud security tools monitor infrastructure. Each produces its own findings, in its own format, with its own severity scoring. Nothing connects them. When a supply chain attack drops a new zero-day into your environment, you can’t ask one system whether you’re affected. You have to check each tool individually, and by the time you’ve correlated the results manually, the attacker has already moved.

The CVE-only blind spot is the second problem. Most vulnerability management programs prioritize based on CVSS scores, which measure the theoretical severity of a vulnerability in isolation. CVSS doesn’t tell you whether a vulnerability is actually exploitable in your environment, whether the affected component is reachable in your code, or whether threat actors are actively exploiting it. Only 2 to 7 percent of published CVEs are ever seen exploited in the wild (EPSS / FIRST), which means most teams spend 93 to 98 percent of their remediation effort on vulnerabilities that will never be attacked. When a supply chain attack drops a zero-day, the CVSS score might tell you it’s critical, but it won’t tell you whether it matters.

The Container Security Blind Spot

Container security adds another layer of risk that standard SCA tools often miss. Containers rely on public base images that may contain outdated or vulnerable libraries, and if container security isn’t integrated into your supply chain strategy, those hidden vulnerabilities can be deployed directly into production environments. A vulnerable base image might carry dozens of known CVEs, but unless your tooling correlates container image findings with your broader vulnerability data, you won’t see the full picture.

This is where the lack of unified visibility becomes a strategic problem, not just an operational one. If your SCA tool says a dependency is clean, but your container scanner says the base image is vulnerable, and nothing connects the two findings, you have a gap. Supply chain attackers exploit gaps. They don’t need to find a new zero-day. They just need to find the component you forgot to scan.

How Can Enterprise Teams Detect Supply Chain Vulnerabilities?

Detection starts with knowing what’s in your environment. That means maintaining a Software Bill of Materials (SBOM) for every application and continuously monitoring it against new advisories. For a broader foundation, see our comprehensive guide to software supply chain security. But generating an SBOM isn’t enough. Many organizations produce SBOMs for compliance and then file them away. The value of an SBOM isn’t the document itself. It’s the ability to query it when a new vulnerability drops and immediately answer the question every CISO asks during a zero-day: are we affected?

Effective detection requires three things working together. First, unified visibility across all your security tools and SBOMs, so you have a single source of truth for every component in your environment. Second, continuous monitoring against threat intelligence feeds, so you know when a new advisory matches something in your SBOM. Third, business context, so you can distinguish between a critical vulnerability in a component that runs in production and a critical vulnerability in a component that sits in a test environment and is never deployed.

Leveraging EPSS, CISA KEV, and Threat Intelligence for Prioritization

When a new supply chain vulnerability is disclosed, you need to cut through the noise fast. The Exploit Prediction Scoring System (EPSS) from FIRST helps you assess the likelihood that a given vulnerability will be exploited in the wild within the next 30 days. The CISA Known Exploited Vulnerabilities (KEV) catalog tells you which vulnerabilities are already being actively exploited by threat actors.

But EPSS and CISA KEV alone aren’t enough. To prioritize effectively, you need to layer in four additional data points:

• Threat intelligence: Is there a public exploit available? Are threat actors discussing this vulnerability on dark web forums? Has it appeared in any known attack campaigns?
• Business impact: What application does the affected component run in? Is it customer-facing? Does it process sensitive data? What’s the financial and operational cost if it goes down?
• Reachability: Is the vulnerable code path actually reachable in your application, or is the dependency present but never called?
• Exploitability: What authentication, network access, or user interaction does exploitation require?

Prioritization that combines EPSS, CISA KEV, threat intelligence, business impact, reachability, and exploitability turns a backlog of thousands of vulnerabilities into a short list of the ones that actually matter. That’s how you move from finding vulnerabilities to fixing the ones that pose real risk.

What Are the Best Practices to Stop a Supply Chain Attack?

Stopping supply chain attacks isn’t about buying another scanner. It’s about changing how your organization handles the full lifecycle of software components, from ingestion through remediation. Frameworks like NIST SP 800-161 (Cyber Supply Chain Risk Management) and the OWASP Software Component Verification Standard provide useful reference architectures, but the operational reality comes down to execution. The following practices shift the focus from finding vulnerabilities to efficiently fixing them.

1. Unify Your Security Data

You need an independent control plane that aggregates data from all your SCA tools, SBOMs, container scanners, and CI/CD security tools. Eliminating tool silos gives you a single source of truth for your entire software development ecosystem. When a new advisory drops, you query one system, not fifteen. When you need to know whether a component is in production, the answer is already there.

Unification also means normalizing findings. Different scanners use different severity scales, naming conventions, and vulnerability identifiers. Without normalization, the same vulnerability might appear as three separate findings from three different tools, each with a different severity. That creates confusion and duplicate work. An independent control plane normalizes all findings into a unified model, so every vulnerability appears once, with all relevant context attached.

2. Prioritize with Full Context

Prioritization is where most supply chain security programs break down. CVSS-only prioritization treats every critical vulnerability as equally urgent, which is why security teams end up with backlogs of thousands of “critical” findings and no way to triage them. The fix is to prioritize based on real-world context: EPSS scores, CISA KEV listings, threat intelligence, business impact, reachability, and exploitability. When you prioritize with full context, the 3 percent of vulnerabilities that represent 80 percent of real business risk surface to the top, and the noise drops away.

3. Automate Remediation Workflows

Detection without remediation is just expensive reporting. The goal is to compress the time between “we know we’re affected” and “the fix is deployed.” That means automating the answer to “are we affected?” when new advisories drop, routing fixes to the right developers with full remediation context, and tracking MTTR as a measurable, improvable metric.

Most enterprise security teams measure MTTR in months. The industry average for vulnerability remediation is 240 days. That’s not a technology problem. It’s a process problem. Manual triage, spreadsheet-based tracking, and handoffs between security and development teams that lose context along the way are what stretch remediation timelines. Automation compresses that timeline by eliminating the manual steps: automatically identifying affected components, enriching findings with remediation guidance, routing tickets to the right developers with all the context they need, and tracking the fix to completion.

How ArmorCode Secures the Software Supply Chain

ArmorCode approaches supply chain security through three core capabilities, each addressing a specific failure point in how most organizations manage their software development ecosystem today.

Tracking Software Supply Chain

You can’t protect what you can’t see. ArmorCode’s software supply chain security module gives you unified visibility into all third-party, open-source, and in-house components across your CI/CD pipeline, classified by dependency level (direct or transitive) and linked back to the repositories where they originate and where they’re declared. The Agentic Control Plane ingests SBOMs from across the organization and correlates component data with findings from 400+ security tool integrations, normalizing everything into a single view.

Visibility alone isn’t enough, so ArmorCode enriches every component with the context that actually determines risk: maintenance signals like contributor activity and commit recency, license terms, popularity metrics, and trust signals from OpenSSF Scorecard, including CI checks, branch protection, and contributor diversity. When a new advisory drops, or when legal flags a restrictive license, you don’t need to run a scan or dig through a spreadsheet. You already know.

The Context Risk Graph sits behind this visibility, connecting findings, assets, supply chain data, and threat intelligence in a single data model. It’s the same graph that powers every other capability on the platform, which means supply chain risk isn’t siloed from application security risk, infrastructure risk, or compliance posture. Everything connects.

SBOM Management and Vulnerability Disclosure

Generating an SBOM is table stakes. The question is what you do with it. ArmorCode consolidates fragmented SBOMs from across your tools into composite, application-level SBOMs, then continuously monitors them against new vulnerability disclosures and enriches component data with deprecation status and OpenSSF Scorecard ratings. When a new CVE is disclosed, ArmorCode automatically checks your SBOMs for affected components and surfaces the findings with full context: which applications use the component, whether it’s in production, and what the business impact looks like.

This turns the SBOM from a compliance document into an operational tool. ArmorCode also generates VEX data alongside your SBOMs, so you can produce formal, audit-ready vulnerability disclosures for frameworks like FedRAMP, SOX, ISO 27001, and the Cyber Resilience Act without stitching the documentation together by hand. Instead of asking “do we have an SBOM?” after an attack, you’re asking “are we affected?” before the attack reaches you. And when a supply chain attack does break, the Zero-Day Exposure Hunting Agent, one of ArmorCode’s Anya Agents, assesses organizational impact by pulling threat intel, identifying affected components, checking supply chain exposure, correlating existing findings, and producing a full impact report in minutes rather than days.

End-of-Life Component Tracking

End-of-life components are one of the most overlooked supply chain risks. When a library or package is no longer maintained, it stops receiving security patches. Every new vulnerability discovered in that component becomes a permanent exposure. ArmorCode tracks end-of-life components across your environment, flagging dependencies that have been deprecated or abandoned so you can replace them before they become a liability.

This capability matters because most SCA tools flag known vulnerabilities but don’t track the lifecycle status of the components themselves. A package with no known CVEs but no active maintainer is a ticking time bomb, and it’s a risk that regimes like SOC 2, PCI-DSS, HIPAA, and the FDA’s SBOM guidance treat as a named finding independent of vulnerability count. ArmorCode surfaces that risk before it becomes a finding, and before it becomes a compliance gap.

Anya Agents: AI Workers for Supply Chain Security

Anya Agents are ArmorCode’s purpose-built, role-aware AI workers. Each agent is scoped to a single, high-value security workflow and grounded in the Context Risk Graph, not in public LLM guesswork. For supply chain security, two agents matter most:

The Zero-Day Exposure Hunting Agent activates when a new supply chain attack breaks. It pulls threat intelligence, identifies affected components across your environment, checks supply chain exposure, correlates existing findings, and produces a full impact report. Instead of spending days manually asking “are we affected?”, you get an answer in minutes.

The Remediation Agent generates code-aware remediation guidance for supply chain findings. It uses available metadata and external sources to produce specific, actionable fix recommendations that developers can implement without additional research. The guidance includes the affected component, the fix version, and the context needed to understand why the fix matters.

ArmorCode customers have used these capabilities to accelerate MTTR from an average of 240 days to just hours (ArmorCode). The platform processes 400+ billion findings annually across customer environments (ArmorCode), giving every agent and every workflow the scale of data needed to produce meaningful prioritization.

Conclusion

Supply chain attacks aren’t a new threat category. They’re the natural consequence of how modern software is built: assembled from thousands of third-party components, distributed through automated pipelines, and trusted by default. The attacks will keep coming. The NPM supply chain attack in September 2025 showed that a simple phishing campaign can compromise maintainers and cascade through billions of downloads in hours. The XZ Utils backdoor showed that attackers are willing to spend years building the trust needed to slip malicious code into foundational libraries.

What changes the equation isn’t another scanner. It’s an independent control plane that unifies your security data, prioritizes vulnerabilities based on real-world context rather than theoretical severity, and automates remediation to the point where your team can respond to a supply chain attack in hours, not months. ArmorCode’s Agentic Control Plane, with its 400+ integrations, 400+ billion findings processed annually, and Anya Agents built for zero-day exposure hunting and remediation, gives enterprise teams the infrastructure to make that shift.

Stop hunting for vulnerabilities and start fixing them. See how ArmorCode’s Agentic Control Plane accelerates remediation from 240 days to just hours.

Request a demo at armorcode.com/request-a-demo.

Frequently Asked Questions

Q: What is the difference between a supply chain attack and a direct cyberattack?

A: A direct attack targets your organization’s perimeter or infrastructure. A supply chain attack compromises a trusted third-party vendor or open-source component you rely on, using their access to breach your systems. The key difference is trust: the compromised component is already inside your environment, so it bypasses perimeter controls entirely.

Q: How does container security impact the software supply chain?

A: Containers often rely on public base images that may contain outdated or vulnerable libraries. If container security isn’t integrated into your supply chain strategy, these hidden vulnerabilities can be deployed directly into production environments. A vulnerable base image might carry dozens of known CVEs, and unless your tooling correlates container findings with your broader vulnerability data, you won’t see the full exposure.

Q: Why is an SBOM important for stopping supply chain attacks?

A: A Software Bill of Materials (SBOM) provides a comprehensive inventory of all components in your software. Without it, you cannot quickly answer “are we affected?” when a new zero-day vulnerability like Log4j is disclosed. But an SBOM is only useful if it’s actively managed and continuously monitored against new advisories, not just generated for compliance and filed away.

Q: How can organizations reduce MTTR for supply chain vulnerabilities?

A: Organizations can reduce Mean Time to Remediate (MTTR) by moving away from manual triage. Using an independent control plane to automate workflows, route tickets to the right developers, and prioritize based on EPSS, CISA KEV, threat intelligence, and business impact can accelerate MTTR from 240 days to just hours. The key is combining automated detection with context-rich remediation guidance so developers can fix vulnerabilities without additional research.

Key Takeaways

• Supply chain attacks doubled in 2024 (Sonatype), and the average breach now costs $4.6 million (IBM Security). Attackers target the trust relationships in your development pipeline, not your perimeter.
• Traditional defenses fail because they treat every vulnerability as equal. Only 2 to 7 percent of published CVEs are ever exploited in the wild, yet most teams spend their time on the wrong 97 percent (EPSS / FIRST).
• Effective prevention requires unifying your security data, prioritizing with threat intelligence and business context, and automating remediation workflows so you can answer “are we affected?” in hours, not weeks.
• ArmorCode’s Agentic Control Plane ingests SBOMs across 400+ integrations, enriches component data, and uses Anya Agents to cut MTTR from 240 days to just hours.