You are on page 1of 20

2020 Q1 Report

Vulnerability QuickView
VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 2

Welcome
The vulnerability disclosure landscape was not immune to the changes brought on by COVID-19. For the first time in years, we
may have seen a true decline in the quantity of vulnerabilities being reported. Does that mean that products and vendors are
actually becoming more secure? Not likely.

It would be easy to make assumptions about the current climate, but at Risk Based Security we strive for accuracy and precision
in our research and analysis. With many factors at play, it will take some time before we can truly understand the influence of
COVID-19 on 2020 Q1’s vulnerability disclosures, as well as subsequent quarters. However, analyzing the currently available data
has revealed several interesting trends, which we’ve explored in this report.

What are the stories behind the numbers? The answers matter to all of us. The more detail you have, the better your ability to
effectively prioritize and remediate risk. Or to put it another way, Better Data Matters . We hope this report helps
®

you understand the current vulnerability disclosure landscape, where we go from here, and what kind of data is needed to see
the big picture.

The 2020 Q1 Vulnerability Report covers vulnerabilities disclosed between January 1, 2020 and March 31, 2020. We hope you find
the report an interesting read.

Key Highlights
• Risk Based Security’s VulnDB team aggregated 4,968 newly-disclosed vulnerabilities during Q1 2020.

• The number of vulnerabilities disclosed in Q1 2020 has decreased by 19.8% compared to Q1 2019. This is likely the only
true dip in at least 10 years, according to Risk Based Security’s research.

• Risk Based Security predicts that COVID-19’s full impact on Q1 2020 vulnerability disclosures won’t be fully known until
next year. Analysis suggests that the count of vulnerabilities disclosed in Q1 2020 may rise to 6,126 as further
information comes to light, but will still represent a decline.

• Risk Based Security has found 561 vulnerabilities disclosed in Q1 2020 that have a public exploit, yet do not have any
detail in CVE/NVD. Of these vulnerabilities missing details in NVD, 60.2% are remotely exploitable - the worst possible
scenario.

• The latest Patch Tuesday reached an all-time high of 465 new vulnerabilities published in a single day. The
overwhelming number of disclosures and patches continue to represent a challenge to organizations.

• Microsoft rises from 9th in Q1 2019 to 1st on the Top 10 List in Q1 2020, surpassing all other vendors for the number of
vulnerabilities disclosed in Q1 2020. Windows 10 leads all products having the most disclosed vulnerabilities in Q1 2020.

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 3

In This Issue
V I EW P O IN TS FR O M

Brian Martin
Vice President,
Vulnerability Intelligence,
Risk Based Security

W E LC OM E
Key Highlights ................................................................................................................................................. 2
Viewpoints ...................................................................................................................................................... 4
The Value of Backfilling...................................................................................................................................... 4
The Year of the Vulnerability Fujiwhara: Two Down, One to Go .................................................................... 7
Vulnerability Trends of 2020 ....................................................................................................................... 11
2020 At A Glance .............................................................................................................................................. 11
“Top” Vendors by Confirmed Vulnerabilities ............................................................................................ 13
“Top” Products by Confirmed Vulnerabilities........................................................................................... 14
Disclosure Over Time ................................................................................................................................... 15
Exploitability Trends in 2020 Q1 ................................................................................................................. 17

In Closing ....................................................................................................................................................... 19
About Risk Based Security .......................................................................................................................... 20
About VulnDB ................................................................................................................................................... 20
No Warranty ................................................................................................................................................. 20

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 4

The Value of Backfilling


Brian Martin, Vice President of Vulnerability Intelligence, Risk Based Security
Brian has been studying, collecting, and cataloging vulnerabilities for twenty-five years both personally and professionally.
He has pushed for the evolution of Vulnerability Databases for years via blogs, presentations, and public dialogue on social
media, and has helped change them to improve their processes and coverage. He was previously a member of the CVE
Editorial Board for ten years and continues to rigorously follow the changing landscape of the vulnerability database
ecosystem.

In every edition of our quarterly Vulnerability QuickView Report, we include a chart that shows how many vulnerabilities were
disclosed so far that year, along with the most current counts for prior periods to show relative growth and decline.

In some cases, as in this year’s Q1, the chart shows a decline


