A Comparative Analysis of Software Liability Policies

Fig. 2: A characterization of the optimal patch liability share as it depends on the likelihood of zero-day attacks and the potential magnitude of security losses.

of their products at the design and development stage. There- fore, we subsequently study a long-run setting where vendors can invest in security quality in response to policy. We analyze and contrast three classes of security liability policies, namely (i) Loss Liability Policies, where the software vendor is liable to partially or fully compensate users' losses incurred in case of a zero-day attack; (ii) Patch Liability Policies, where the software vendor is held liable to compensate patching costs incurred by users if a vulnerability is discovered before it is exploited; and (iii) Security Standards Policies, where regula- tion enforces a certain standard of security to be achieved by the vendor during software development to mitigate security vulnerabilities. The former two policies can be applicable in both short-run and long-run settings, while the last one is only applicable in the long run. We explore the role of zero-day attacks by studying and comparing these policies in two security environments, with low and high zero-day attack likelihood respectively. For each class of policies and each zero-day environment, we characterize the optimal policy and study its effectiveness. We then compare and contrast their effectiveness and generate policy recommendations based on our analysis. Our goal is to answer the question whether vendor security liability can be an effective method to improve security and the net social value generated by software, and, if so, how.

III. RESULTS

As can be seen in panel (b) of Fig. 1, a main takeaway from our analysis is that it is advisable to social planners to refrain from imposing loss liability on vendors of soft- ware with interdependent risks. We find that whether or not software vendors have the opportunity to invest in security in response to loss liability makes little difference in the net impact of such a policy: welfare mostly decreases. On the surface, one may think that holding the vendor liable for a portion of consumers' losses would provide increased incentives for the vendor to improve security, and, in some cases, the vendor's optimal investment indeed rises. However, even if investments positively respond, the vendor tends to restrict usage through pricing to limit its exposure to liability on these losses. Hence, loss liability is often an inefficient policy to apply in the software industry. On the other hand, we find that both patch liability and security standards should play an important role in software policy. Security standards are recommended for environments with low zero-day attack risk because, under these conditions, software vendors lack incentives to produce software that is sufficiently secure. On the other hand, sharing of patching costs is recommended for environments with higher zero-day attack risk because of its ability to increase security in riskier settings by incentivizing appropriate user behaviors. Fig. 2 illustrates how the optimal patching cost share (as prescribed by a social planner) varies with economic costs and security characteristics. There are many ways to implement the essence of a patch liability policy. For example, one could have software vendors offer customers who agree to adhere to an appropriate patching strategy with a price discount because patching behavior is verifiable in such interconnected environments.