There are some trade-offs here - first, don't discount the risk of regression, especially if you have a very large number of customers. The updated executable may also contain a number of additional fixes, and if you don't test them together, things break. When things break, customers don't just automatically install the patch, and vuln-days climbs quickly.
Remember that the people running the network fear downtime more than anything else.
Next, we fix a bunch of issues that aren't weaponized. Basically, the bar is that if you can't prove it isn't exploitable, you fix it. I don't have numbers, but quite a lot of the things that get fixed never do get weaponized. While this is the right thing to do overall, from the customer/vendor standpoint, you're taking regression risk for minimal security gain.
I'm somewhat doubtful that things get independently rediscovered very often. What I think is most often the case is the real finder shared the bug with 3 of their closest buddies, which quickly expands to a lot of people. This actually supports your argument that vendors should attempt to drive response times as low as practically possible - IMHO, true responsible disclosure is rare. I've also witnessed incidents where finders didn't really find anything, but just pretended that to a vendor, and incidents where the finder was responsible, but the company overall had leaks.
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