compared to the previous year, and we note that this may or may not
be a true drop in the number of vulnerabilities. It’s worth taking a
moment to explain this in more detail.

For example, in 2019’s year-end Vulnerability QuickView Report, we


noted a 4% decrease in vulnerabilities between 2018 and 2019, despite
a steady increase over the previous years. If we were to re-run those
numbers now, we see only a 1.9% decrease between 2018 and 2019, a
lesser drop than we reported previously. This is because, though 2019
has come to a close, we will continue to find and publish vulnerabilities
that were disclosed in 2019. Similarly, throughout the remainder of
2020, we will continue to find issues disclosed in Q1 and publish them.
No. of vulnerabilities disclosed in Q1, in the last five years
We call this process “backfilling”.

As time goes on, this number of backfilled additions to Q1 2020 will get smaller and smaller until our current research effort will
effectively stabilize, converging on the “true” number of vulnerabilities disclosed in Q1 2020. It may take several years to fully
determine that number, but we want to be as precise as possible, for ourselves and for our customers.

Why does this backfill happen? In the last year, we have added well over 1,000 new sources to be monitored, at an average rate
of over three a day. That explosive growth in source coverage is one way we continue to provide the best vulnerability
intelligence for our clients. With each source comes the backfill, in which we go through the historical content to look for
vulnerabilities not just from this year, but in prior years as well. That may lead us to find vulnerabilities from the prior quarter or
year, or even from ten years ago.

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 5

P R E D ICT I N G T H E “ T RU E ” C OU NT

If we know the rate at which our backfill impacts our vulnerability counts, we can estimate what the “true” count might be for the
current period and, with confidence, determine if there really has been a decline in Q1 2020 compared to prior years. We can
actually extrapolate that now by looking at previous years’ totals (as reported immediately after Q1 of those years), and see how
much those counts increased year-by-year. For example, here is 2017:

Number of vulnerabilities disclosed in Q1 2017, corrected for added backfill each year

By the time Q1 2017 ended, our VulnDB team published 4,440 vulnerabilities that were specifically disclosed in January,
February, and March of that year.

During the remainder of 2017 and 2018, we discovered an additional 815 vulnerabilities that were technically disclosed in Q1
2017, that were later published by RBS. This increased the previous total of Q1 2017 vulnerabilities (4,440) by roughly 18%, to
5,255. At the end of 2019, the count had grown again, but by only 2.2%. At the end of Q1 2020, the count for Q1 2017
vulnerabilities is now 5,422, a growth of less than 1%. Overall, while pursuing our goal of serving our clients’ best interests, it took
three years of backfilling to get a more accurate picture of how many vulnerabilities were disclosed in 2017. This trend is fairly
consistent, and the end result is that we see our “raw count” (the one we publish fresh off the press) mature to a steady future
state within a period of three years.

Based on prior trends, we expect the count for Q1 2019 to reach 6,432 once it stabilizes in 2022. Similarly, we expect to see the
count for vulnerabilities disclosed in Q1 2020 to converge on 6,126, which indicates that we really may be seeing a slight dip in
vulnerabilities in Q1 2020 as compared to the same period in 2019. We’ll have to set calendar reminders to revisit these
predictions.

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 6

W H AT H AP P EN S W H EN W E A P PL Y T H E S AME L E VE L O F SC RU TI N Y T O CV E?

Now, a natural question: how does CVE stack-up? The number of vulnerabilities disclosed in a single quarter, as reported by CVE,
will grow by over 70% before reaching a consistent number. For example, while we initially published 4,440 vulnerabilities in Q1
2017, they published only 1,756 in that same period. Based on our analysis of CVE prior performance, CVE is on track to publish
around 3,158 vulnerabilities for Q1 2017, if we extrapolate the model seven years into the future.

Predicted comparison between VulnDB and CVE’s reported number of Q1 2017 vulnerabilities, in years

While their subsequent backfill, after seven years, nearly doubles the vulnerability count, CVE still misses nearly 2,300
vulnerabilities compared to VulnDB. Lost time is the killer of vulnerability management and CVE simply cannot be relied upon for
timely information. Even after three years, they haven’t reached the total vulnerabilities initially reported by VulnDB in Q1 of
2017. On top of that, though the rate at which they’re uncovering and publishing vulnerabilities is decreasing rapidly, they have
still not stabilized and their count is still growing by a few percent. This is partly because they will publish vulnerabilities using a
CVE ID created years after initial disclosure, and label it as growth, even though it is simply something that was missed. At their
current rate, CVE will never reach the level of vulnerability knowledge that VulnDB has right now.

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 7

