How to Avoid the Looming Threat of Product Liability Fines
Author: Trevor Young
Product liability laws are coming. Are you ready?
Product liability laws have existed for a long time. If you purchase a coffee maker with a defective heating element that then caught fire and damaged your home, the manufacturer of the coffee maker could be found liable for the damages. If a design defect in a children’s stroller results in injuries, the manufacturer is likewise liable.
Software has largely been excluded from discussions around product liability. That is changing. As software becomes an increasingly important part of “products,” including critical infrastructure like energy production and distribution, transportation, and medical devices, regulators have begun considering software as part of the product. We are now beginning to see this reflected in product liability regulations.
In 2023, the US government announced its National Cybersecurity Strategy. The strategy “seeks to build and enhance collaboration around five pillars.” The third pillar is to “Shape Market Forces to Drive Security and Resilience.” This includes an effort to “…shift liability [for insecure software products and services] onto those entities that fail to take reasonable precautions to secure their software…”.
The European Union (EU), however, is far ahead of the US on this matter. In 2024 it made liability for software companies a reality with the revised Product Liability Directive (PLD).
The Product Liability Directive (PLD)
Product liability laws often differ between jurisdictions. In 1985, the European Union (EU) introduced the Product Liability Directive (PLD) to standardize laws across member states and safeguard consumers. The PLD is designed to hold manufacturers accountable for damages resulting from their products, regardless of whether they were at fault. The original PLD primarily focused on tangible products, such as hardware, and did not explicitly cover software or digital products.
Times change, however. Driven by the need to adapt to the digital age, in 2024 the EU revised the PLD to include:
(i) “Software (including software updates) – whether embedded or standalone, including AI systems;
(ii) Digital manufacturing files – enabling the automated control of machinery or tools, such as 3D printers;
(iii) Digital services – where these are necessary for products to function as components of the product with which they are interconnected or integrated (e.g., navigation services in an autonomous vehicle).”
What Changes for Software Companies
The revised PLD has significant implications for organizations building products that include software. These include:
Expanded Liability
Software is now considered a “product,” making developers liable for defects. It also extends to post-release changes (after the product is in the market) for “software updates under the manufacturer’s control, failure to address cybersecurity vulnerabilities and machine learning.” Further, developers may also be responsible for defects in third-party components integrated into their software.
This raises the stakes for organizations to ensure that all aspects of software development, from initial design to ongoing updates and integrations, prioritize security.
Increased Accountability
Ignorance is not an excuse under the revised Product Liability Directive’s no-fault liability system. Consumers of the software and products do not need to prove that a manufacturer was negligent to claim compensation for damages. This liability covers various damages, including data loss or corruption, personal injury, property damage, and material losses.
Greater Scope in Risk Management
Software organizations have long needed to pay attention to privacy standards. With the revised PLD, risk managers and Boards of Directors must contend with product liability risk. Organizations should reassess their development processes to ensure they deliver more secure code.
Challenges Addressing the Revised PLD
The PLD marks a significant shift in consumer protection by extending liability to digital products, including software and AI systems. The directive’s broadened scope means that software integrated into physical products or provided as standalone services can trigger liability if it contributes to defects causing harm.
In other words, shipping software with vulnerabilities and flaws brings added risk to the organization. This poses substantial challenges for software organizations and security teams, including:
Overcoming a “find and fix” culture: Many organizations treat security as a service offering to development teams. Engineering will produce builds that are scanned using application security testing solutions like Static Analysis (SAST) and Dynamic Analysis (DAST) to identify design flaws and coding errors that can result in vulnerabilities, and Software Composition Analysis (SCA) to find vulnerable open source components. Bug reports are provided to development teams with recommendations for prioritization. This “find and fix” approach to security delays software releases, as bugs found later in the development process can take significantly longer to address. Our study, The State of Security by Design and Threat Modeling in 2024, found the mean cost to fix a bug late in the development process exceeded $50,000.
Worse, pressure to ship often leads to software releases that include vulnerabilities with plans to address those issues in later releases.
Aggressive development schedules: Rapid release schedules can provide organizations with a competitive advantage, and the adoption of rapid development programs like DevOps or Continuous Integration | Continuous Deployment continues.
Integrating security into these environments can be disruptive. Aggressive timelines may lead to insufficient testing and quality assurance, increasing the risk of defects, vulnerabilities, and potential liability claims.
Defining security requirements: When defining new or updated software, most organizations focus on the product’s functional requirements. These define what a system must do to meet user needs. Building secure software requires teams to consider security requirements focused on protecting the system and its data. These can include limiting user privileges, prohibiting hard-coded credentials, and validating untrusted input. Manually creating security requirements and ensuring proper execution is time-consuming, does not scale, and is difficult to document.
Insufficient secure coding training: Ensuring that developers are writing secure code as the development process begins would obviously help build more secure software.
Unfortunately, developers are not trained sufficiently to code securely. Most universities do not address secure coding as a core requirement in their undergraduate programs.
Secure by Design Addresses Product Security Proactively
Avoiding product liability claims requires organizations to build and maintain secure software throughout the product’s lifecycle. Implementing Secure by Design can play an important part in this. Secure by Design is a philosophy emphasizing integrating security measures into every stage of the software development life cycle rather than treating security as an afterthought. This approach helps ensure that software products are fundamentally secure from the outset, reducing the likelihood of vulnerabilities and potential liabilities.
Here are three best practices to support Secure by Design.
Build security requirements into developer workflows
As noted, a “find and fix” culture is reactive and slows down development teams when security issues are identified later in the development process. In contrast, security requirements anticipate threats to an application and prescribe specific, measurable, and actionable controls to protect information assets and systems.
Security requirements are part of the development team’s workflow in high- performing organizations. Tasks can be assigned in issue-tracking solutions like Jira, including code snippets and testing procedures. This allows development teams to implement approved controls as they build code, minimizing security tasks and maintaining development velocity. By integrating security into the development lifecycle, they ensure that systems are built with security in mind rather than as an afterthought. As an added benefit, a proactive approach allows teams to avoid coding errors that would later be flagged by security testing (or completely overlooked!).
Map requirements to industry standards
To mitigate the risk of liability, map your requirements to an internationally accepted standard that covers a broad range of risks. Examples include HIPAA, GLBA, PCI, ISO- 27001, DIACAP, privacy requirements including GDPR, California Privacy Act, and PIPEDA, and industry standards like NIST 800-53 and 800-82. You can demonstrate your commitment to following industry best practices by aligning with widely accepted cybersecurity frameworks. This is evidence of due diligence in protecting against defects and security vulnerabilities. These comprehensive standards typically address various risks, enabling organizations to implement safeguards against potential liabilities.
The international recognition of these standards also lends credibility to an organization’s security efforts on a global scale, which can be particularly beneficial when addressing the requirements of the EU’s revised PLD.
By adopting such widely respected frameworks, companies can demonstrate a proactive approach to security that customers may view favorably, providing a competitive advantage to the organization.
Invest in automation
Attempting to identify, communicate, and track security requirements manually is challenging for a single project, much less across an enterprise’s entire application inventory. Even well-staffed organizations face challenges with manual approaches, including:
• Scarce Senior Resources – Identifying risks and proactive controls requires senior security and development resources to discuss architecture, frameworks, deployment environments, and applicable regulatory requirements. These resources are scarce and in high demand.
• Scalability – Manually modeling threats to an application and identifying appropriate controls can take weeks. Doing so for each project is not practical in most organizations. This often limits generating in-depth security requirements to an organization’s most critical projects.
• Consistency – Ideally, organizations will analyze each application and apply consistent controls. However, a security requirements exercise will reflect the knowledge and biases of those participating. As team members change, identified risks, threats, and controls will also change.
• Auditability – Manual processes frequently rely on spreadsheets, shared documents, or email threads to communicate required controls. This provides poor evidence of compliance with corporate policies and regulatory standards.
Automation addresses each of these challenges. By adopting an automated approach, teams can easily scale security requirements across their entire application inventory without burdening senior engineering and security resources, ensure consistency across all projects, and maintain a secure audit trail tracking all activity.
How Security Compass Helps
SD Elements allows teams to automatically identify threats and generate security requirements across their software initiatives. Based on a brief survey, SD Elements identifies applicable regulatory standards and threats to an application’s technology stack and deployment environment. It then translates those threats into actionable security controls and assigns them to development, QA, security, and operations through the teams’ existing systems, such as Jira.
SD Elements enables development teams to build secure applications and comply with security requirements in a platform that is:
• Scalable: SD Elements automates building secure coding requirements in a self- service model. The survey can be completed by project leads to identify risks and produce security requirements in a few hours. This allows organizations to scale secure coding standards across their entire application inventory without increasing demands on senior resources.
• Consistent: SD Elements provides teams with professionally curated security controls to ensure that teams apply consistent and effective countermeasures. Extensive secure coding policies are included with SD Elements, or organizations can add their own policies.
• Just-in-Time Training Modules: SD Elements delivers contextual learning directly to developers’ workstations. Brief Just-in-Time Training (JITT) modules are mapped to security requirements and countermeasures and delivered to developers through their existing workflow.
• Accurate: The SD Elements Security Content and Training Library covers compliance requirements for standards including HIPAA, GLBA, PCI, ISO-27001,
DIACAP, privacy requirements including GDPR, California Privacy Act, and PIPEDA, and industry standards like NIST 800-53, 800-82, and others, ASD-STIG, OWASP Top 10, and SANS Top 25 to ensure full compliance.
Security by Design
SD Elements ensures that software is built with security and compliance from the beginning of the development process, preventing delays and costly rework.
About the Author
Trevor Young is the Chief Product Officer at Security Compass, who leads the Product team and key stakeholders in defining the vision and strategy of the SD Elements platform and E-Learning and Training products. Trevor spent the first half of his career as a developer, enterprise architect, and software leader before transitioning into Product Management. He has over 12 years of experience managing enterprise B2B and B2C products and platforms in Fintech, AdTech, Data subscriptions, and other highly regulated and security-sensitive industries.