The number of software vulnerabilities reached an all-time high in 2014 the overwhelming majority of which had patches available on the day the issue was made public, research outfit Secunia has reported in its annual review.
But the figures, taken from the firm's Personal Software Inspector (PSI) tool, reveal a troubling sting in the tail - if the patch wasn't available on day one it was unlikely to be made available for some time - or possibly ever - forcing organisations to come up with alternative and complicated fixes.
As for vendors using open source libraries, many take week or months to patch the small but growing clutch of serious flaws being discovered in this class of software, a leisurely approach that looks increasingly out of touch with the realities of software insecurity.
Secunia recorded a total of 15,435 software vulnerabilities for the year, a figure that has accelerated sharply since 2012 when it stood at around 10,000. In 2014, vulnerabilities were found in 3,870 applications from 500 vendors, underlining the complexity of the patching workload now being imposed on organisations.
Within this, the 50 most popular applications suffered 1,348 vulnerabilities, almost three quarters of which were rated by Secunia as 'highly' or extremely' critical which means they required urgent patching.
Of these, seven out of ten were Microsoft applications that were responsible for only 23 percent of the vulnerabilities. The message from this is simple - focusing on Microsoft patching won't protect organisations because most of the risk lies elsewhere.
Secunia doesn't include Windows XP in any of these calculations although a surprising 12 percent of its user base were running this operating system despite its end of life status.
As for time to patch, the low point for patch availability was 2009 when only half of vulnerabilities had fixes available on day one since when the percentage has risen steadily to 2014's 83.3 percent. Thirty days later, that rises to 84.3 percent, in other words barely changes at all.
"If it isn't patched on the day of disclosure, chances are the vendor isn't prioritising the issue," said Secunia's director of research, Kasper Lindgaard.
"That means you need to move to plan B, and apply alternative fixes to mitigate the risk."
The improvement in the time-to-patch was most likely a result of better coordination between researchers and vendors, which is to say that many now have paid programmes in place designed to get early information on flaws.
Secunia doesn't say which applications and vendors fit into the slower patching cycle but it can be assumed that it won't be major vendors such as Microsoft or Adobe, or browser makers Google, and Mozilla. The culprits are probably smaller vendors without flaw disclosure programmes.
As for the anxiety-ridden topic of zero days, once rare these are now a major aspect of any and every vulnerability report, rising from 14 in 2013 to 25 last year, almost all in the top 25 most popular applications. This underlines the importance of rapid patching.
Secunia touches on the issue of open source flaws, timely given that several high-profile issues were discovered during 2014 in bits of software nobody had paid much attention to until then.
According to Secunia, there is a major problem here because even large vendors don't seem to be reacting rapidly to these issues. Unlike closed source software that has gone through years of pain, there seems to be a degree of complacency among some vendors.
Again, Secunia doesn't name names but one vendor took 160 days to issue a patch for the one OpenSSL flaw with a number of others taking weeks to address Heartbleed and Shellshock. To be clear this isn't an issue to do with open source software per se so much as the third parties using it inside their products.
"We find that there is no general pattern to response times. Consequently, organisations can not presume to be able to predict which vendors are dependable and quick to react, when vulnerabilities are discovered in products bundled with open source libraries," said Lindgaard.