The Year of the Vulnerability Fujiwhara: Two Down, One to Go


Brian Martin, Vice President of Vulnerability Intelligence, Risk Based Security
Brian has been studying, collecting, and cataloging vulnerabilities for twenty-five years both personally and professionally.
He has pushed for the evolution of Vulnerability Databases for years via blogs, presentations, and public dialogue on social
media, and has helped change them to improve their processes and coverage. He was previously a member of the CVE
Editorial Board for ten years and continues to rigorously follow the changing landscape of the vulnerability database
ecosystem.

On April 14th, security teams were hit by the latest Vulnerability Fujiwhara Effect, which occurs when the disclosure schedules for
multiple significant vendors collide. In the second storm this year we saw Microsoft, Oracle, Adobe, SAP, Siemens, Schneider
Electric, Broadcom, IBM, McAfee, Xen, Lenovo, VMware, and Intel collectively release a staggering amount of vulnerability
disclosures and patches for previously disclosed issues. As we noted previously, the hours required for IT security teams to
collect, analyze, triage, and then address these vulnerabilities will be considerable.

Yes, we are aware that April is not in Q1 2020 and that most of the vulnerabilities disclosed during the latest Patch Tuesday are
not contained within this report. However, the importance of this event cannot be understated as nearly every major
organization relies on products and vendors contained within these disclosures. As such, it is necessary to discuss what we have
seen and learned so far when it comes to these Vulnerability Fujiwhara storms. Knowing the impact of what has already
transpired may help you judge what to expect in July’s coming storm.

A P R OJ EC T ED F OR E C AS T OF 3 0 0 – 5 0 0 +

January’s Vulnerability Fujiwhara saw a total of 325 new vulnerabilities, which we used as a benchmark to predict the number of
vulnerabilities for April’s event. Based on the work of our VulnDB team, who closely monitor vulnerability disclosure trends, we
warned of a potential of 500 or more new vulnerabilities during our recent webinar Vulnerability Management In the Time of a
Pandemic.

So, what was the total for the latest storm? Overall, April’s Vulnerability Fujiwhara affected nearly 600 vulnerabilities. After our
research team assessed each one, a total of 465 new vulnerabilities were published on that day. That number may still rise
slightly, as our team continues to process entries from additional sources, typically in software that doesn’t enjoy a high
distribution. The average number of newly published vulnerabilities in a day this year is 66, so processing 465 in a single day is a
tremendous undertaking for any organization. This is especially true during a period when some companies have shed IT staff in
the face of economic disruption as a result of COVID-19, and many are working remotely or dealing with disrupted business
processes.

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 8

T A K EAW AY S F R OM APR I L’ S F U J IW HA RA E F FE C T

Here are some noticeable takeaways we saw during April’s Vulnerability Fujiwhara Effect:

• There were three Microsoft fixes for Zero-days being exploited in the wild.

• There were 101 vulnerabilities disclosed that had a CVSSv2 rating of 7.0 - 10.0.

• If your organization prefers CVSSv3 (good luck), 243 vulnerabilities were disclosed that had a CVSSv3 rating of 7.0 - 10.0,
once again pointing out the disparity in CVSS version 2 and 3 scoring.

• Disclosures from six prominent vendors spanned over 12 hours, creating a long-running firehose of new vulnerability
information.

Aside from Intel, most of the vendors we listed as ‘possibly’ disclosing did not release. However, as though to make up for this,
SAP’s vulnerability disclosure, still mostly behind their paywall, was larger than usual.

For organizations relying solely on CVE and NVD, be aware that at the time of publication, NVD was missing CVSS scoring and
Common Platform Enumeration (CPE) details for several Microsoft vulnerabilities. Even worse? It took NVD a whole week to
report these details on three critical zero-day vulnerabilities disclosed by Microsoft on April 14th. This will unfortunately hamper
assessment and remediation efforts for organizations relying on CVE/NVD information.

P A Y C L OS E A TT E NT I ON T O O RAC L E

