For decades, the software industry has operated under a liability model that would be unrecognizable in any other sector. If you buy a car and the brakes fail due to a manufacturing defect, the manufacturer is liable. If you buy software and it has a security vulnerability that leads to a breach, you, the buyer, bear the consequences. End-user license agreements routinely disclaim all liability for security defects, and the legal system has generally upheld these disclaimers.
In 2024, that model is under serious pressure from multiple directions. The U.S. National Cybersecurity Strategy, CISA's Secure by Design initiative, and the EU's Cyber Resilience Act are all moving toward a world where software vendors bear more responsibility for the security of their products.
The Current State of Software Liability
Today, software liability is governed primarily by contract law and the terms of service or license agreements that accompany software products. These agreements almost universally include limitation of liability clauses that cap the vendor's financial exposure, often at the amount the customer paid for the software.
When software vulnerabilities lead to breaches, the legal costs typically fall on the customer:
- Incident response and forensic investigation costs
- Notification requirements under breach notification laws
- Regulatory fines (GDPR, HIPAA, PCI DSS, etc.)
- Customer lawsuits and class action settlements
- Business disruption and reputational damage
The vendor who shipped the vulnerable software bears minimal financial consequences. They may issue a patch and an advisory, but the economic impact of the vulnerability is externalized to their customers.
This creates a misalignment of incentives. Vendors are incentivized to ship features quickly and minimize development costs, because the cost of security failures is borne by someone else. Customers are incentivized to invest in security, but they often lack the ability to assess the security quality of the software they purchase and have limited leverage to demand improvements.
The National Cybersecurity Strategy
The Biden administration's National Cybersecurity Strategy, published in March 2023, explicitly called for shifting liability toward the entities best positioned to reduce risk. The strategy stated: "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."
This was a significant policy statement. While a strategy document does not have the force of law, it signals the administration's intent and directs agencies to pursue legislative and regulatory measures that implement the strategy's goals.
Key elements of the strategy's liability provisions include:
- Companies that make software must be held liable when they fail to live up to the duty of care they owe to consumers, businesses, or critical infrastructure providers
- Legislation should prevent software vendors from fully disclaiming liability by contract
- Liability should be calibrated to the vendor's market position, size, and the criticality of the software
The EU Cyber Resilience Act
The European Union has moved faster than the United States on software liability. The Cyber Resilience Act (CRA), which entered into force in late 2024 with a phased implementation period, establishes mandatory cybersecurity requirements for products with digital elements sold in the EU.
Under the CRA, software manufacturers must:
- Conduct cybersecurity risk assessments for their products
- Implement vulnerability handling and disclosure processes
- Provide security updates for the expected product lifetime
- Document known vulnerabilities in technical documentation
- Report actively exploited vulnerabilities to ENISA within 24 hours
Critically, the CRA creates civil liability for software vendors whose products do not meet these requirements. If a product with a known vulnerability causes harm, and the vendor failed to meet their obligations under the CRA, they face regulatory penalties and potential civil liability.
The CRA also specifically addresses open source software, exempting non-commercial open source development from the regulation's requirements while placing obligations on companies that commercially distribute open source software as part of their products.
CISA's Secure by Design
CISA's Secure by Design initiative, culminating in the April 2024 voluntary pledge, represents the U.S. government's attempt to shift vendor behavior through a combination of moral suasion, market pressure, and the implicit threat of regulation.
While the pledge is voluntary, it establishes norms that could become the basis for future legal standards. If a vendor signs the Secure by Design pledge and then fails to deliver on its commitments, that gap between promise and practice could be legally relevant in future litigation.
What This Means for Software Vendors
Software vendors should prepare for a world where security failures carry financial consequences. This means:
Invest in secure development. The cost of building security into the development process is far less than the cost of liability for security failures. Secure development practices, including threat modeling, security testing, code review, and dependency management, become direct investments in liability reduction.
Document your security practices. If liability litigation becomes common, vendors will need to demonstrate that they took reasonable precautions. Documentation of security testing, vulnerability management, and incident response processes will be essential.
Maintain transparency about vulnerabilities. The CRA requires disclosure. The Secure by Design pledge commits to it. Proactive vulnerability disclosure and timely patching reduce both actual risk and legal exposure.
Review your supply chain. If your software includes third-party components with known vulnerabilities, and those vulnerabilities cause harm to your customers, the liability question becomes complex. Maintaining SBOMs and tracking vulnerabilities in your dependencies is both good security practice and potential legal protection.
How Safeguard.sh Helps
Safeguard.sh provides the evidence and process automation that software vendors need in an era of increasing liability. Our SBOM generation and continuous vulnerability monitoring create the documented trail of security diligence that vendors will need to demonstrate reasonable precautions. Policy gates enforce security standards throughout your development pipeline, ensuring that known-vulnerable components do not ship to customers. For software consumers, Safeguard.sh provides the visibility to assess whether your vendors are meeting their security obligations and to hold them accountable when they fall short.