Software makers must improve the robustness of software as a priority over creating new features, but they lack legal incentives to do so, a report by the House of Lords Science and Technology Committee has concluded.
The report on internet security, published in August, said that software suppliers could design more robust software through self-regulation and use of standards such as ISO 9126.
This standard distinguishes software failures in two categories. The first category is not fulfilling a usage requirement, for example, critical banking software having weak authentication. The second category is not fulfilling a specified requirement, for example, software not being interoperable on different systems.
The report found that software is being released with major defects. End-users who suffer loss as a result have no legal recourse against suppliers as licence agreements generally exclude legal liability.
"The absence of liability means that there is little incentive, particularly given the high degree of uniformity across the marketplace, for suppliers to raise security standards in software development," said Lord Broers, chairman of the report.
Because of this, the committee recommended that the government explore the introduction of supplier liability within the industry.
Philip Virgo, strategic adviser at the Institute for the Management of Information Systems, said, "The cautious recommendation from the Lords committee that the government explore supplier liability legislation is well overdue for what claims to be a mature industry selling reliable products and services."
However, Virgo questioned how one would demonstrate negligence on the part of a software supplier, given the complex nature of the product. "Software can be installed or even configured incorrectly by a user - how do you account for that?" he said.
A spokesman for the Department for Business and Enterprise said that before legislation was introduced the industry would have to "look at what would be the likely impact in terms of price and availability of software, and whether legislation would really deliver more robust software".
Guy Bunker, senior director of technical strategy at security software supplier Symantec, said, "I think liability would be very difficult to prove. Software suppliers would have to start to protect themselves legally in the licensing and use of their software, thereby limiting their liability and limiting the functionality and interoperability. Using open source software - where no single person can claim full authorship and responsibility - would also be limited."
Sun already does this with the latest Java Runtime Environment. In a rather extreme example of possible limitations, the licence agreement for the Java environment excludes its use in designing and operating nuclear power stations.
Alan Cox, a programmer closely involved with the development of the Linux kernel, who gave feedback to the Lords committee, said that software can sometimes interact with different applications in unpredictable ways. "The rational thing for a software supplier to do faced with liability would be to forbid the installation of any third-party software on the system," he said.
The Lords report said that some software companies might seek to maximise flexibility and functionality at the expense of security, and others might make security decisions that make it more difficult to download and run third-party applications.
"Good software security begins with good design, but that early on in development, conscious decisions have to be made to balance software security with usability," said Guy Tribble, vice-president of software technology at Apple.
Carrie Hartnell, programme manager at IT suppliers body Intellect, said that bug-free software could not be guaranteed, and changing liability could prevent smaller software development companies from doing business because of the potential compensation costs.
Ross Anderson, professor of security engineering at Cambridge University, said that if liability was introduced, courts would be faced with difficult cases where ascribing liability to a supplier or to a user who misconfigured the machine would be complicated. "But analysing such questions of fact and reaching a judgment is what the courts do every day," he said.
Mark Handley, professor of computer science at University College London, who contributed to the Lords report, said, "A key question is assessing whether the person who wrote the software did the best job that the industry knows how to do in writing that software. If they did, I do not think they should be liable, but if they did not, then I think some liability ought to be there."
Market pressures may encourage the use of a "less than optimal amount of time and resources for testing software", according to a 2002 US report from the National Institute of Standards and Technology entitled "The economic impacts of Inadequate infrastructure for software testing".
Daniel Dresner, head of standards at the National Computing Centre, pointed out the risks in this. "Developers should spend time getting the design right up-front and prioritising the features. Then delivery can be channelled around the benefits required from a release. More features - wow. Bet you do not use half the old ones. More software interaction is bound to lead to more problems, but only if you want to accept the risk," he said.
Dresner said that it would be unfair to lay blame at the feet of software developers, but there needs to be some way forward to sort out problems.
Broers said, "Just because something is complex, it does not mean that we should not begin to take steps to understand it and fix it. It is better to light a small candle than to continue complaining about the darkness."