The bulk of the vulnerabilities disclosed during the latest Vulnerability Fujiwhara Effect came from Oracle. According to Dark
Reading, Oracle accounted for “70% of the patch load, addressing 405 new security vulnerabilities” (based on CVE identifiers).
However, to be more precise, out of those 405 fixes, only 230 of the vulnerabilities were newly disclosed. The remainder of the
175 patched vulnerabilities had been disclosed previously, meaning that for these vulnerabilities, organizations relying on
CVE/NVD have been vulnerable to known flaws for some period of time. And that period of time is significant: up to six years.
However, despite the lost time, these vulnerabilities have been available to VulnDB clients since they were originally disclosed.

Oracle spread out their disclosures in four different advisories:

• Oracle Critical Patches - There were 246 new vulnerabilities in Oracle’s own code, with the oldest vulnerability patched
originating from 2015. There were 203 previously disclosed vulnerabilities in third-party code used within the Oracle
suite of software, with the oldest vulnerability patched originally disclosed in 2014.

• Solaris Third Party Bulletin - There were zero new vulnerabilities in Solaris itself. There were 16 previously disclosed
vulnerabilities in third-party libraries going back to March, 2019.

• Oracle Linux - There were zero new vulnerabilities disclosed. There were 210 previously disclosed vulnerabilities, with
the oldest vulnerability patched originating from 2014. It is interesting to note that four of the 30 Linux Kernel
vulnerabilities are attributed directly to issues in “Unbreakable Enterprise kernel”, but all four are actually vulnerabilities
in the upstream Linux Kernel.

• VM Server - There were zero new vulnerabilities, but three previously disclosed issues all from this year.

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 9

I S T HI S I N T HE C U S TO M E R’S B ES T I NT E R ES T?

Many vendors have adopted Microsoft’s Patch Tuesday as their own, which is now an established norm. We reached out to some
of these vendors in the past and had discussions on this topic. In the end, their stance is that releasing everything together
allows customers to plan ahead and address everything at once. What they don’t account for is when many of their peers do it at
the same time.

600 vulnerabilities and patches in a single day, 465 of those being new vulnerabilities, presents an incredible and overwhelming
challenge to security teams. This raises the question we have been asking both recently and for a long time; Is it even possible to
address so many patches at once? Colleagues that work on vulnerability teams responsible for patching, have told us that
patching Microsoft products alone can represent two weeks of work to test and deploy across their organization. We’ve heard of
teams that spend 30 days dealing with the aftermath of Patch Tuesday, when also accounting for Adobe and a few other leading
vendors. Even if vendors are truly motivated by what they think is best for their customers, a new, better coordinated plan is
required.

V E ND O RS D ON ’T M A KE IT E AS Y

Organizations need to be able to prioritize effectively so that they can mitigate risks that have the highest impact on their most
critical assets. While there is an advantage to having vendors disclose at scheduled intervals, if nothing is done to prevent those
scheduled releases from clashing, even if organizations just focus on select high-deployment vendors like Microsoft, Adobe, and
Oracle, successful, timely mitigation becomes infeasible.

What ends up happening instead is an overload of information that needs to be assessed. The sheer size of the workload, and
the manner in which it is shared, may cause key vulnerabilities to be lost in the process, or delayed for an unacceptable amount
of time. For many of these Patch Tuesday disclosures, organizations cannot even rely on a single advisory from vendors. At RBS
we don’t have to patch thousands of systems, but the fact that Patch Tuesday is becoming overwhelming for us speaks to the
risk to organizations not equipped to handle the volume. The increasing frequency of these Vulnerability Fujiwhara events make
us worry greatly on behalf of the IT teams entrusted with this endless task.

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 10

The Vulnerability QuickView report is powered by

The most comprehensive, detailed and timely source of


vulnerability intelligence and third-party library monitoring.

 DevSecOps

 Security & Vulnerability


Management

 Vendor Risk Management

 Procurement

 Governance & Management

REQUEST A DEMO LEARN MORE


sales@riskbasedsecurity.com vulndb.cyberriskanalytics.com

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 11

Vulnerability Trends in 2020


