28.2: Liability Landscape for Software Supply Chains¶

Disclaimer: This section provides general educational information about legal liability concepts. It does not constitute legal advice. Organizations should consult qualified legal counsel for guidance on liability exposure and risk management strategies.

For decades, software has occupied a privileged position in liability law. While manufacturers of physical products face strict liability for defects that cause harm, software vendors have largely escaped similar accountability through carefully crafted warranty disclaimers and the characterization of software as a licensed service rather than a sold product. The resulting legal landscape has allowed software to be distributed "as-is," with users bearing the risk of defects—including security vulnerabilities that may cause significant harm.

This framework is fundamentally shifting. The EU Cyber Resilience Act explicitly imposes manufacturer liability for software security failures. U.S. policy documents increasingly call for liability reform. Courts are beginning to consider whether traditional software disclaimers remain appropriate given software's role in critical infrastructure and daily life. For organizations across the software supply chain, understanding this evolving landscape—and preparing for increased liability exposure—has become a strategic imperative.

Traditional Software Disclaimer Framework¶

The foundation of software liability protection rests on warranty disclaimers that have become ubiquitous in software licensing. Virtually every software license includes language like:

"THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT."

This "as-is" disclaimer attempts to shift all risk of software defects—including security vulnerabilities—to the user. The legal theory underlying these disclaimers treats software as fundamentally different from physical products:

Software is licensed, not sold, arguably exempting it from product liability doctrines
Software complexity makes perfection impossible, justifying acceptance of defects
Users can inspect software (especially open source) and choose whether to accept risks
Rapid software evolution makes fixed-point warranties impractical

Warranty disclaimer effectiveness varies by jurisdiction and context:

Consumer vs. commercial contexts: Consumer protection laws may invalidate disclaimers against individual users while permitting them in business-to-business transactions
Unconscionability: Courts may refuse to enforce disclaimers in contracts of adhesion where users had no meaningful negotiating power
Public policy: Disclaimers against liability for gross negligence or intentional misconduct are often unenforceable
Jurisdictional variation: Different jurisdictions apply different standards for disclaimer validity

Limitation of liability clauses further restrict potential exposure:

"IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY... ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE."

These clauses attempt to cap or eliminate damages even when warranty disclaimers fail. Their enforceability follows similar patterns—more likely enforceable between commercial parties, less likely against consumers, and rarely enforceable for intentional or grossly negligent conduct.

For open source software specifically, the combination of no payment, explicit disclaimers, and user access to source code has historically provided strong protection against liability claims. The absence of a commercial transaction weakens arguments for implied warranties. User ability to inspect code arguably transfers responsibility for identifying defects.

Product Liability Extension to Software¶

Product liability law traditionally applies to tangible goods that cause physical harm. Manufacturers face strict liability—liability without fault—for defective products that injure users, regardless of due care exercised during manufacture. The question of whether software constitutes a "product" subject to these doctrines remains contested but increasingly answered affirmatively.

Arguments for software as product:

Software embedded in physical products (vehicles, medical devices, appliances) is inseparable from the product itself
Standalone software functions like any other tool users purchase and rely upon
Modern software distribution (downloaded executables) resembles product sale more than service provision
User expectations treat software as a product regardless of licensing terminology

Arguments against software as product:

Software licenses explicitly characterize transactions as licenses, not sales
Software's intangible nature distinguishes it from traditional products
The service elements of software (updates, support) blur product/service lines
Applying strict liability to software would fundamentally alter the industry

Courts have reached varying conclusions. In cases involving software embedded in medical devices, automotive systems, and other physical products, courts have applied product liability principles. For standalone software, particularly enterprise software in commercial transactions, courts have more frequently applied contract law rather than product liability.

The Restatement (Third) of Torts: Products Liability defines "product" as "tangible personal property," and most courts applying this definition have held that software alone does not qualify. However, courts have applied product liability principles when software is embedded in physical products that cause harm, and the question remains contested in evolving case law. The trend—particularly in cases involving physical harm from software failures—moves toward treating software as a product subject to defect liability.

Implications for supply chain:

If software is subject to product liability: - Manufacturing defects: Bugs introduced during development could create liability - Design defects: Architectural flaws enabling exploitation could be actionable - Failure to warn: Inadequate disclosure of security limitations could trigger liability - Strict liability: Liability could attach regardless of due care exercised

