Slow down the security patch cycle

Computerworld - There are many myths surrounding computer network security that are counterproductive to finding a true solution to the problem. One of these is the belief that vendors should speed up the process of producing and releasing patches for security vulnerabilities that have been discovered by security researchers. Instead, we need a completely different solution to the patch management problem, and part of the solution involves slowing down, not speeding up, patch releases.
Slow them down? What about hackers taking advantage of the vulnerability in the meantime? What about those "zero-day" exploits? To answer this, we need to know how the researcher/patcher/exploiter cycle really works and the motivations of each party in the cycle. This cycle is where researchers discover vulnerabilities, software companies patch the vulnerabilities and hackers exploit the vulnerabilities.
First, let's define zero-day exploit. An exploit is a method devised to take advantage of a specific software vulnerability using a software virus, Trojan horse or worm. When the exploit is done without a virus, Trojan or worm, it's using an undocumented feature. The zero-day type of exploit is discovered, not as part of the security research process, but when an active exploit is using a vulnerability the software developer was previously unaware of. Many different groups at that point rush to reverse-engineer the exploit to document the vulnerability. Antivirus vendors compete to be first to announce a method to detect and fix the exploit, and the software vendor must devise and release a patch immediately to combat the exploit.
By far, the most common type of exploit is the buffer overflow, and software vendors are spending millions of dollars to find and prevent these types of vulnerabilities. These vulnerabilities still exist -- they are getting fewer in number, however, and finding them is now much more difficult. Part of my consulting practice to software vendors and their major customers is finding and reporting these types of vulnerabilities. Where I used to be able to do the "find vulnerabilities blindfolded with one arm tied behind my back" routine, I now actually have to work to find them in major software products.

Researchers are motivated to find these remaining vulnerabilities either by a desire to make a name in the software security industry ("Discoverer of the wack-a-mole vulnerability in Linsoft 2004") or, as in my case, because they are getting paid by the vendor or major customers for this research. Independent researchers will report their findings to CERT, and the vendor and researchers will report the vulnerability to the vendor and