eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Security researcher David Litchfields announcement that he will give vendors only one week to release security patches before he publicly announces new vulnerabilities highlights the difficult debate over how to best protect IT assets.
Software vendors are often slow to fix problems in their products, and outside pressure (through disclosure and media publicity) is often the only leverage customers have to push vendors to be more responsive. Those who regularly examine security bulletins from major software vendors will notice that, unfortunately, far more security bulletins are issued as a result of a third-party vulnerability report than as a result of a vendors internal security audit process.
Even when vendors concede that a vulnerability is serious, they need a reasonable amount of time to check whether the vulnerability exists on all supported versions and on all supported platforms. And once a patch is developed, it needs to be tested, documented and translated. This quality assurance process is essential because, as Peter Coffee reports, security patches can themselves be a source of pain by breaking existing systems.
eWeek Labs sees the need for a sliding scale of vendor responses. We think vendors should get private and advance notice of vulnerabilities, but they shouldnt be notified so privately and so far in advance that they become complacent.
A deadline of two weeks to produce a vulnerability description and limited workaround (firewall changes or software configuration changes, for example) addresses the immediate need for customers to be informed and to protect critical systems. A workaround can be as good as a patch and is less operationally risky.
Another four weeks should be sufficient to produce patches that properly fix all affected systems.
Enterprise vendors that can fix their problems rapidly—and effectively—have a real competitive advantage over those that cant.
Open-source software also has an advantage because those who discover or are critically affected by a vulnerability can implement stopgap patches themselves while a vendor prepares a more comprehensive fix.