This would fundamentally change supply chain risk allocation. Every component provider in the chain could face potential strict liability for defects in their components.

Negligence Theories for Supply Chain Failures¶

Even without product liability's strict liability standard, organizations may face liability under negligence theories when supply chain failures cause harm. Negligence requires proving:

Duty of care: Defendant owed a duty to the plaintiff
Breach: Defendant failed to meet the applicable standard of care
Causation: Breach caused plaintiff's harm
Damages: Plaintiff suffered actual harm

Establishing duty of care in software supply chains raises complex questions. Does a software vendor owe a duty to users? To downstream consumers of products incorporating its software? To third parties harmed by security failures?

Courts have increasingly found that software vendors owe duties to reasonably foreseeable users of their software. The scope of this duty—and whether it extends through supply chains—remains an evolving area of law.

Standard of care for software security has no universally defined legal standard, but several sources inform expectations:

Industry practices and prevailing standards
Regulatory requirements (FDA guidance, financial regulations)
Voluntary frameworks (NIST SSDF, OWASP SCVS) adopted by industry
Representations made by the vendor about security

As frameworks like NIST SSDF and OWASP SCVS gain adoption, they increasingly define what "reasonable care" means for software development. Failure to follow widely-adopted security practices may support negligence claims.

Dependency selection creates specific duty of care questions. When you incorporate a third-party component into your software:

Did you exercise reasonable care in selecting the component?
Did you evaluate the component's security before adoption?
Did you monitor the component for vulnerabilities?
Did you respond appropriately when vulnerabilities emerged?

Organizations that blindly incorporate dependencies without security evaluation may face negligence claims when those dependencies enable breaches. Conversely, documented security evaluation processes may demonstrate reasonable care even when vulnerabilities occur.

Breach through inaction presents another liability vector. When a vulnerability becomes known:

How quickly must you patch?
Must you notify users of vulnerability and patch availability?
What responsibility exists for users who cannot easily update?

Failure to respond appropriately to known vulnerabilities—particularly after public disclosure—may constitute breach of duty of care even if the original vulnerability was not negligently introduced.

Contract vs. Tort Liability¶

Supply chain liability may arise under either contract law (breach of agreement) or tort law (wrongful conduct causing harm). The distinction significantly affects available claims, defenses, and damages.

Contract liability arises when software fails to meet commitments made in the agreement:

Express warranties about security characteristics
Implied warranties of merchantability or fitness
Service level agreements for response times
Indemnification obligations for third-party claims

Contract liability is generally limited to parties to the contract. A user cannot typically sue a component vendor directly unless privity of contract exists. Damages are limited to those foreseeable at contract formation, and limitation of liability clauses may cap recovery.

Contract liability advantages for claimants: - Clear relationship and expectations - No need to prove duty of care - Specific commitments may be easier to prove

Contract liability advantages for defendants: - Ability to disclaim warranties and limit liability - Damages limited to contract terms - Generally no punitive damages

Tort liability arises from wrongful conduct causing harm regardless of contractual relationship:

Negligence in software development or maintenance
Fraudulent misrepresentation about security
Product liability for defective software

Tort liability can extend to parties without contractual privity—a user harmed by a component vendor's negligence might sue the vendor directly. Damages may include consequential damages and, in cases of willful misconduct, punitive damages.

Tort liability advantages for claimants: - No contract required - Broader damages available - May reach parties throughout supply chain

Tort liability advantages for defendants: - Plaintiff must prove duty and breach - Various defenses available (assumption of risk, comparative fault) - Higher burden of proof for plaintiff

The economic loss rule traditionally limits tort recovery for purely economic harm (as opposed to personal injury or property damage) to contract claims. Software security failures often cause economic harm—breach costs, business interruption, remediation expenses—without physical injury. This rule may limit tort claims to situations involving physical harm, leaving contract as the primary vehicle for pure economic losses.

However, exceptions exist, and the rule's application to cybersecurity harms remains unsettled. Some jurisdictions recognize exceptions for negligent misrepresentation or products unreasonably dangerous for their intended use.

The Evolving Legal Landscape¶

The traditional "as-is" software framework faces mounting pressure from multiple directions.

