The recent observation that companies buying software are unaware of 95% of the bugs contained therein places the well-worn argument about the value of security vulnerability research in a new light. Are security researchers, who spend much of their time finding flaws in others' programming efforts and are often the bane of software vendors, doing enough? And do software consumers escape blame for shoddy products put on the market?

Attendees at the Gartner IT security summit keynote session Tuesday responded to an instant poll indicating that most of them, 57% of the 340 people present, believe that vulnerability labs set up by security researchers are a useful public service, while 22%, or 75 people, think they're a distraction that forces them to patch more often.

Yet there's not consensus on how much information to disclose or when to disclose it. The discovery of a security vulnerability in a piece of software is in many ways like seeing that the front door to your neighbor's house has been left open, David Maynor, chief technology officer of Errata Security, said Tuesday. The options are calling the neighbor right away and alerting them to the open door, inspecting the neighbor's house (helping yourself to some of their food and trying on their clothes in the process) before calling them, or calling all of the other neighbors on the block to tell them about the neighbor's open door. An even more nefarious option is to close the neighbor's door but leave it unlocked so that the house can be entered some time in the future. In software terms, that pretty much sums up the spectrum that includes discrete disclosure of software vulnerabilities to the software's maker, full disclosure of the vulnerabilities to the public Internet, and no disclosure at all.

Different researchers take a different approach. Maynor, for example, says he gives the software vendor a month to fix its software vulnerability before he reports the flaw publicly. "We'll give you 30 days to fix a bug, that's it," he said. Thomas Ptacek, the principal of Matasano Security and a member of the Tuesday morning keynote panel, said he's willing to wait until the software maker makes its own decision to publicly disclose a vulnerability before he publishes his report.

One sentiment that's been floated is for software vendors, or internal software developers, to be held liable for flaws in their products that lead to intrusions into their customers' -- or their own -- networks and breaches of data found there. The concept of spending the time and money to write secure programs is a difficult one for company executives on the business side to accept, as it means possibly extending deadlines for deployment, lowering margins on products, or passing along the higher costs to customers. But it's worth it for companies to consider paying extra attention to the security of the programs they write, when you consider the cost of fixing a bug once an application is shipped and in use can be up to 100 times more expensive than identifying the problem during the development phase, Chris Wysopal, chief technology officer for Veracode and the third member of the Tuesday morning keynote panel, said.