2020 At A Glance
As we explored earlier in this report, taking a snapshot of the vulnerability count shortly after a given period proves to be
incomplete. In the time it took between noting our vulnerability totals and this report’s publication, we have added almost 200
additional vulnerabilities for Q1 2020. Despite that, using the forecasting above, this is the first time we have seen what may be a
slight dip in Q1 vulnerability disclosures. Even though there are many factors at play, the COVID-19 coronavirus pandemic is a
new factor impacting vulnerability disclosures that is not understood but cannot be overlooked.

Given the unprecedented changes driven by the pandemic, it is difficult to evaluate the direct impact on vulnerability disclosures.
On one hand, with more people working from home, perhaps we’ll see disclosures rise as people skip out on a bit of work to
pursue more stimulating research. Additionally, with massive unemployment and tech sector layoffs, those impacted may turn
to vulnerability research to strengthen their resume. On the other hand, another aspect to consider is covered in our 2020 Q1
Data Breach QuickView Report; indicating that just as breaches are likely going underreported during the pandemic, some
companies may not be disclosing vulnerabilities as well. Between drastic changes in work environments and a global pandemic,
vulnerability disclosure totals are most certainly directly impacted.

With the first significant drop in vulnerability disclosures in Q1, we want to look more closely at the numbers that make up those
totals. When comparing the last three years’ worth of Q1 totals, the results are interesting.

Figure 1: Number of vulnerabilities disclosed in Q1, in the last five years

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 12

Figure 2: Monthly comparison of vulnerabilities disclosed in Q1 for the last three years

Starting with February, we see that 2018 had the most disclosures followed by 2019 and even fewer still in 2020. This is expected
because there is more time to fill in that data through backfill efforts. But when looking at January, we see 2018 is under
reporting compared to 2019 and is almost equal to 2020 despite having two additional years to fill in additional data. It is difficult
to say why January 2018 might be under reporting compared to 2019. Readers of our reports and blogs may speculate that
January 2018’s under reporting when compared to 2020 is because of the January Fujiwhara event. However, that event
produced fewer vulnerabilities than we expected.

Finally, looking at March, even factoring in the backfill that will happen, that month is seriously under reporting compared to
prior years. While the COVID-19 pandemic is an obvious potential influence, it will likely take another year to compare to 2021
along with a more broad vulnerability disclosure analysis in the interim to ultimately determine if that is the reason for this drop.

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 13

“Top” Vendors by Confirmed Vulnerabilities


For ages, many IT folks have wanted to know: “which vendors have the most vulnerabilities?” While a fun question, raw numbers
really don’t have much significance for most organizations. While it may illustrate the extreme differences in patch management
headaches, a vulnerability in a Microsoft product that is not widely deployed, versus a handful of vulnerabilities in an application
found on every desktop, doesn’t make for a good numbers comparison. A vendor that has a thousand vulnerabilities, all
exploitable only to local authenticated users and resulting in a crash, cannot be fairly compared to another vendor who only has
50 vulnerabilities but all can be executed remotely.

Vendors New Rank Old Rank 2020 Totals 2019 Totals


Microsoft Corporation 1 9 324 208
Oracle Corporation 2 3 265 361
Red Hat 3 7 232 293
SUSE 4 1 216 472
Cisco Systems 5 10 204 160
Google 6 8 202 291
Software in the Public Interest, Inc 7 2 160 412
IBM Corporation 8 4 144 325
Canonical, Ltd. 9 6 124 319
Dell 10 5 119 323

Table 1: Top ten vendors by vulnerability disclosures in Q1 2020, as compared to 2019.

That said, purely by the numbers, we see that Microsoft ranked #9 in Q1 2019 and has jumped to #1 in Q1 2020. Of course,
remember that Microsoft only publishes advisories for ‘Medium’ severity issues or higher. So we don’t really get a fair picture of
their actual vulnerability landscape due to their disclosure policy. Right behind Microsoft, holding about the same position as last
ranked, is Oracle. However, we have to consider Oracle’s growing list of acquisitions and how it takes time to bring each
company into the fold and merge their software practices. This could result in vulnerabilities not being accurately reported for a
given year due to silent patches or developer cycles being put on hold pending review and restructuring.

After that, we see the usual suspects in the Top 10. Interesting trends that will take more time to fully appreciate and potentially
explain are the significant jump in volume from Microsoft and Cisco, along with the sharp decline from several other vendors.

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 14