EU Cyber Resilience Act Liability Provisions

The EU Cyber Resilience Act fundamentally shifts liability for software security failures within the EU. Key liability provisions include:

Manufacturer liability: Manufacturers are liable for damage caused by products failing to meet essential cybersecurity requirements
No-fault liability: Liability attaches based on non-compliance, not fault
Consumer rights: Consumers harmed by non-compliant products have direct claims against manufacturers
Damages: Covers material and non-material damage from security failures

The CRA explicitly provides that liability cannot be contracted away—warranty disclaimers will not defeat claims based on CRA non-compliance. This represents a categorical rejection of the "as-is" framework for software sold in the EU market.

The EU Product Liability Directive revision (2024) complements the CRA by explicitly including software as a "product" subject to product liability. Together, these measures create a comprehensive liability regime for software security failures.

U.S. Policy Direction

While the U.S. lacks legislation equivalent to the CRA, policy documents signal shifting expectations:

The 2023 National Cybersecurity Strategy explicitly calls for liability reform:

"We must begin to shift liability onto those entities that fail to take reasonable precautions to secure their software while recognizing that even the most advanced software security programs cannot prevent all vulnerabilities."

The strategy identifies goals including: - Shifting liability to entities best positioned to reduce risk - Establishing safe harbors for entities following best practices - Adapting liability frameworks to support the software ecosystem while incentivizing security

The CISA Secure by Design initiative establishes voluntary principles that may inform future liability standards. Adoption of these principles may demonstrate reasonable care; rejection may support negligence claims.

Federal agencies increasingly condition procurement on security attestations. False attestations create potential False Claims Act liability—a significant expansion of liability exposure for federal contractors.

Judicial Evolution

Courts are gradually recognizing that traditional software liability frameworks may be inadequate:

Class actions involving IoT device security failures have been filed, testing whether product liability principles apply, though courts have yet to establish clear precedent holding manufacturers strictly liable for cybersecurity failures
Data breach litigation increasingly survives motions to dismiss
Class actions for software security failures have resulted in significant settlements

While no watershed Supreme Court decision has definitively extended product liability to software, the trend in lower courts moves toward increased accountability.

Insurance Market Signals

Cyber insurance markets provide indirect evidence of liability expectations. Insurers increasingly:

Require security controls as conditions of coverage
Exclude coverage for known vulnerabilities left unpatched
Impose retroactive premium increases following claims
Decline coverage for organizations with inadequate security practices

Insurance underwriting standards may inform judicial determinations of reasonable care—practices insurers require for coverage may define industry standards.

Liability Risk Management¶

Organizations should prepare for expanded liability exposure through comprehensive risk management.

Contractual risk allocation:

Negotiate appropriate indemnification in supplier agreements
Ensure insurance coverage addresses supply chain failures
Carefully review and update limitation of liability provisions
Allocate risk to parties best positioned to mitigate it

Operational practices:

Implement and document security practices aligned with recognized frameworks
Conduct and document component security evaluation before adoption
Establish and follow vulnerability response procedures
Maintain records demonstrating due care

Disclosure and communication:

Avoid misrepresentations about security capabilities
Provide accurate security disclosures in documentation
Communicate promptly about vulnerabilities and remediation
Document communications for potential litigation

Insurance considerations:

Review cyber insurance coverage for supply chain scenarios
Understand coverage exclusions and conditions
Maintain compliance with policy requirements
Consider coverage adequacy as liability exposure expands

Recommendations¶

We recommend organizations prepare for the evolving liability landscape:

Review warranty disclaimers and limitations with counsel to understand current protection and likely enforceability
Assess EU CRA exposure if products are sold in the European market, preparing for liability framework changes
Document security practices demonstrating reasonable care in development and dependency management
Implement vulnerability response procedures that demonstrate appropriate urgency when issues arise
Evaluate supplier agreements for indemnification, insurance requirements, and liability allocation
Review insurance coverage for adequacy given evolving liability exposure
Monitor legal developments as courts, legislatures, and regulators reshape software liability
Engage legal counsel proactively to develop liability management strategies before claims arise

The era of consequence-free software distribution is ending. Organizations that prepare for increased accountability—through better security practices and appropriate legal protections—will navigate this transition more successfully than those caught unprepared.