Cybersecurity's Original Sin (Part 1/4)
Part 1 of 4: A 25-Year Audit of Structural Incentive Failures Across Vendors, Operators, Regulators, and Consumers (June 2026)
Author’s note: A substantial rewrite was done to this section based on feedback from readers.
Introduction
The fact that customers must patch, monitor, segment, and defend a system does not erase the fact that the original security weakness was built into the product by the vendor.
That observation is the starting point for this series.
In 2001, the SANS Institute identified ten cybersecurity problems that were already well known to practitioners. Twenty-five years later, nine of those ten failure classes remain active causes of compromise. The question is not whether cybersecurity improved during that period. It clearly did. The question is why the same root causes continue to appear in the largest breaches, the most damaging ransomware incidents, and the most consequential attacks on critical infrastructure.
This series examines whether the persistence of these failure classes is better explained by technical limitations or by the economic and legal incentives surrounding software development.
Cybersecurity’s original sin is not insecure code. It is an accountability structure that made insecure code economically rational. The costs created by insecure design decisions have historically been borne by operators, insurers, victims, and governments rather than by the vendors who introduced the defects. Under those conditions, eliminating the root cause is often less profitable than managing its downstream consequences.
The costs borne by ‘victims’ are not abstractions in a forensic database. A smart lock installed by a domestic violence survivor for safety opens for someone it should not -- because the vendor shipped the device with a remotely exploitable default credential the household had no meaningful ability to change. A baby monitor speaks to a child in their room at night, accessed by someone who was never supposed to be there. A Ring camera streams footage of a family’s home to an unauthorized viewer. These are not edge cases. Mirai infected over 600,000 consumer IoT devices simultaneously on the basis of a single class of error: default credentials the vendor shipped across an identical product line. The household had no IT department, no security budget, no patch management capability, and no ability to redesign insecure architecture. Whatever the vendor shipped became the security model. The EULA clause saying the software is provided as-is does not survive the sentence ‘your home was surveilled by someone you never consented to.’ The accountability structure broke when the victim class changed from enterprises with legal capacity to households with none.
In May 2001, shortly after publication of the original SANS Top 10, I was interviewed by Computerworld for an article titled “IT Security Destined for the Courtroom.” At the time, I believed the growing economic impact of software vulnerabilities would eventually produce significant product liability litigation against software vendors.
The reason I was wrong is itself evidence for the argument that follows.
It was not because the damages failed to materialize. The damages became larger than most practitioners imagined in 2001. It was not because the vulnerability classes disappeared. Most remained active causes of compromise twenty-five years later. I was wrong because I underestimated the durability of the accountability structure surrounding software.
The assumption in 2001 was straightforward. Known defects would eventually generate sufficient economic harm to trigger litigation, litigation would change incentives, and vendors would respond by reducing the defect classes that enabled those harms. That is broadly how accountability evolved in industries such as automobiles, pharmaceuticals, and consumer products.
Instead, the software industry evolved differently. The vulnerability classes persisted. Security spending exploded. Compliance frameworks multiplied. Cyber insurance became a major industry. Entire markets emerged to manage the consequences of software insecurity. Yet broad software product liability never arrived.
Looking back, that failed prediction may be more informative than a successful one. It forces a different question. If the defects remained, and the damages grew, why didn’t accountability follow?
The answer proposed in this series is that the software industry developed a legal and economic structure that successfully transferred most of the costs of insecurity to operators, insurers, victims, and governments. The EULA liability shield, warranty disclaimers, advisory patch model, and compliance-based accountability frameworks did not eliminate the defects. They reduced the economic consequences of shipping them.
That realization is one of the reasons this series exists.
Two Duty Chains, Not One: Vendors, Operators, and Shared Accountability
This series focuses substantial attention on vendor accountability. That focus requires an upfront clarification: vendor design failures are one cause of cybersecurity’s persistence problem, not the only cause. The argument is not that vendors are uniquely culpable and everyone else is blameless. The argument is that vendors are the one party in the system that currently faces minimal legal consequence for their contribution to the problem. Every other actor in the ecosystem already carries some form of accountability. Vendors do not. That asymmetry, not vendor malice, is the structural problem this series addresses.
The ecosystem failure is genuinely distributed. Software vendors have historically faced fewer direct downstream consequences than operators, insurers, or regulated entities. Operators defer patches and run unsupported systems. Executives prioritize feature velocity and operational continuity over hardening. Regulators mandate controls without requiring outcomes. Consumers consistently reward convenience over security. Vendor accountability is therefore not exclusive accountability. The asymmetry this series addresses is narrower: every other actor in the chain already faces some form of consequence for failure.
Vendor liability for design defects and operator liability for operational failures are separate duty chains that run in parallel and do not cancel each other. The two chains address different causal questions: what made the attack possible, and what determined how bad the consequences were. Conflating them allows the vendor who originated the exploitable defect to point at the operator who failed to mitigate it, obscuring who is responsible for what. A compensating control may reduce harm. It does not erase the vendor-originated defect. Operator responsibility becomes relevant, in a liability sense, only where the vendor supplied a timely, effective, and reasonably deployable patch or mitigation, and the operator failed to act. Part 4 develops those conditions into a liability threshold standard.
Operator duty chains already carry legal consequence: breach notification law, regulatory compliance obligations, cyber insurance requirements, contractual liability to customers, and in some sectors personal liability for executives under SEC disclosure rules. Regulators face political accountability for failures on their watch. Security teams face career consequences for incidents. Consumers absorb the direct cost of fraud. The one party whose contribution to predictable exploit-enabling conditions has historically faced the weakest and most inconsistent downstream legal consequence is the vendor who designed the product with exploitable defaults and contractually disclaimed all responsibility through the EULA.
1. The SANS Top 10: A 25-Year Audit
1.1 What the Audit Reveals: A Causal Taxonomy
The pattern in the audit data is not random. To explain why some SANS failure classes improved while others showed little movement, this series groups the failures into four causal categories: exploit-originating defects, operational exposure and consequence management, bounded operator negligence, and vendor remediation/disclosure responsibility. The categories distinguish between the origin of exploit-enabling defects, the operational conditions that govern exploitability in practice, and the remediation and accountability mechanisms that follow. In 1997, the co-author of this series and Tom Wilson published a paper demonstrating how a keystroke recorder could be packaged in an email attachment which is the precise attack vector that remains the leading initial access method in 2026. Full category definitions and the complete SANS mapping are provided in Appendix A.
2. The EULA as a Liability Shield: A Legal Strategy, Not a Legal Inevitability
Why did these problems persist? We need to examine the legal strategy that the software industry consciously built in the 1990s. As software became infrastructure running hospitals, banks, power grids, and government systems, the industry faced a fork in the road. It could accept that infrastructure-grade software carried infrastructure-grade liability, as manufacturers of aircraft, pharmaceuticals, and automobiles do or it could construct a legal argument that software was categorically different and could avoid ordinary accountability mechanisms. Commercial incentives increasingly favored the latter approach, and the resulting liability structure became normalized across the industry.
THE SOFTWARE IS PROVIDED “AS IS,” WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. This single clause, replicated across hundreds of thousands of software products, effectively disclaims liability for every item on the SANS Top 10.
2.1 How the Strategy Worked in Practice
The per-item application of this legal strategy - showing which pillar covered which SANS defect class, and why regulatory mandate was required to displace it - is documented in Appendix A alongside the full causal taxonomy mapping.
The legal argument that allowed the software industry to avoid accountability for insecure products rested on four pillars, each constructed and defended by industry lobbying and sustained by courts that were reluctant to impose product liability on an industry they did not fully understand.
2.1a The Four Legal Pillars
Four recurring legal and contractual mechanisms reinforced this allocation structure across the industry. Four pillars transferred breach recovery costs from vendors onto operators, insurers, and victims through parallel adoption of the same contractual mechanisms.
The intangibility defense. Product liability doctrine does not apply. The speech framing was a lobbying position advanced in academic literature and industry advocacy, not a holding of settled law. U.S. courts have not held that software is categorically exempt from product liability because it constitutes speech. The correct doctrinal account is the intangibility problem. Product liability doctrine, as developed under the Restatement (Second and Third) of Torts, applies to products, i.e., tangible goods. Courts have struggled to classify pure software as a product in this sense, frequently treating software failures as service defects rather than manufacturing defects, and distinguishing between software embedded in a physical medium (where liability is more likely to attach) and pure software delivered electronically (where courts have been less consistent). The industry did not create this ambiguity. It exploited it systematically, embedding it in every license agreement written. The EU Cyber Resilience Act addresses this directly by treating software with digital elements as a product with mandatory safety obligations regardless of delivery medium. (Detail: Appendix B, Note 1.)Product liability doctrine does not apply. The speech framing was a lobbying position advanced in academic literature and industry advocacy, not a holding of settled law. U.S. courts have not held that software is categorically exempt from product liability because it constitutes speech. The correct doctrinal account is the intangibility problem. Product liability doctrine, as developed under the Restatement (Second and Third) of Torts, applies to products, i.e., tangible goods. Courts have struggled to classify pure software as a product in this sense, frequently treating software failures as service defects rather than manufacturing defects, and distinguishing between software embedded in a physical medium (where liability is more likely to attach) and pure software delivered electronically (where courts have been less consistent). The industry did not create this ambiguity. It exploited it systematically, embedding it in every license agreement written. The EU Cyber Resilience Act addresses this directly by treating software with digital elements as a product with mandatory safety obligations regardless of delivery medium. (Detail: Appendix B, Note 1.)
The AS-IS warranty disclaimer. UCC § 2-316 permits disclaimer of implied merchantability with conspicuous "as-is" language. The standard EULA disclaimer mentioning merchantability by name satisfies the requirements of UCC 2-316 for effective disclaimer and closes the warranty claim that would otherwise be available to a commercial buyer of defective software. Importantly, warranty disclaimers are not unique to software. The EULA is the standard commercial risk allocation mechanism the UCC contemplates. What makes software warrant policy attention is that these standard commercial risk allocation mechanisms, when applied to products deployed as public infrastructure, place consequences on third parties and the public who had no role in the contract negotiation and cannot invoke its terms. The structural failure is contract law was designed for willing parties at a negotiating table, not for third parties who agreed to nothing. (Detail: Appendix B, Note 2.)
The advisory patch norm. Security advisories are legally non-binding recommendations. The email attachment attack vector, documented and presented at the SANS International Network Security Conference in 1996, illustrates the advisory norm's structural failure. The attack class was known and vendors chose to frame detection product failures as user error rather than product failures. The EULA enforced that framing. A vendor who discloses a defect and issues a patch bears no liability for harm caused during the remediation window. Equifax (2017) is the canonical illustration: patch available two months before exploitation; software vendor liability zero. CISA's KEV mandatory remediation timelines are the first binding counterweight.
Compliance as accountability substitute. PCI-DSS, HIPAA, SOX, and ISO 27001 mandated control presence, not security outcomes. A web application firewall satisfies a PCI audit whether or not the underlying application has SQL injection vulnerabilities. Compliance became the goal; security became incidental. Vendors benefited from mandatory procurement cycles that did not require root-cause remediation. (Detail: Appendix B, Note 3.)
The CIS Security Controls, which represent the most outcome-focused security framework in general practice, illustrate the structural limit of compliance-based accountability. The CIS Controls are the best available compliance instrument but are still structurally insufficient to solve the problem the series documents because even outcome-focused controls cannot substitute for vendor liability when vendors are not subject to the controls at all. Operators implement the Controls against products whose underlying architecture vendors designed and shipped before any control framework was applied. The Controls manage the exposure, they do not eliminate the defect.
Continues in Part 2/4: The Economic Insecurity Model
This article was written with AI assistance (Claude Sonnet 4.6, Anthropic). The structural analysis, historical judgements, and policy positions are the author’s own. Section-level AI assistance disclosure is provided in the Technical Addendum.
Appendix A: Full Causal Taxonomy and SANS Top 10 Mapping
The fact that customers must patch, monitor, segment, and defend a system does not erase the fact that the original security weakness was built into the product by the vendor. The causal taxonomy used throughout this series assigns each security failure to at least one of four categories. The taxonomy is not a moral ranking. It is an analytical tool for determining which actor’s conduct was the necessary condition for the harm, which actor’s conduct amplified the harm, and which legal track is therefore appropriate. Categories do not cancel each other. A finding of operator loss amplification does not reduce a finding of vendor exploit causation. The four categories run in parallel, and the full SANS mapping below applies them to each item on the 2001 list.
A.1 The Four Categories in Full
Category A - Exploit Causation (Vendor Responsibility): The defect that made the attack possible. This framework distinguishes between exploit-originating defects and downstream operational exposure. A vendor who ships a product containing SQL injection vulnerabilities, shared credentials, unsafe default privilege structures, or comparable implementation flaws created the exploit-enabling condition prior to deployment. Subsequent operator decisions may increase or decrease exposure, but they do not alter the origin of the defect itself. Category A therefore applies to product-level design, implementation, authentication, privilege, default-configuration, and remediation failures introduced before the product enters operational use. Operator compensating controls may reduce exploitability or operational risk, but they do not eliminate the underlying defect. A post-shipping patch confirms that the exploit-enabling condition existed within the product prior to remediation and that the vendor controlled the corrective mechanism.
Category B - Operational Exposure and Consequence Management (Operator Domain): Many Category B operator actions are reactive compensations for exploit-enabling conditions introduced upstream in Category A or D. Operator-controlled conditions that determine whether a vendor-originated defect becomes practically exploitable and how severe the resulting operational consequences become. Category B includes deployment posture, internet exposure of vulnerable systems, unsupported deployments, disabled or absent security controls, insecure integration architecture, exposed administrative interfaces, absent segmentation, inadequate logging, ignored remediation guidance, and deficient incident response capability. These conditions do not create the originating defect itself, but they frequently determine exploit reachability, persistence, lateral movement, detection capability, and operational impact. In many environments, Category B conditions become the decisive factor governing whether a latent defect remains contained or becomes operationally exploitable at scale.
Category C - Operator Negligence (Bounded and Conditional): Operator failure to act on a known, vendor-supplied remedy. Applies only where the vendor provided a patch that was timely, effective, and reasonably deployable, and the operator failed to apply it. If any of those conditions are not met - the patch arrived late, required downtime incompatible with OT operations, or carried unacceptable regression risk - vendor responsibility remains primary. Category C does not apply to configurations or hardening steps the vendor never supplied documented guidance for. The boundary condition is strict: Category C is the exception, not the default, and it never transfers the underlying design-defect responsibility.
Category D - Vendor Responsibility (Design, Remediation, and Disclosure): The vendor shipped the defect, failed to patch it promptly or effectively, failed to disclose it with adequate specificity, and used the four contractual pillars to ensure breach recovery costs landed on operators and victims rather than on the vendor. Not conditional on operator conduct. Category D applies in full where: the defect class was documented and preventable at time of design; the vendor’s remediation was delayed, incomplete or framed as advisory rather than mandatory. Category D is the primary accountability category for seven of the ten SANS items. It coexists with Category B or C findings without cancellation.
A.1a The 25-Year Audit Data
The table below maps each of the SANS 10 mistakes to a revised status assessment. The assessment distinguishes between problem class persistence (whether the vulnerability class remains exploitable) and exploitation rate (whether the class is being actively exploited at scale), and identifies the primary drivers of change or stasis.
Of the ten systemic problems identified by SANS in 2001, one (Mistake 1: default credentials) shows meaningful improvement driven by regulatory mandate and reputational pressure, with important caveats around enterprise and OT software. Two others (Mistake 6: incident response planning; Mistake 9: backup adoption) show nominal to partial improvement, primarily driven by compliance mandates and cloud economics. The remaining seven show negligible improvement in active exploitation rate despite significant defensive investment, with credential abuse, phishing delivery, unpatched known-exploited vulnerabilities, and inadequate logging remaining the dominant initial access and persistence vectors in every major longitudinal attack dataset.
A.2 How to Read the Mapping Table
Each row assigns a primary category (the causal condition most directly responsible for the attack being possible or the harm being unmediated) and notes secondary categories where relevant. The “25-Year Status” column indicates whether the problem class improved, partially improved, or showed negligible improvement across the longitudinal record. The “Primary Driver of Change or Stasis” column identifies what mechanism produced whatever movement occurred. Where the primary driver is “regulatory mandate,” it means voluntary vendor action did not occur and improvement required external compulsion. That pattern is the structural finding.
Category D assignments in the mapping table carry two levels of evidentiary weight. Primary Category D applies where the vendor created the exploit-enabling condition and controlled the remediation mechanism with the unpatched known vulnerabilities, premium-tier audit logging withheld from base-tier customers, default credential architecture, privilege, design decisions made at shipping. These assignments would independently support a products liability or FCA claim given sufficient per-vendor evidence of constructive knowledge. Secondary Category D applies where the vendor used contractual displacement to transfer a shared or operator-domain accountability into an exclusive operator burden with documentation non-provision, policy guidance absence, EULA-transferred safe-harbor obligations. Secondary Category D assignments support the structural finding but would not independently ground a legal claim without additional evidence. Mistake 8 (No Written Policy) carries a secondary Category D assignment on this basis, and is marked B/D shared accordingly. The taxonomy assignments represent analytical judgments applied to publicly documented incident data; while the SANS Top 10 Internet Threats was co-authored by 42 practitioners from across government, industry, and academia not a single author’s list. Independent replication of the taxonomy assignments remains both invited and necessary. The SSAP’s first-year technical priority of publishing the incident database in a peer-reviewed forum is designed to subject these assignments to independent scrutiny.
The SANS Top 10 Internet Threats was not a single-author opinion document. Version 1.10 (June 1, 2000) was co-authored by 42 named practitioners and researchers from NSA, DoD/JTF-CND, CERT/CC, MITRE, Network Associates, Internet Security Systems, Counterpane Internet Security (Bruce Schneier), Foundstone, Purdue University CERIAS (Gene Spafford), UC Davis, Carnegie Mellon University, Boston University, and the SANS Institute. Randy Marchany of Virginia Tech is the first-listed co-author. The document originated from a February 15, 2000 White House meeting with President Clinton on critical infrastructure protection following the 2000 DDoS attacks. It was published in the peer-reviewed professional journal, ISACA Information Systems Control Journal, Volume 4, 2000. Every vulnerability entry embedded MITRE CVE numbers from initial publication. That original document evolved into the SANS/FBI Top 10 Internet Threats and subsequently the SANS/FBI Top 20 Internet Threats, co-published with the FBI’s National Infrastructure Protection Center. Their institutional standing has only grown since publication. Five formal citation lineages establish that the failure classes this series audits are part of the baseline of the field, not a practitioner’s informal list.
First, the CWE/SANS Top 25 Most Dangerous Software Errors: a formal collaboration between SANS and MITRE, the federally funded research organization that maintains the Common Weakness Enumeration taxonomy (MITRE CWE, https://cwe.mitre.org/; SANS CWE Top 25 page, https://www.sans.org/top25-software-errors). The 2025 CWE Top 25 is derived from analysis of CVE records and is explicitly intended to inform vulnerability reduction and policy. MITRE states: ‘The CWE Top 25 highlights the most common and impactful software weaknesses.’ The same weakness classes that appeared in the 2001 SANS list appear in the 2025 CWE Top 25. They have not been resolved. They have been formally enumerated and catalogued for twenty-five years.
Second, the CIS Controls: the prioritized safeguard framework co-developed by the Center for Internet Security from practitioner top-lists and incident analysis, with direct SANS lineage (CIS Controls, https://www.cisecurity.org/controls/). The CIS Controls are mapped to NIST and other frameworks and are used in procurement, compliance assessments, and vendor evaluations globally.
Third, the OWASP Top Ten: the standard awareness document for web application security risks (https://owasp.org/www-project-top-ten/). Its categories -- injection, authentication failures, logging and monitoring gaps -- overlap directly with SANS failure classes and are used alongside SANS material in vendor training and procurement.
Fourth, the Verizon Data Breach Investigations Report (DBIR), published annually (https://www.verizon.com/business/resources/reports/dbir/). The DBIR repeatedly documents leading initial access vectors namely credential abuse, phishing, exploitation of unpatched vulnerabilities that correspond directly to SANS Mistakes 1, 2, and 7. The DBIR is used by vendors, insurers, and regulators to assess the current threat landscape. Its year-over-year consistency across two decades is independent empirical confirmation that the SANS failure classes have not been eliminated.
Fifth, the CISA Known Exploited Vulnerabilities catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog), which documents vulnerabilities actively exploited in the wild with mandatory remediation timelines for federal agencies. The KEV catalog quantifies the continuing exploitation of unpatched vulnerabilities, SANS Mistake 2, with government-mandated response requirements. It is the regulatory operationalization of the same failure class the SANS list named in 2001.
A vendor who claims no constructive knowledge of these failure classes is claiming ignorance of MITRE’s CWE taxonomy, the CISA KEV catalog, the Verizon DBIR, the CIS Controls, and OWASP’s Top Ten simultaneously. That is not a credible defense. It is a description of an organization that has declined to engage with the baseline of the field for twenty-five years.
The distinction between vendor-originated technical vulnerabilities and individual behavior failures was recognized in the original 2001 publication framework. The co-author of this series co-authored both documents simultaneously: the SANS/FBI Top 10 Internet Threats documenting technical vulnerability classes in vendor-controlled systems, and ‘The Ten Worst Security Mistakes Individuals Make’, a separate SANS/FBI/NIPC document documenting user behavior failures. SANS and the FBI drew a clear line between the two accountability domains in 2001. The series audits the former. The industry’s subsequent practice of reclassifying vendor-created technical vulnerabilities as user errors particularly for phishing, where the attack chain was documented by the same co-author in 1996, represents the Category D framing decision the taxonomy assigns, not a legitimate application of the individual-mistakes framework that SANS and the FBI themselves published as a separate document. The person drawing the line between vendor accountability and user accountability in this taxonomy is the person who drew that line in the original 2001 documents. That is not circular reasoning. That is primary source authority.
A.3 SANS Top 10: Full Taxonomy Mapping
A.4 The Structural Finding
Seven of the ten SANS failure classes (Mistakes 1, 2, 3, 4, 5, 7, and 8) are primarily Category A or D: vendor-originated design defects or vendor-controlled remediation failures whose persistence cannot be explained by operator conduct alone. Three (Mistakes 6, 9, and 10) are primarily Category B: operator-domain failures where meaningful improvement occurred or was at least achievable through operator and market action.
The two items showing the most compliance-driven improvement (Mistakes 1 and 6) both share a common feature: the improvement arrived only after external compulsion - regulatory mandate or reputational damage - made inaction commercially untenable. Neither moved through voluntary vendor action. This is not a coincidence. It is the structural finding the taxonomy is designed to surface: in the categories where vendors bear primary responsibility, improvement requires external pressure. In the categories where operators bear primary responsibility, market and compliance forces produced at least partial movement without that pressure. That asymmetry is the accountability argument in longitudinal form.
Appendix B: Legal and Doctrinal Notes
These notes provide the doctrinal and statutory detail underlying the four-pillar analysis in Section 2.1. They are intended for readers who want the legal foundation without having it interrupt the main argument.
Note 1: The Intangibility Problem and the Product/Service Distinction
Strict products liability under the Restatement (Second) of Torts § 402A applies to sellers of products in a defective condition unreasonably dangerous to the user. Courts applying this doctrine to software have split on whether software constitutes a “product” or a “service” - a distinction that determines whether strict liability or negligence governs. The majority treatment has been to characterize software as a service or to decline to extend strict liability on policy grounds, leaving negligence as the primary theory available to plaintiffs. The software industry embedded this ambiguity into licensing agreements early, using language that characterized the software as a “license to use” rather than a sale of goods, further insulating vendors from UCC warranty obligations and products liability exposure. The EU Cyber Resilience Act (Regulation (EU) 2024/2847, in force December 2024, obligations from December 2027) takes the opposite approach, treating software with digital elements as a product subject to mandatory safety obligations regardless of delivery medium. The US has no equivalent federal statutory provision as of this writing.
Note 2: UCC Warranty Disclaimers and the AS-IS Clause
UCC § 2-314 creates an implied warranty of merchantability in the sale of goods - that the goods are fit for their ordinary purpose which attaches automatically unless disclaimed. UCC § 2-316(2) permits disclaimer of the implied warranty of merchantability provided the disclaimer is conspicuous and uses the word “merchantability” by name. The “AS-IS” language found in software EULAs was designed to satisfy this requirement. UCC § 2-316(3)(a) additionally permits disclaimer of all implied warranties with language such as “as is” or “with all faults,” provided it is conspicuous. Consequential damages including lost profits and downstream harm - are disclaimed under UCC § 2-719(3), which permits exclusion of consequential damages unless the limitation is unconscionable. Courts have rarely found software EULA damage caps unconscionable in commercial contexts, though some consumer-protection frameworks apply additional scrutiny. The East River Steamship doctrine (East River Steamship Corp. v. Transamerica Delaval Inc., 476 U.S. 858 (1986)) further limits tort recovery for purely economic loss in product cases, reinforcing the contractual barrier against vendor liability for breach costs that do not involve personal injury.
Note 3: Compliance Framework History and the Control-Presence Model
The major compliance frameworks governing cybersecurity practice in the United States each mandate the presence of specific controls rather than security outcomes. PCI-DSS (Payment Card Industry Data Security Standard, first published 2004) requires organizations processing card data to maintain specific technical controls but does not require that those controls be demonstrably effective against the threat classes they are meant to address. HIPAA (Health Insurance Portability and Accountability Act, 1996; Security Rule, 2003) requires covered entities to implement “reasonable and appropriate” safeguards, a standard that has been interpreted as process-based rather than outcome-based. SOX (Sarbanes-Oxley Act, 2002) Section 404 requires attestation on internal controls over financial reporting; its cybersecurity coverage is incidental rather than primary. ISO 27001 (Information Security Management Systems) and SOC 2 (Service Organization Control) are certification and attestation frameworks respectively, both of which assess documented processes and control presence rather than breach outcomes. The reform direction - articulated in the National Cybersecurity Strategy (March 2023) and reflected in CMMC’s outcome-based assessment methodology - is to shift frameworks from control-presence mandates to security-outcome requirements. That shift has not yet been accomplished in any major general-purpose framework.
Note 4: Timeline of EULA Shield Construction, 1994–2001
The legal architecture insulating software vendors from liability hardened primarily between 1994 and 2001 through the convergence of three parallel developments. First, the enforceability of shrink-wrap and click-wrap license agreements was progressively confirmed by courts in ProCD, Inc. v. Zeidenberg (7th Cir. 1996) and subsequent decisions, establishing that EULA terms - including warranty disclaimers and limitation-of-liability clauses - were binding on users who had not separately negotiated them. Second, UCITA (Uniform Computer Information Transactions Act), proposed in 1999 and adopted in Virginia and Maryland, provided a statutory framework explicitly permitting the disclaimer and damage-cap provisions the industry had already adopted contractually. Third, judicial treatment of the product/service distinction for software consistently declined to extend strict liability, reducing plaintiffs to negligence theories that required proof of unreasonable conduct - a standard vendors had structured their internal documentation to defeat. The SANS Top 10 was published in 2001, at the end of this hardening period, into a legal environment that had already largely resolved the question of vendor accountability in vendors’ favor.
Next: Part 2/4 -