...security researchers who threaten vendors with disclosure of bugs as a problem, she wrote in a recent perspective piece on ZDNet UK sister site CNET News.com. "The reality is that most vendors are trying to do better in vulnerability handling. Most don't need threats to do so," Davidson said.
Alexander Kornbrust specializes in security of Oracle products. He went public with details on six security vulnerabilities in Oracle software in July, about two years after he reported the bugs to the software maker and fixes still had not been provided.
Oracle chided Kornbrust as irresponsible for disclosing the data.
Although not entirely happy about his dealings with Oracle, Kornbrust said it is not an adversarial relationship. "Hostile is not the right expression. I did get feedback from Oracle," Kornbrust said, but that was only immediately after he reported the bugs. Oracle did not give Kornbrust updates on how it was addressing the problems afterwards.
"Oracle supports guidelines for responsible disclosure. One of those guidelines is that the company should send out updates to the researcher. They don't," said Kornbrust, who runs Germany's Red Database Security.
In the past, many hackers and security researchers outed glitches without giving much thought to the impact the disclosures would have on Internet users. Software makers have been working to provide a channel for disclosure. Several have also established patching schedules. Microsoft releases patches every second Tuesday of the month, and Oracle has a quarterly schedule.
Still, the debate on responsible disclosure rages. Recently FrSIRT was the subject of discussion on a popular security mailing list. FrSIRT, formerly known as K-Otic, releases details on vulnerabilities and also publishes exploit code that could help attackers. Sometimes the holes aren't yet patched. Other than FrSIRT selling its service critics are unsure what the purpouse of such a service is.
"With our dependency on IT systems, responsible disclosure is of paramount importance," said Howard Schmidt, an independent security consultant who has served as cybersecurity adviser to the White House and security executive at Microsoft and eBay.
Technology companies that are not responsive to security researchers do pose a problem, Schmidt said. He suggests that the government, specifically the US Computer Emergency Readiness Team [the Department of Homeland Security's Internet security agency], could act as an intermediary. "And then perhaps the government could put some pressure on [technology companies]," he said.





Talkback
Vendors shouldn't lay down security related disclosure rules. Period.
When a researcher finds a flaw he/she should post it in full on a special members only disclosure list and 30 days after the same information should be posted on a public list by someone else. End of story.
That should motivate vendors and researchers alike to be very carefull as to what they publish (or sell on the markets). As well as making sure that they follow up with all required resources.
Don't like? Then make sure that, 1, you don't get posted or, 2, that if you get posted you can fix things within 30 days.
Nothing is perfect. We all know that. So make sure that you're prepared to handle inperfections in a timely matter. In fact, that aspect should have been part of the general design.
The only two constants in IT are: damage and change. So master that. The rest will be part of history sooner or later.
There's plenty of blame to go around.
The software makers are responsible for preventing and repairing issues with the software. This means they should keep any foreseeable holes out of there software and QUICKLY remove any that turn up despite their efforts to prevent them. Those that don't are the blame for making an insecure product; no more, no less.
The press and IT/security professionals are responsible for informing the software makers and computer users of any problems in such a way that does not compound the issue. Those that don't are the blame for reenforcing the problem by preventing appropriate communication.
The IT/security professionals and end users are responsible of understanding and applying the appropriate patches to already installed version of the software. Those that don't are the blame for leaving the issue in play.
The malicious hacker, are also the blame for exploiting these problems and actually aggravating them.