“Top” Products by Confirmed Vulnerabilities


Similarly to vendors, pure counts of vulnerabilities in a given product doesn’t mean much without understanding their nature
and what it represents about the likely code maturity of that product. There are many facets to consider even when looking at a
single vulnerability disclosure attributed to a piece of software.

It is logical to assume that with new features come new bugs and vulnerabilities, and that they will be found and disclosed.
However, with a more mature Software/Security Development Lifecycle (SDLC), one would expect those new features to be more
robust in terms of secure coding practices, and therefore have fewer vulnerabilities. Consider it from the researcher’s side, too:
the tools to find those vulnerabilities, even the more difficult-to-find ones, become a bit easier, resulting in more vulnerabilities.
Ultimately, that means there are just too many factors to consider to definitively say the quality of a piece of software is
improving, solely based on raw vulnerability numbers alone.

In addition, we cannot compare a vendor that has transparency via open source code, that also includes all vulnerabilities
regardless of severity, with a vendor that is closed source and does not disclose any ‘low’ risk issues. In the latter case, one
cannot even safely assume that all medium or high risk vulnerabilities are being disclosed either; their CVSS scoring may not be
accurate. A vulnerability that may have a serious impact on an organization could be scored low due to the vendor’s perception
of access complexity, or the researcher saying it was a low-end crash with no security implications. If neither the researcher or
vendor investigates further, the vulnerability could remain inaccurately disclosed.

Product New Rank Old Rank 2020 Totals 2019 Totals


Windows 10 1 10+ 222 142
Windows Server 2019 2 10+ 204 127
Windows Server (Semi-Annual Channel) 3 10+ 187 91
Windows Server 2016 4 10+ 186 103
openSUSE Leap 5 1 179 437
Debian Linux 6 2 160 411
Red Hat Enterprise Linux 7 7 142 217
Windows Server 2012 R2 8 7 142 217
Windows 8.1 9 10+ 123 68
Windows RT 8.1 10 10+ 131 67

Table 2: Top ten products by vulnerability disclosures in Q1 2020, as compared to 2019.

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 15

Table 2 shows the number of vulnerabilities specific to that product. But notice that there are several versions of Windows on
the chart. That typically means that a single vulnerability can cross multiple versions of the same base software. However, that
does not mean that remediation is the same across each version or that the same team will handle all versions of the software.

Ultimately, there are many caveats to these numbers. So why include them? To explain such caveats and pitfalls so that you can
better understand what vulnerability numbers represent. We hope it helps you to decipher other vulnerability reports, and sets
the stage for understanding where we go from here and how we can use better interpretation of the data to give more helpful
information. For us, that is in the form of our Vulnerability Timeline and Exposure Metrics (VTEM), which uses several points of
metadata to give a picture of software and vendor maturity around these disclosures.

Disclosure Over Time


Days of Our Weeks
We started writing about disclosures by day of the week in search of an answer to a 25-year old question: do vulnerability
disclosures increase when students are on break from university? This topic has sparked debate and contention within the
community, where many have joked that, like Winter, Christmas or Spring Break “is coming”. What that meant for vulnerability
researchers was that they could expect to see a flood of poor-quality vulnerability disclosures and spam being sent to mailing
lists like Bugtraq and Full Disclosure. That is a question that requires a great many graphs to answer, so we’ll save it for an
upcoming blog. But, a fortunate by-product of that research is a higher-level view of disclosures by day, and a couple of
interesting trends that it illuminates.

Figure 3: Number of disclosures each week in 2019

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 16

Day by Day
Before conducting our analysis, we initially started looking at disclosures by year, and above, we can see 2019 as an example.
The first question that came to mind is what would 2019 look like by day. So we jumped ahead to Q1 2020 for a more granular
view, which showed four significant peaks.

Four significant peaks in Q1 2020:

• January 2nd with 163 vulnerabilities

• January 4th with 310 vulnerabilities

• February 11th with 224 vulnerabilities

• March 10th with 219 vulnerabilities

Figure 4: Number of disclosures each day in Q1 2020

