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.
