In December 2020, security researchers discovered that attackers had compromised a routine software update distributed by SolarWinds, a company whose network management tools were used by thousands of organizations worldwide. In the weeks that followed, it became clear that the attackers — widely attributed to Russian intelligence — had used that compromised update to gain access to the networks of US government agencies, major corporations, and critical infrastructure providers. The SolarWinds attack was not a breach of a single target. It was a breach of a trusted distribution channel, and that distinction changes almost everything about how you think about cyber risk and cyber insurance.
About a year later, in December 2021, security researchers disclosed a critical vulnerability in Log4j, a widely used open-source logging library embedded in an enormous range of software products. The vulnerability was so pervasive that organizations around the world scrambled to identify every system that used Log4j — a task that turned out to be far harder than expected, because Log4j was buried inside commercial software, cloud services, and custom applications, often without the organizations’ knowledge. The Log4j vulnerability remains one of the most consequential software security events in history.
Together, these events exposed a fundamental weakness in how businesses manage technology risk: the assumption that security is primarily about what happens inside your own organization. In reality, every piece of software your business uses, every vendor whose systems connect to yours, and every open-source library embedded in your applications represents a potential entry point for an attacker. This guide explains what supply chain attacks are, how they affect your cyber insurance coverage, and what steps you can take to protect your business.
What Is a Supply Chain Attack?
A supply chain attack is a cyberattack that targets a business not directly, but through a vendor, service provider, or software product that the business trusts and uses. Instead of attacking your organization head-on — which may be difficult if you have strong security controls — the attacker compromises something that already has authorized access to your systems.
The term supply chain comes from the physical world concept of a production chain: raw materials flow through multiple hands before becoming a finished product, and a contamination at any point in that chain affects the final product. In the software world, your technology supply chain includes the operating systems and commercial software your business runs, the cloud services and SaaS applications your employees use, the third-party vendors who have remote access to your systems for support or integration purposes, and the open-source libraries that are built into the software your developers write or that your vendors use.
Supply chain attacks are particularly dangerous because they exploit trust. When a software vendor sends an update, your systems are configured to accept and install it automatically. When a managed service provider logs into your network to provide support, your firewall allows that connection. When your accounting software runs, your computer executes its code without question. A supply chain attack weaponizes that trust relationship, giving the attacker access that your defenses are specifically designed not to block.
How SolarWinds-Type Attacks Work
The SolarWinds attack is the defining example of what security professionals call a software supply chain attack. The attackers compromised SolarWinds’s own development and build environment — the internal systems that SolarWinds used to write, compile, and package its software. By inserting malicious code into SolarWinds’s build process, the attackers ensured that when SolarWinds released a routine update to its Orion network monitoring platform, that update contained malware.
Because the malicious update was digitally signed by SolarWinds and distributed through SolarWinds’s normal update channels, it was indistinguishable from a legitimate update. Organizations that installed it — following standard security practice of keeping software current — inadvertently installed malware that gave the attackers persistent, stealthy access to their networks. The malware was specifically designed to avoid detection: it dormant for weeks before activating, it mimicked normal network traffic patterns, and it used legitimate cloud services for command and control communications.
The implications for cyber insurance are significant. In a traditional cyber incident, the affected organization can point to a specific intrusion event — a phishing email that was opened, a vulnerability that was exploited, a set of credentials that were stolen. In the SolarWinds scenario, the affected organizations did everything right by their own policies. They kept their software updated, they used trusted vendors, and they followed standard security guidance. The breach happened not because of anything those organizations did wrong, but because of what happened upstream in a vendor’s development environment.
Whether this distinction matters for insurance coverage depends on specific policy language, but it raises serious questions about how coverage applies when the insured organization cannot be said to have failed any of the security standards required by the policy. Some insurers have argued that coverage exclusions for failures by third parties limit recovery in supply chain scenarios. Others have paid claims without dispute. The outcome is highly fact-specific and depends heavily on how the policy is written.
How Log4j-Type Vulnerabilities Create Widespread Exposure
The Log4j event illustrates a different dimension of supply chain risk: the open-source software ecosystem. Unlike the SolarWinds attack, which involved an active adversary deliberately inserting malware, the Log4j vulnerability was an ordinary software flaw — a coding error in an open-source library that had been in use for years and had been reviewed by countless developers without the flaw being identified.
Log4j is a logging library written in Java. It is used to record events and errors in software applications, which is an unglamorous but essential function that nearly every significant Java application requires. Because it is useful, free, and widely available, Log4j became one of the most commonly used components in Java software across the world — embedded in commercial products, enterprise applications, cloud services, and custom software alike.
When a critical vulnerability was discovered in Log4j in December 2021, the response revealed how poorly most organizations understood their own software supply chains. Identifying whether you were affected by the Log4j vulnerability required knowing not just what software you ran, but what components that software was built on — information that was often unavailable because software vendors had not disclosed their component dependencies. The US Cybersecurity and Infrastructure Security Agency estimated that hundreds of millions of devices worldwide were potentially affected.
For businesses that were actually exploited through the Log4j vulnerability, coverage under a cyber policy was generally available if the exploitation resulted in a qualifying incident — a data breach, ransomware, or network disruption. However, the costs of the response — identifying whether your systems were affected, patching them where possible, and implementing workarounds where patching was not immediately available — were substantial even for organizations that were never actually exploited. Whether those pre-breach response costs are covered under a cyber policy depends on how the policy defines a covered cyber event.
Cyber Insurance Coverage for Supply Chain Incidents
Whether a supply chain attack is covered by your cyber insurance policy depends on several factors: how the policy defines a covered cyber event, whether there are relevant exclusions for third-party failures, and whether the loss you suffered — data breach, business interruption, extortion, or response costs — is a type of loss the policy covers.
Most cyber policies cover losses resulting from unauthorized access to or use of your computer systems, regardless of how that unauthorized access occurred. If an attacker gains access to your systems through a compromised software update and then steals data or deploys ransomware, that should be a covered event under a standard cyber policy — the mechanism of entry does not typically matter as long as the resulting harm is a covered type of loss.
The more difficult coverage question arises when the harm results not from an attacker actively exploiting the supply chain compromise, but from the disruption caused by the compromise itself or from the costs of responding to it. Business interruption coverage, for example, typically requires a covered cause — usually an attack on your own systems or a failure of your own network. If your operations are disrupted because your software vendor’s systems were attacked and the vendor’s services went offline, your business interruption claim may be subject to dependent business interruption analysis, which is discussed further below.
Some cyber policies include specific exclusions for losses caused by failure of third-party service providers, failure of software products not operated by the insured, or losses that originate outside the insured’s own technology environment. These exclusions can significantly limit coverage for supply chain incidents and should be reviewed carefully. If your policy contains broad third-party exclusion language, you should discuss with your broker whether this is standard in the current market and whether better terms are available.
The Systemic Risk Problem
One of the most significant concerns raised by events like SolarWinds and Log4j is the concept of systemic risk in cyber insurance. Traditional insurance works best when losses are independent — when one policyholder suffers a loss, it is unrelated to whether another policyholder suffers a loss. This independence allows insurers to diversify risk across a large pool of policyholders and pay claims from premium income without facing catastrophic losses.
Cyber insurance faces a fundamental challenge in this regard: cyber incidents, especially supply chain attacks and software vulnerabilities, can affect thousands of businesses simultaneously. When a single compromised update reaches tens of thousands of SolarWinds customers, or when a single Log4j vulnerability affects hundreds of millions of devices, the losses are not independent. Insurers who have written cyber policies for many of the affected organizations face claims from all of them at once — the very scenario that insurance is least well-equipped to handle.
This systemic risk concern has led some insurers to introduce or tighten policy exclusions designed to limit their exposure in widespread events. You may see exclusions for losses arising from infrastructure failures affecting a broad population of insureds, for losses arising from vulnerabilities in widely used software components, or for losses that exceed a specified threshold of affected businesses. These exclusions are controversial and some have been challenged in litigation, but they reflect a real structural concern about whether private insurance can bear the full cost of truly catastrophic, correlated cyber events.
As a practical matter, the existence of systemic risk exclusions means that your coverage for a major supply chain event — precisely the scenario you most need coverage for — may be less certain than your coverage for a targeted, company-specific attack. This is an important reason to work with experienced legal counsel when reviewing your policy and to understand what coverage limitations apply to widespread events.
Protecting Yourself Contractually After a Supply Chain Event
When your business suffers harm because a software vendor or service provider was compromised, your first instinct may be to look to that vendor for recovery. Whether that recovery is available depends almost entirely on the contract between you and the vendor, because most vendors disclaim liability through their standard terms of service in ways that would be startling to most business owners.
Standard software license agreements typically include broad disclaimers of warranty, limitations of liability capped at the amount you paid for the software or services, and exclusions for indirect, consequential, and incidental damages. If you paid ten thousand dollars per year for a software product and that product caused a million-dollar breach, the vendor’s contract likely limits your recovery to ten thousand dollars — if you can recover anything at all.
For significant technology relationships, you should negotiate vendor contracts that include meaningful security representations and warranties, incident notification obligations, and liability provisions appropriate to the risk. This is particularly important for vendors who have significant access to your systems or data, who provide services critical to your operations, or whose software or systems are deeply integrated into your technology environment. These negotiations can be difficult because large software vendors have significant market power, but mid-market and smaller vendors are often willing to negotiate reasonable security terms.
Your contracts should require vendors to notify you promptly if they experience a security incident that may affect your systems or data, to cooperate in forensic investigation if your business is affected, and to maintain their own cyber insurance with reasonable coverage limits. Vendor notification provisions are particularly important in supply chain scenarios because the vendor often knows about the compromise before you do, and timely notification is essential to limiting the damage.
Security Practices That Reduce Supply Chain Risk
From both a risk management and an insurance perspective, there are established security practices that meaningfully reduce supply chain risk. Implementing these practices not only reduces the likelihood of harm from a supply chain event but also demonstrates to insurers that your organization has a mature approach to third-party risk, which can improve your insurance terms.
Software bill of materials, or SBOM, is an emerging practice that has received significant attention since the Log4j event. An SBOM is essentially a complete inventory of every software component in an application, including open-source libraries and their dependencies. The US government’s 2021 executive order on cybersecurity called for SBOM adoption in software sold to the federal government, and private sector adoption is growing. Maintaining SBOMs for software you develop and requesting them from vendors allows you to quickly identify whether your environment contains a vulnerable component when a new vulnerability is disclosed.
Third-party risk management programs provide a structured approach to evaluating and monitoring the security of vendors and service providers before you engage them and on an ongoing basis. This typically includes security questionnaires or independent assessments for significant vendors, contractual requirements for security standards and audit rights, and monitoring programs that track vendors’ security posture over time. The depth and formality of these programs should be proportional to the risk the vendor relationship creates.
Network segmentation limits the damage that can result from a supply chain compromise. If a vendor’s product or access is limited to a specific segment of your network rather than having access to your entire environment, the blast radius of a compromise is significantly reduced. Principle of least privilege — giving vendors and software products only the access they actually need to perform their function — is a foundational security practice that applies with particular force to third-party relationships.
Vendor Notification Obligations After a Supply Chain Event
When you learn that a software vendor you use has been compromised, you face immediate legal and practical questions about your own notification obligations. Whether you have a legal obligation to notify affected individuals, regulators, or business partners depends on whether the vendor’s compromise resulted in a breach of your own data.
US data breach notification laws — which exist at the state level in all fifty states and at the federal level for certain industries — are generally triggered by unauthorized access to or acquisition of personal information held by your business. If a vendor compromise resulted in attackers accessing personal information that your business entrusted to the vendor, that likely constitutes a reportable breach for which you, as the data owner, bear notification responsibility. The fact that the breach originated at the vendor rather than within your own organization does not eliminate your notification obligation.
This creates a practical challenge in supply chain events: determining the scope of the breach before your notification deadlines expire. Many state breach notification laws require notification within sixty, forty-five, or even thirty days of discovery. If your vendor was compromised but cannot tell you with certainty what data was accessed, you may face notification deadlines before you have complete information. Your legal counsel should be involved immediately when you learn of a potential supply chain compromise to advise on your notification obligations and timelines.
What to Do Immediately When Your Software Vendor Is Compromised
When you receive notification that a software vendor has been compromised, or when you learn through news reports or security alerts that a product you use has been affected by a supply chain attack or vulnerability, speed is essential. The steps you take in the first hours and days will significantly affect both the severity of the harm and the strength of your insurance coverage position.
The first priority is containment and assessment. Work with your IT team or security provider to identify all instances of the affected software or vendor access in your environment, to assess whether the compromise could have affected your systems, and to implement any immediate mitigations recommended by the vendor or security researchers. If the vendor has issued guidance — patches, workarounds, or indicators of compromise to search for — follow that guidance promptly.
The second priority is to notify your cyber insurer. Most cyber policies require prompt notification of potential claims, and a supply chain event that has affected a software product you use is a circumstance that should be reported even if you are not yet certain whether your organization was actually compromised. Failing to notify promptly can jeopardize your coverage for costs incurred during the response. Your insurer may also have access to resources — forensic investigators, legal counsel, public relations support — that can assist in your response.
The third priority is to engage legal counsel to assess your notification obligations, review your vendor contracts for any relevant obligations or rights, and advise on how to preserve your legal position in the event of subsequent litigation or regulatory inquiry. Supply chain events are legally complex, and the decisions made in the immediate aftermath — what you communicate to customers, regulators, and the public, and how — have lasting consequences.
The fourth priority is documentation. Preserve all records related to the event: communications from the vendor, internal assessments, security scans, and response activities. This documentation is essential for your insurance claim, for any regulatory inquiry, and for any litigation that may follow. Create a contemporaneous record of when you learned about the compromise, what you knew at each point in time, and what actions you took in response.
Supply chain attacks are among the most challenging cyber incidents to respond to because they involve factors outside your control and may create harm that is difficult to trace and quantify. Building strong vendor relationships, maintaining robust contractual protections, and working with experienced legal and insurance advisors before an incident occurs are the most effective ways to position your business to weather these events.