You might guess the explanation for three of these peaks: they align to the three Patch Tuesdays in the Quarter (the tallest peak
being January’s Vulnerability Fujiwhara Effect). But what happened on January 2? Skimming the disclosures that day we see one
name frequently appearing: Cisco. Of the 163 vulnerabilities disclosed that day, 103 came from Cisco. Depending on your
vulnerability intelligence and how you prioritize patching, this may be deceptive on the surface. In CVE, this high volume may
appear as only 12 issues because this time, they decided not to abstract for each distinct vulnerability. For some disclosures they
abstract on a per-vulnerability basis, for some they do not.

What are the takeaways from this view regarding the data? First, IT administrators can reliably expect huge swings in disclosures
centered around Patch Tuesday, which hasn’t been “just” a Microsoft affair for a long time. Second, any given day, a single
vendor can release in a way that skews daily averages considerably. In the example above, shops with a heavy Cisco deployment
likely felt discomfort the first week of the year, if not longer.

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 17

Exploitability Trends in 2020 Q1


How to Improve the Limitations of CVSS Scoring
The almost 5,000 vulnerabilities disclosed in the first quarter of 2020 reinforces a point we have been making for years now;
basic risk scores only go so far. If 1,000 of those 5,000 vulnerabilities impact your organization, intelligence on attacker location,
attack complexity, and impact would be more useful than just having a numerical score that is derived from the basics.
Fortunately, the CVSS scoring system allows for additional score weighting via Temporal and Environmental scoring. But since
Environmental scoring is meant to be done by organizations within their own specific environment, Temporal scoring attributes
are what we want to consider.

C V S S T E MP O RA L S C OR I N G

The CVSS Temporal score consists of the status of an exploit, the existence of mitigations, and the confidence in the vulnerability
report. When we publish vulnerability disclosures for our VulnDB clients, rather than attribute a single number reflecting
confidence, we also include technical descriptions that explain if and why we question the veracity of a disclosure. Oftentimes,
it’s not that we dispute a single number, as the report may be accurate in some ways, it is when the report is missing caveats and
conditions. For both the exploit and mitigation status, we have a more granular abstraction than what CVSS offers, especially
around exploit status.

For the availability of a solution, the metadata we provide can help organizations derive a temporal score. It’s safe to assume
that an organization will use those solutions to mitigate vulnerabilities as best they can, so having as much information as
possible is obviously helpful. However, temporal scores do not speak to the risk of actually being attacked and exploited with a
given vulnerability. Instead, it is often logical to use one point of metadata, such as the availability of an exploit, to enhance the
use of a second point, such as the solution.

Before we go into exploit status further, let’s look at how many vulnerabilities have a proof-of-concept or exploit. The
vulnerabilities are broken down in the following ways: if it has a CVE ID with public information, a CVE ID but still in RESERVED
status, or no CVE ID.

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 18

Where Does Exploitability and Availability Overlap?


Figure 5 shows a breakdown of vulnerabilities in Q1 2020, taking a look at three qualities: availability via CVE, remote
exploitability, and public exploit code or a proof-of-concept. While 31.2% of vulnerabilities had some public exploit, 36% of those
vulnerabilities do not appear in CVE. There were 1,200 vulnerabilities disclosed in Q1 2020 that were not particularly out of the
ordinary, in that they had some level of detail in CVE, no known exploit information, and were not remotely exploitable.

In this case, that means there are 561 vulnerabilities disclosed in Q1 2020 with no detail in CVE, but do have a public exploit.
That means that very few security devices, if any, can detect or block many of these exploits. The only real chance for detection
would be that the attack pattern happens to match a more generic signature, but that’s not something you want to gamble on.

Figure 5: 2020 Q1 vulnerabilities with public exploit, by availability

Figure 5: Vulnerabilities of interest disclosed in Q1 2020

Another obvious limiting factor is how many of these 561 vulnerabilities can be leveraged remotely, which we can also see from
Figure 5 is 338, about 60%. This is the exact center of the diagram, the overlap between all three qualities. Those include issues
such as remote authentication bypass, stored XSS, SQL injection, information disclosure, denial of service, and more.

Some of these vulnerabilities are present in software from Symantec, Apple, Atlassian, ManageEngine, Nextcloud, Jetbrains, and
IBM. That should give pause to anyone who has to come up with a mitigation strategy where patching ‘in the right order’
becomes a key strategy.

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 19

