S4x24 Interview With Stewart Baker: Legal Issues on Software Liability & SEC Case Against Solarwinds

S4x24 Interview With Stewart Baker: Legal Issues on Software Liability & SEC Case Against Solarwinds

Speakers: Stewart Baker

Conference: S4

YouTube: https://www.youtube.com/watch?v=L6DUCqIQ4qA

Overview

This talk features Stewart Baker, a distinguished legal expert with extensive experience in Washington law, discussing the intricate and evolving landscape of software liability. The conversation, while initially framed to cover both software liability and the SEC case against SolarWinds, focuses exclusively on the former in the provided transcript. Baker delves into the historical context of product liability, contrasting its established principles with the unique challenges posed by software and cybersecurity incidents. He highlights the critical tension between the desire to hold software producers accountable for defects and the potential for such liability to stifle technological innovation.

The discussion is particularly relevant for security professionals, legal practitioners, and technology companies grappling with the increasing frequency and impact of software-related vulnerabilities and breaches. Baker provides a lawyer's perspective on why applying traditional product liability frameworks to the digital realm is not straightforward, examining factors such as the nature of damages, the role of End-User License Agreements (EULAs), and the complexities of multi-component software systems, including those incorporating open-source elements. His insights are crucial for understanding the current legal environment and anticipating future developments in software accountability.

The talk underscores the importance of a nuanced understanding of legal principles for those in the cybersecurity field, cautioning against overly simplistic interpretations of liability. By exploring the economic justifications for product liability and the judiciary's historical approach to innovation, Baker offers a comprehensive foundation for appreciating the legal hurdles and potential pathways for establishing greater accountability in the software industry.

Background

▶ Watch: Introduction to software liability and SolarWinds SEC case (0:00)

The concept of product liability is not new; it has been a cornerstone of legal systems for many decades, arguably over a century. Traditionally, product liability emerged from common law and litigation, where judges observed accidents and injuries caused by defective products. They would then determine that manufacturers had failed to meet expected safety standards, leading to compensation for the injured party. This judicial activism, particularly prominent since the 1940s, was often underpinned by a compelling economic theory: responsibility for losses should be placed on the party best positioned to prevent those losses. In the context of physical products, manufacturers are uniquely positioned to design, produce, and test their goods, making them the most logical bearers of this responsibility. This principle often leads to strict liability, where fault does not necessarily need to be proven, only that the product was defective and caused harm.

A landmark case illustrating this principle is MacPherson v. Buick Motor Co. (1916). In this case, a car manufacturer was held liable for injuries caused by a defective wooden wheel, even though Buick did not manufacture the wheel itself but purchased it from another supplier. The court ruled that as the final seller of the complete product, Buick had a duty to ensure its safety. This precedent established that manufacturers cannot simply deflect blame to component suppliers, setting a broad standard for accountability in the supply chain of physical goods.

However, applying these established principles to software introduces significant complexities. Software, unlike a physical product, can be intangible, constantly updated, and its "defects" (vulnerabilities) may not manifest in immediate, physical harm but rather in data breaches, system downtime, or financial losses. Furthermore, the ecosystem of software development is often distributed, relying heavily on third-party components, including a "boatload of open-source" code, which can make it challenging to pinpoint ultimate responsibility. The legal system has historically been cautious about imposing liability that could "destroy innovation," recognizing the transformative benefits of technology. This judicial caution, coupled with the unique characteristics of software, has slowed the emergence of a clear framework for software liability.

Key Findings

▶ Watch: Why software liability is difficult to apply, unlike physical products (2:00)

Stewart Baker's analysis reveals several key findings regarding the application of traditional product liability to the domain of software and cybersecurity:

1. Unclear Application to Software: The established principles of product liability, while robust for physical goods, are "less clear" when applied to software. This ambiguity stems from fundamental differences in the nature of software, the types of damages incurred, and the judicial approach to technological innovation.
2. Nature of Damages: In traditional product liability, damages are often tangible and directly affect individuals (e.g., physical injury). In software liability, however, damages frequently manifest as financial losses, operational disruptions, or data compromises, primarily impacting other companies rather than individuals. This often leads to a "slightly less sympathetic hearing" from courts and makes it harder to precisely quantify the exact cost of the harm.
3. Judicial Caution for Innovation: Courts have historically been "enthusiastic about software" and technology, viewing it as beneficial for the country. Consequently, there is a strong inclination to avoid imposing liability standards that could "destroy innovation" or unduly burden the burgeoning tech sector. This cautious approach acts as a significant barrier to expanding software liability.
4. Limited Efficacy of Terms of Service (TOS) and Licenses: While software users routinely agree to Terms of Service and End-User License Agreements (EULAs) that typically disclaim liability for problems, these contracts are not an absolute shield. Courts, particularly in the context of consumer products, have historically "waved that stuff away" when they deem terms "unacceptable to ordinary people" or "unfair," unilaterally imposing liability. While some courts have enforced such clauses in software contexts, there's no guarantee they will continue to do so, especially if public or regulatory pressure for fairness increases.
5. Challenges in Company-to-Company Litigation: When one company (e.g., Clorox) suffers harm due to a software flaw and considers suing another company (the software provider), several practical hurdles emerge. First, many large companies are themselves frequently "on the receiving end of exactly that kind of lawsuit," creating a conflict of interest that makes them hesitant to expand product liability law. Second, the software provider may be significantly smaller than the aggrieved company, meaning they "won't be able to carry your losses," making the lawsuit an insufficient remedy. For instance, the Clorox case from last year, which involved a cyber incident leading to a 26% loss of manufacturing capacity and an estimated cost of $47 million, exemplifies a quantifiable corporate harm. Yet, even with clear damages, the decision to pursue litigation against a software vendor is complex due to these factors.
6. Open Source Complexity: Modern software often incorporates a "boatload of open source" components that the primary vendor did not write. This distributed development model makes it exceedingly difficult for a vendor (e.g., Siemens, Emerson, Schneider Electric selling a system) to be "absolutely sure" that every component is free of problems, further complicating the attribution of liability.

