Bug secrecy is a viable solution only if software vendors are followers of W. Edwards Deming’s quality management principles. The longer a bug remains unfixed, the bigger a problem it is. And because the number of systems on the Internet is constantly growing, the longer a security vulnerability remains unfixed, the larger the window of exposure. If companies believe this and then act accordingly, then there is a powerful argument for secrecy. However, history shows this isn’t the case.schneier

As the GNUCITIZEN group grows, the team continue to find vulnerabilities in software products and applications, and there has been no real set policy around our members disclosure of these vulnerabilities. I think most of us have leaned towards the full-disclosure route. Occasionally, the vulnerability has been fairly critical and we have felt that releasing it early would be irresponsible, especially if the vendor had provided us with an acceptable timescale of when a fix would be available.

I had a recent situation where I released a vulnerability to the vendor and the vendor made the details of the vulnerability public. Although, I had warned users to disable a certain peice of software, I ended up releasing the advisory 2 weeks after my email to the vendor, rather then my prefered 4 week waiting period.

The general policy I have seen adopted is to allow vendors 30-45 days to provide a fix before releasing the full advisory. However, a public flag is released immediately allowing users to disable certain peices of software and to create awareness around the particular vulnerability without disclosing the exact details. This seems to be a win-win situation in many cases, but certainly has its points of controversy.

Although this is an age old debate, it is a question GNUCITIZEN will have to answer shortly.