In Closing
The ongoing COVID-19 pandemic continues to impact the vulnerability disclosure landscape, and although “backfilling” normally
brings the true count of vulnerability disclosures to a steady state, we are still expecting to see an overall decline in vulnerability
disclosures when compared to Q12019. With the Internet of Things growing rapidly, true declines don’t happen often; this is
likely the first time we have seen a drop in disclosures over the past 10 years. But even though a decline may imply that the
vulnerability landscape is improving, underlying factors suggest that products and vendors are not becoming more secure.
COVID-19 is proving to be a factor that cannot be overlooked, so be sure to read our next Mid-Year report where its impact will
begin to be seen

Methodology and Terms


VulnDB® is derived from a proprietary methodology and daily analysis of thousands of vulnerability sources. Unlike some
vulnerability database providers, Risk Based Security is constantly searching for and adding new sources, in addition to working
closely with customers to ensure coverage of the products they use.

VulnDB counts only distinct vulnerabilities. Products sharing the same vulnerable codebase are considered only one unique
vulnerability. We do not consider vulnerabilities that affect multiple products as unique vulnerabilities as some vulnerability
databases do, which artificially inflates their numbers. To be clear, a vulnerability in a third-party library such as OpenSSL is
treated as one vulnerability; the multiple projects using and integrating that code do not constitute additional unique
vulnerabilities, and are not included in any VulnDB counts.

CVE: Mission vs. Expectations


One of the fundamental objectives of VulnDB is to expand our search methods and collect as many vulnerabilities as possible, to
provide our clients with the most comprehensive vulnerability intelligence available, allowing them to determine which
vulnerabilities are important to their organization.

While we maintain a curated list of thousands of sources that are monitored on an hourly, daily, and weekly basis, new sources
are discovered and/or are brought to our attention every day. CVE on the other hand, issues CVE IDs when requested by a
vendor or researcher. Their mission is not to search for vulnerabilities like a vulnerability intelligence company. Rather, they are
charged with assigning IDs and keeping minimal records.

Why then do organizations, scanning companies, risk platforms, and security service providers continue to use CVE/NDV as a
vulnerability intelligence service and continue to insist that it is “good enough”? Who is best served by this approach? Certainly
not those organizations, government agencies and consumers victimized by the increasing number of data breaches from
exploited software vulnerabilities.

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved


VULNERABILITY QUICKVIEW REPORT BETTER DATA MATTERS®P
PAGE 20

About Risk Based Security


Risk Based Security (RBS) provides detailed information and analysis on Vulnerability Intelligence, Vendor Risk Ratings, and Data
Breaches. Our products, Cyber Risk Analytics (CRA), VulnDB and YourCISO, provide organizations access to the most
comprehensive threat intelligence knowledge bases available, including advanced search capabilities, access to raw data via API,
and email alerting to assist organizations in taking the right actions in a timely manner.

For more information, visit www.riskbasedsecurity.com or call +1 855-RBS-RISK.

About VulnDB
VulnDB is the most comprehensive and timely vulnerability intelligence available and provides actionable information about the
latest in security vulnerabilities via an easy-to-use SaaS Portal, or a RESTful API that allows easy integration into GRC tools and
ticketing systems. VulnDB allows organizations to search and be alerted on the latest vulnerabilities, both in end-user software
and the 3rd Party Libraries or dependencies

A subscription to VulnDB provides organizations with simple to understand ratings and metrics on their vendors and products,
and how each contributes to the organization’s risk-profile and cost of ownership.

REQUEST A DEMO LEARN MORE


sales@riskbasedsecurity.com vulndb.cyberriskanalytics.com

N O W A R RA NT Y

Risk Based Security, Inc. makes this report available on an “As-is” basis and offers no warranty as to its accuracy, completeness or
that it includes all the latest data breaches. The information contained in this report is general in nature and should not be used
to address specific security issues. Opinions and conclusions presented reflect judgment at the time of publication and are
subject to change without notice. Any use of the information contained in this report is solely at the risk of the user. Risk Based
Security, Inc. assumes no responsibility for errors, omissions, or damages resulting from the use of or reliance on the
information herein. If you have specific security concerns please contact Risk Based Security, Inc. for more detailed data loss
analysis and security consulting services.

© Copyright 2020 Risk Based Security, Inc. All Rights Reserved

You might also like