A study of more than 300 companies published last week found that nearly 80 percent of companies support security consultants and hackers releasing information about software vulnerabilities even when the developers aren't prepared, and that they want news of potential flaws within a week.
The desire for greater and more rapid disclosure comes more out of spite than as a way to increase security. Slightly more than half of those in favor of disclosure seemed to support it as a way to embarrass software companies that haven't done an adequate job busting bugs in their programs, rather than as a way to protect themselves against future attack.
"They are tired of software vendors not writing good code," said Pete Lindstrom, director of security strategies for the Hurwitz Group, a technology consultancy. "The end users are the ones saying we don't care about time periods, we don't care about patches--just get the information out."
The findings undermineby several software makers, most notably Microsoft, and some security consultants, to define "responsible" disclosure as the release of information after a developer has had a chance to create a patch or after 30 days, whichever comes first. The fact that corporate software customers--those hurt worst by software makers' slipups--disagree with the delayed-disclosure policy removes a much-touted claim from the developers' side of the debate that they have customers' interests at heart.
"Every time we see a vendor scream about (a bug being disclosed before) 30 days, and that that hurts the end-user...the customers are saying that's crazy," Lindstrom said.
The focus on software maker liability for shoddy products has gained steam this year with areleased by the National Academy of Sciences recommending that federal lawmakers create legal guidelines to hold companies responsible for bugs in applications that affect security.
Software customers seem to not want to wait for Washington to weigh in. More than two-thirds of the companies polled felt that a bug should be made public in a week or less, even if the maker of the application is not prepared. The vast majority of companies split, however, on how much information should be made available: 40 percent for only a general description of the flaw and another 40 percent for a more detailed report. Very few companies thought that "exploit code"--source code that could be used to create an attack program--should be included in the report.
While software companies' customers seem to be generally dissatisfied with the quality of the product they're buying, they aren't ready to switch to another provider based on poor security alone, the survey found.
"It is really kind of fascinating," said Lindstrom. "Not only do you have end users that are fed up, but despite that, no one will get rid of their software because of vulnerabilities. There doesn't seem to be a great answer to this."
The survey also found that more than two-thirds of respondents felt that the cost of security incidents caused by flaws were low or negligible.
Other data also showed that most companies thought the media overhyped security vulnerabilities and that very few got information about flaw from the news. Most relied on industry-focused mailing lists.