These findings highlight that while the desire for accountability in software is growing, the legal and practical mechanisms for achieving it are still in their nascent stages, marked by significant legal precedent, economic considerations, and the unique characteristics of software itself.

Technical Deep Dive

▶ Watch: Courts can override software EULAs/terms of service disclaiming liability (3:00)

While this talk is not about specific code vulnerabilities or system architectures, the "technical deep dive" here refers to the intricate legal mechanisms and their application—or misapplication—to the unique complexities of software. The core legal framework under discussion is product liability, which traditionally operates on principles of strict liability. This means that if a product is found to be defective and causes harm, the manufacturer can be held liable regardless of whether they were negligent in its production. The economic justification for this is to incentivize the party best positioned to prevent harm (the manufacturer) to do so, and to ensure that the costs of accidents are borne by those who profit from the product.

However, applying this to software is fraught with challenges. What constitutes a "defect" in software? Is it a bug, a vulnerability, or a design flaw? Unlike a physical product where a defect might be a faulty brake or a weak material, software "defects" can be subtle, context-dependent, and exploited by external malicious actors. The talk points out that judges are wary of imposing liability that could "destroy innovation," recognizing that software development, by its very nature, involves iterative processes and the continuous discovery of imperfections. This contrasts sharply with the expectation of near-perfect safety in traditional manufacturing.

A critical aspect of the legal landscape is the role of End-User License Agreements (EULAs) and Terms of Service (TOS). These contracts almost universally include clauses disclaiming liability for any issues arising from the software's use. In the realm of consumer products, courts have often "waved away" such disclaimers, deeming them unconscionable or unfair to ordinary consumers. The question is whether courts will apply similar reasoning to software. While some courts have historically upheld these clauses for software, the speaker suggests that this is not guaranteed and could change as public expectations for software safety evolve. The potential for judicial intervention to declare liability disclaimers in software as "unfair" could fundamentally alter the risk profile for software developers.

The modern software supply chain further complicates the issue. Industrial control system (ICS) vendors like Siemens, Emerson, or Schneider Electric integrate numerous components, including third-party libraries and a "boatload of open-source" code, into their systems. Under traditional product liability, the final seller of a complex system, like Buick in the 1916 case, was held responsible even for components they didn't manufacture. If this principle were strictly applied to software, these large industrial vendors could face significant liability for vulnerabilities introduced by upstream open-source projects or third-party proprietary modules over which they have limited direct control. Ensuring the security and quality of every line of code in such an aggregated product is a monumental, if not impossible, task.

Furthermore, the quantification of damages in software-related incidents presents a unique technical-legal challenge. While a case like Clorox losing 26% of manufacturing capacity and incurring $47 million in costs due to a cyber incident provides a concrete financial figure, translating this into a direct liability claim against a specific software vendor is difficult. It requires proving a direct causal link between a specific software defect and the financial loss, often amidst a complex interplay of user configuration, network security, and attacker sophistication. Unlike a physical product failure, software incidents often involve external actors and a chain of events that obscure direct causality, making it challenging for a plaintiff to prove their case and for courts to award appropriate remedies. This difficulty in establishing clear causation and quantifying damages can lead to "a remedy that most companies are not content with," deterring potential lawsuits even when significant harm has occurred.

Demo / Proof of Concept

▶ Watch: Why corporate victims might struggle more in liability lawsuits (4:05)

This talk was a legal discussion and analysis of complex liability issues, not a demonstration of technical vulnerabilities or security tools. Therefore, no demo or proof of concept was presented as part of the session.

Defensive Implications

▶ Watch: MacPherson v. Buick: Manufacturer liability for third-party components (6:05)

The insights from Stewart Baker's discussion on software liability carry significant defensive implications for both software developers/vendors and the organizations that utilize their products. Understanding this evolving legal landscape is crucial for managing risk and bolstering cybersecurity posture.

For Software Vendors and Developers:

1. Re-evaluate Security Practices and SDLC: The potential for increased liability necessitates a more rigorous approach to security throughout the Software Development Life Cycle (SDLC). This includes adopting secure coding standards, conducting thorough security testing (penetration testing, static and dynamic analysis), and implementing robust vulnerability management programs. Documenting these efforts will be critical for demonstrating due diligence in potential legal challenges.
2. Supply Chain Security: Given the reliance on "boatloads of open source" and third-party components, vendors must implement stringent supply chain security measures. This means vetting suppliers, performing security audits of third-party code, maintaining a comprehensive Software Bill of Materials (SBOM), and having clear contractual agreements with component providers regarding their security responsibilities. The "you sold the product" principle from MacPherson v. Buick could extend liability to the final software integrator even for upstream defects.
3. Contractual Clarity, Not Immunity: While EULAs and TOS may not provide absolute immunity, they remain important. Vendors should review and update their liability clauses to reflect current legal thinking, clearly define the scope of their responsibilities, and articulate any limitations. However, they should not rely solely on these agreements as a shield, especially as courts may increasingly scrutinize them for fairness.
4. Insurance and Financial Preparedness: Software companies, especially smaller ones, need to assess their cyber insurance coverage to ensure it adequately addresses potential liability claims. The risk of being unable to "carry your losses" if sued by a larger client is a significant concern.
5. Industry Standards and Certifications: Proactively engaging with and adopting industry best practices, security frameworks (e.g., NIST CSF, ISO 27001), and obtaining relevant security certifications can serve as strong evidence of a commitment to product safety, potentially mitigating claims of negligence.

For Organizations Using Software (Customers):

1. Enhanced Vendor Due Diligence: Customers must conduct more thorough security assessments of their software vendors. This includes scrutinizing their security practices, requesting SBOMs, inquiring about their vulnerability management processes, and understanding their incident response capabilities.
2. Comprehensive Contract Negotiation: Beyond standard EULAs, organizations should negotiate specific contractual terms with software providers that address security standards, notification requirements for vulnerabilities, incident response cooperation, and clearer liability allocation where possible. This is particularly important for critical infrastructure or operational technology (OT) systems.
3. Quantifying Cyber Risk and Harm: Organizations need to improve their ability to quantify the financial and operational impact of cyber incidents. Detailed records, like Clorox's $47 million loss and 26% manufacturing capacity reduction, are crucial for understanding potential damages and building a strong case if litigation becomes necessary. This data also informs internal risk management and investment decisions.
4. Robust Internal Cybersecurity Posture: While software liability focuses on vendor accountability, organizations must maintain their own strong cybersecurity defenses. Proving that an incident was solely due to a software flaw, and not internal negligence (e.g., poor patching, misconfiguration, inadequate user training), will be critical in any legal challenge.
5. Advocacy and Policy Engagement: Companies benefiting from clear software liability frameworks should consider engaging in industry groups and policy discussions to advocate for sensible legal reforms that balance innovation with accountability.

In essence, the looming specter of increased software liability should prompt a defensive shift towards proactive security measures, transparent communication, robust contractual agreements, and a thorough understanding of the financial and operational impacts of cyber incidents across the entire software ecosystem.

Key Takeaways

• Software liability is an evolving and complex legal frontier, distinct from traditional product liability. While traditional product liability places responsibility on manufacturers, applying these principles to intangible, constantly changing software presents unique challenges.
• The economic justification for product liability—placing responsibility on the party best able to prevent harm—is a core principle. However, identifying that party in the intricate software supply chain, especially with open-source components, is difficult.
• Courts are cautious about imposing liability that could stifle innovation in the technology sector. This judicial restraint has historically been a significant factor limiting the expansion of software liability.
• Standard End-User License Agreements (EULAs) and Terms of Service (TOS) may not offer absolute protection against liability claims. Courts have historically waived such disclaimers in consumer product cases if deemed unfair, a precedent that could potentially extend to software.
• Quantifying damages from software-related incidents, such as data breaches or operational disruptions, is often challenging. While cases like Clorox's $47 million loss are quantifiable, linking them directly to a specific software flaw for legal recourse remains complex, often resulting in remedies that don't fully satisfy the aggrieved party.
• The increasing use of open-source components complicates liability attribution. Vendors incorporating third-party or open-source code into their products may find themselves liable for defects they did not directly create, mirroring the "you sold the product" principle from cases like MacPherson v. Buick.

About the Speaker(s)

Stewart Baker is a highly respected legal expert known for his deep understanding of Washington law and its intersection with technology and security. Throughout the discussion, he demonstrates a nuanced perspective on complex legal issues, particularly in areas like software liability and product accountability. His insights are grounded in extensive experience, allowing him to provide a pragmatic and analytical view on how existing legal frameworks may or may not apply to emerging technological challenges. His ability to explain intricate legal concepts, such as the economic theory behind strict liability and the historical context of landmark cases like MacPherson v. Buick, makes him a valuable voice in conversations about cybersecurity policy and regulation.