8 Improving Software Security A Discussion of Liability for Unreasonably Insecure Software
Bibliographic record
Abstract
One of the recurring themes in discussions of the cybersecurity problem is the importance of improving software security. Mass-market software is commonly released containing multiple vulnerabilities. Attempts are then made to patch these vulnerabilities in the widely deployed software. The process is expensive and inadequate. It is likely that, for various reasons, the market is not able to generate the optimal balance of price and quality (including security-related attributes) for mass-market software. The market for key pieces of software may not be perfectly competitive. Second, the market is characterized by various information failures. Third, software security presents an economic externality problem. The insecurity of one user's computer imposes additional costs on others, beyond those suffered by the user. Furthermore, it appears that the incentives facing software developers are such that they focus on speed to market and the development of new features rather than on the security-related aspects of quality. This paper builds on previous work suggesting that the victim of a distributed denial of service attack (DDOS) is well placed to sue the vendor of unreasonably insecure software. This lawsuit would be based on negligence case law establishing that a defendant may be held responsible for exposing a plaintiff to an unreasonable risk of harm at the hands of third parties (namely those who launch the DDOS attack). This paper further develops this hypothetical negligence lawsuit, addressing the standard of care that should be demanded of software developers. Various classes of errors exist, ranging from well-known and fairly easily avoided coding errors to more high-level design problems. While the existence of the former types of errors may be argued to constitute negligence, the latter are less clear. As knowledge about secure design principles matures, it will be possible to include design errors within the scope of negligence. Nevertheless, it would be helpful for liability to serve as a spur to increase the attention paid to secure design so that better secure design techniques may be created and adopted. As a result, courts should require evidence that software developers have made a bona fide effort to include security considerations at all stages of the software development lifecycle.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame distilled prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.
Codex and Gemma teacher scores by category
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.000 | 0.000 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.001 | 0.000 |
| Bibliometrics | 0.000 | 0.000 |
| Science and technology studies | 0.000 | 0.000 |
| Scholarly communication | 0.000 | 0.001 |
| Open science | 0.002 | 0.001 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.000 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one teacher head, not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".