Table of Contents
As the number of software vulnerabilities continues to rise year over year, the challenges facing companies as they try to keep track of the software flaws that affect the security of their applications—and keep those applications up to date—are both increasing and broadening.
These challenges are exacerbated in many organizations by the lack of an effective, standardized risk metric for judging the exploitability of a particular vulnerability, and a lack of visibility into the full vulnerable surface area of open-source components because of extensive dependencies that most developers don't realize exist in their software.
While the relatively modest growth in the number of vulnerabilities—following a massive jump in 2017—might seem to suggest that the threat landscape is changing very little, that is not the case, said Chris Levendis, principal systems engineer and Common Vulnerability Enumeration (CVE) project lead at MITRE, a government contractor.
"The threat landscape is continually changing. Software and hardware, since the beginning of time, have always been vulnerable. And, there are many more vulnerabilities, because there is much more software and hardware being developed and used."
—Chris Levendis
Figure 1: Data from the National Vulnerability Database shows a huge jump in the number of vulnerabilities between 2016 and 2017.
Using data from the National Vulnerability Database (NVD) and combining that with information from other companies such as MITRE, vulnerability-information firm Risk Based Security, and security-product vendor Kenna Security, this special report chronicles trends in vulnerabilities.
Note: Because this report relies on data from NVD, the US government's standards-based repository of vulnerability data, vulnerabilities that do not have a Common Vulnerability Enumeration (CVE) identifier are not part of the analysis.
What's behind the numbers
In 2017, the number of software flaws assigned a CVE identifier jumped significantly. While many security firms have argued that this expansion in the number of vulnerabilities equates to a higher level of threat, this does not represent the full picture.
Much of the expansion is due to the increased capability of the program that manages the CVE process, with the increase in reported security issues coinciding with organizational changes at the CVE project. Until 2015, for example, fewer than two dozen organizations—called CVE Number Authorities (CNAs)—could submit vulnerability reports and CVE requests to MITRE. By early 2020, that number had increased fivefold, to 129.
The larger number of organizations handling CVE assignments has resulted in better coverage and expedited reporting of vulnerabilities. In 2015, fewer than 6,500 vulnerabilities were recorded as CVEs. Two years later, that had more than doubled, to 14,644.
For the past two years, the number of vulnerabilities assigned a CVE has climbed at a more sedate pace. In 2019, 17,306 vulnerabilities were disclosed by security researchers, open-source projects, and software companies and recorded in the NVD.
Major operating systems see significant reports
Unsurprisingly, the operating systems with the most reported vulnerabilities are the most popular platforms, including eight different varieties of Windows, three different Linux distributions plus the kernel, and two mobile operating systems, including Android—which could also be considered a flavor of Linux.
Finally, macOS X—based on another Unix-like system, Darwin—ranked No. 13 on the list.
Figure 2: The number of CVE reports, listed by operating system, for 2019.
Overall, the various distributions of Linux are seeing less activity than they did in 2018, according to the data. Debian Linux, the operating system with the most reported vulnerabilities both years, saw about half as many issues reported in 2019, compared to the 1,337 issues reported in 2018.
Unsurprisingly, Ubuntu Linux—based on the Debian distribution—saw a similar decrease. The number of vulnerabilities reported in products made by Red Hat, which releases a variety of flavors of Linux, also shrank, to 506 reported CVEs, down from 863 in 2018.
Microsoft encountered the reverse trend, with the number of disclosures in the various flavors of Windows increasing in general. Windows 10 had 449 disclosed issues, up from 257 in 2018, while Windows Server 2016 had 444 reports in 2019, up from 242 in 2018.
Adobe Acrobat continues to post most vulnerabilities
The top 15 applications with the most vulnerabilities reported to the NVD accounted for almost 16% of all reported issues. While Adobe Acrobat continued to top the chart for applications with the most reported CVEs, only two other applications from 2018—Google Chrome and FoxIT's PhantomPDF reader—remained in the top 15.
The changes in the list suggest that vulnerability researchers focused on a new set of applications in 2019. Among the new top-reported applications is CPanel, a web hosting control app that had no public reporting activity in the database between 2010 and 2018 and then suddenly saw 321 issues reported in 2019.
In addition, three applications from Apple—iTunes, iCloud, and the Safari browser—all made the top 15. Finally, Adobe's Magento e-commerce platform, which saw only a handful of vulnerabilities reported over the last few years, suddenly made No. 10 on the list, with 137 reported CVEs.
The number of vulnerabilities reported in an application is not necessarily an indicator of the security of the application. Google Chrome is widely considered to be a secure browser, although it has the second most vulnerabilities reported.
A variety of factors can cause an application to see an increase in vulnerability reports, including the start of a bug bounty program, the decision to move vulnerabilities from a private program to a public one, or the increased popularity of the program itself.
Figure 3: The top 15 applications with the most vulnerabilities reported to the NVD accounted for almost 16% of all reported issues.
Patch Tuesday becomes problematic
The uptick in the overall number of vulnerabilities poses a problem for companies, which have to spend more time triaging the disclosures to separate the relevant issues from the non-relevant and the critical from the low-severity.
Making the issue even worse, a program that originally claimed to ease the triage of vulnerability information by releasing it on a specific day, known as "Patch Tuesday" in the industry, is instead making it harder for security operations teams to keep up.
The problem? After Microsoft started the Patch Tuesday effort in October 2003, other vendors decided that it's in their best interest to release on the same day. Currently, Microsoft, Oracle, Adobe, SAP, Siemens, and Schneider Electric release on the first Tuesday of the month, according to Risk Based Security. And several other companies—such as Oracle and SAP—release quarterly on that day.
In fact, three of the software companies that have adopted the Patch Tuesday release schedules are among the top five vendors in terms of the number of vulnerabilities reported in 2019, accounting for about 12% of all published CVEs.
If other major vendors—such as Google, Linux distributions, Cisco, or Apple—decide to release their updates on the same day, the workload could become prohibitive, said Brian Martin, vice president of vulnerability intelligence for Risk Based Security, which has dubbed such events the Fujiwhara effect.
"As these patch cycles grow, especially as more vendors jump on the Tuesday bandwagon, organizations are going to have to look past [simple Common Vulnerability Scoring System (CVSS) scores to assess risk.]"
—Brian Martin
Figure 4: Three of the software companies that have adopted the Patch Tuesday release schedules are among the top five vendors in terms of the number of vulnerabilities reported in 2019, accounting for about 12% of all published CVEs.
Sometimes-hidden dependencies
Add open-source software to the list of problems as well. While open-source components and projects have created a renaissance in software development, by giving legions of developers a common set of tools and frameworks from which to start, they also pose a software supply-chain security issue for most companies.
A number of popular web-application frameworks, for example, extensively use other code as well. Companies and developers, then, do not have to worry about just their own code or the code in the libraries that they use in their project, but also the code that those libraries import from other projects.
JavaScript-based Node.js, for example, continues to be the most popular web-application framework—with 73% of developers using the programming language and software. Companies, however, have to analyze a lot more code, because 86% of the vulnerabilities in Node.js occur in indirect dependencies, not in the imported component, according to software security firm Snyk.
Overall, these two issues—overloading operations on Patch Tuesday and software flaws hidden in dependencies—are the biggest problems facing companies right now, said Risk Based Security's Martin.
"The volume of Patch Tuesday updates is a big problem, but the dependency issues are even worse, because companies have no visibility into whether they are vulnerable. Companies have to know about the vulnerability in the first place, before they can make a strategy to fix it."
—Brian Martin
Tackling the issues will require companies to have not only good intelligence on the vulnerabilities, but also better visibility into their own assets and software development process.
Exploitability: Key, but hard to calculate
With the rise in vulnerabilities, finding better ways to prioritize patching is critical. Predicting the flaws that will be exploited seems promising, if companies can figure out how to make it work.
Triaging more than 17,000 vulnerabilities each year means that information technology and information security groups need to decide about more than 65 vulnerabilities every work day—a workload that potentially only the most well-resourced companies could manage, said Dylan Thomas, director of product management at Micro Focus.
"The increasing rate of CVE disclosures raises the stakes for developers too, as third-party components form the foundation of modern software. And that's before factoring in the increased attack surface introduced when you introduce containers."
—Dylan Thomas
To dramatically reduce the number of issues, companies can automate the process, weeding out security bugs that impact any software the business has not deployed, as well as those issues that do not have a high criticality. Vulnerability management vendors generally help companies determine whether their assets are impacted by the latest publicly reported vulnerabilities.
Perhaps the best measure of risk, however, is whether a vulnerability has been turned into an attack—an exploit—and whether that exploit is currently being used against targets. Companies that can predict exploitability can get ahead of the attackers and make sure that they have patched software flaws before an adversary targets their assets, said Jonathan Cran, head of research at Kenna Security, a maker of vulnerability-management platforms.
"The technical severity of the bug, obviously, is not enough to know whether to fix it or not. The time and effort that triaging vulnerabilities requires means that it comes back to risk—impact times likelihood."
—Jonathan Cran
As companies struggle with keeping systems—especially critical assets—up to date, and as the number of software flaws continues to climb, predicting the probability that a vulnerability will be exploited has become a key way that companies can prioritize their efforts.
The strategy holds immense promise, especially because software firms are increasingly writing up the reports that represent the official record of a vulnerability. While this makes the process more efficient, businesses need to worry that software makers could downplay the likelihood that a vulnerability will be exploited, said Risk Based Security's Martin.
"Since the reports are coming from the vendors, report confidence can't really factor into additional triage decisions. That takes us back to using exploit availability data to really differentiate some of these. In addition to exploit availability, we may start to see more modeling based on likelihood of exploitation."
—Brian Martin
Goal: Reducing patching workload by a factor of five
Companies that successfully take exploitation likelihood into account could reduce the number of vulnerabilities that need to be patched by 77%. Only 23% of vulnerabilities eventually have an exploit that was publicly available and that only 1% to 2% of CVEs have ever been active exploited in the wild—two decision points for companies' prioritization of patching.
This is according to an early paper, "Prioritization to Prediction: Analyzing Vulnerability Remediation Strategies," by Kenna Security and the Cyentia Institute, a data analytics firm.
However, accurately predicting the exploitation likelihood is difficult.
Using the CVSS, for example, does not give good results for prioritization, the analysis found. The CVSS rates the general criticality of a software vulnerability by its technical ease of exploitation and the potential impact of exploitation to the software system—in other words, likelihood times impact.
The best case allowed by a CVSS strategy is to patch all vulnerabilities with a score of 7 or higher, which would result in a little bit more than half of vulnerabilities properly patched—a coverage of 53%—but with three times the necessary effort. Using data from 2002 to the end of 2017, the Kenna analysis found that 11,600 vulnerabilities would have been properly patched before they were exploited but that another 25,200 vulnerabilities would have been patched and never exploited.
"It is a hard problem. Software is not getting less complex. Systems are not getting less complex. They are just getting more complex components."
—Jonathan Cran
Digging into the latest exploitability data
Another approach might be to use the exploitability subscore of the CVSS, which rates the relative complexity of exploiting the vulnerability in the impacted software. CVSS version 2, for example, first calculates the subscore and then uses it—along with the impact subscore—to assign each vulnerability an overall score.
Yet using that measure does not reduce a security team's workload. More than three-quarters of the 17,300 vulnerabilities published in 2019 had exploitability ratings of 8.0 or higher, making the exploitability index a poor estimate of the actual likelihood that an exploit will be released for a flaw.
Figure 5: Predicting the flaws that will be exploited, and patching those first, is a key strategy for reducing the workload on IT teams.
Another metric that holds some potential is the type of weakness constituted by a vulnerability—as defined by another MITRE initiative, the Common Weakness Enumeration (CWE) project. MITRE has created a list of the Top-25 Most Dangerous Software Errors, an annual ranking that weights issues by their CVSS score and the number of CVEs that are disclosed in any given year.
Figure 6: CWEs, as defined by MITRE.
The most frequently occurring weaknesses in 2019 include the classes that cover cross-site scripting (CWE-79), improper input validation (CWE-20), buffer overflows (CWE-119), and unauthorized information disclosure (CWE-200).
The MITRE rankings just slightly rearrange these classes by taking into account severity: Buffer overflows are by far the most critical issues, followed by cross-site scripting, improper input validation, and information disclosure.
In the end, however, the ranking can provide guidance to software developers. The CWE allows developers to determine which dangerous classes of issues they are allowing to reach production.
Certain CWEs pose a much greater risk to companies—SQL injection flaws (CWE-89), for example, have the highest average CVSS score, at 9.1. And if developers repeatedly make coding errors that allow those issues, then the list may be good guidance as to what areas of secure coding need to be addressed.
In search of better prioritization
For operations, the search for a better way of predicting exploitability, however, is all about the ability to better prioritize patching. Kenna Security found that about 5% of vulnerabilities were both exploited and observed in customer environments, suggesting the power of knowing those two pieces of information.
To better predict exploitability, a variety of other signals can help refine predictions. An assortment of databases—from Metasploit to Exploit.db—can be used to determine whether an exploit has been released, while a company's own intrusion detection data can determine whether attacks are currently happening.
Performing natural-language processing of the CVE descriptions can also return some information that is useful. Finally, knowing the popularity of products and vendors also has some efficacy in predicting exploitation.
"Companies need the technology and processes to focus on actionable outcomes, and exploitability/susceptibility analysis is the next frontier in staying ahead of the oncoming wave of CVEs."
—Dylan Thomas
Yet even the best prediction model—using all of the derived signals—will still result in capturing a bit more than 60% of vulnerabilities that eventually were exploited. It also creates unnecessary work, with the strategy resulting in a third of the patched vulnerabilities never being exploited at all, according to Kenna Security's report.
Overall, security-mature companies have options for reducing the workloads on security teams. The number of vulnerability reports published each year shows no signs of abating and will likely continue to grow as a variety of factors result in more vulnerability disclosures. Finding a way to prioritize the patching of vulnerable software will continue to be a goal for companies.
Increase in covered products, companies issuing CVEs driving growth
The expansion in the number of organizations that assign CVEs—from a handful to more than 120—has eased the backlog of vulnerability information but has also led to an explosion in the number of reported vulnerabilities.
In 2017, the number of vulnerabilities disclosed by software companies and recorded as a CVE identifier more than doubled, to over 14,600 issues, up from nearly 6,500 the previous year.
The massive jump was not a unique event, but a new normal. Vulnerability reports in 2018 and 2019 rose to similar—and even slightly higher—levels.
The jump in the number of software vulnerabilities over the past three years, however, does not necessarily indicate that software is more vulnerable. The rise is not driven by fundamental changes to the threat landscape, but by fundamental changes to the organization of the CVE Project, the group of organizations that evaluates and documents software vulnerability reports.
Yet, for application-security professionals, the result is the same: They should expect to cull through even more vulnerability information in the future, said MITRE's Levendis.
"I think, as a general statement, we should expect year-over-year growth in the CVE program. While there is no way for me to predict how large or small that year-over-year growth will be, the numbers will keep going up."
—Chris Levendis
The "new normal" for vulnerability disclosures set in 2017 was not the first time that recorded vulnerabilities had seen a massive increase.
Until 1999, software vendors did not often disclose vulnerability information, so only tens or hundreds of issues were reported, mostly by security firms. From 1999 to 2004, anywhere from 900 to 2,500 vulnerabilities were assigned CVE identifiers. In 2005, reported vulnerabilities jumped again, staying between 4,000 and 8,000 issues recorded each year. The trend continued until 2017, when the CVEs reported jumped as previously mentioned.
Call it the fourth age of vulnerability disclosure.
Figure 7: CVEs vs. CNAs.
At the heart of the rapid expansion in the number of vulnerabilities is a move by MITRE to make the CVE Project more distributed and expand the ranks of CNAs, the organizations that assign CVE identifiers to vulnerabilities.
Five years ago, MITRE realized that being the hub of the CVE assignment process had resulted in a backlog of vulnerability reports and delayed assignments, Levendis said. Some researchers were no longer even bothering to file vulnerability reports.
"We all realized that if MITRE was the hub of the assignment wheel and had to assign every CVE ID, regardless of how well resourced we were, we would never be able to keep up with demand," he said. "So we changed the philosophy for the program. Three years ago we were a community-participatory program; now we have a community-driven program, where we have drastically increased the number of CNAs."
The number of CNAs, at 129 as of June 24, over time matches quite closely the growth in reported software vulnerabilities, because more CNAs means greater product coverage.
When the MITRE program distributed the work of reviewing vulnerability reports and assigning CVEs by growing the CNAs, the effort resulted in more products being covered. Most CNAs cover the products that the organization produces—or is otherwise responsible for—and the vendors and developers with whom they work.
Before 2005, vulnerabilities were reported in about 1,500 products every year. (See chart, below.) For the past two years, the number of vulnerable products has surpassed 6,600.
Figure 8: For the past two years, the number of vulnerable products has surpassed 6,600.
With more products come more reported vulnerabilities. The relationship between the two is quite linear, and in fact, each product contributes an average of about 2.5 vulnerabilities to the number reported every year.
Application-security teams should expect the trend to continue.
Some large organizations—such as GitHub, owned by Microsoft, and BitBucket, owned by Atlassian—could issue an enormous number of vulnerability reports to the CVE Project because many smaller open-source projects are hosted on those services and could fall under the purview of the service's CNA duties. While both have joined the CVE Project, they are generally reporting only the software flaws in their own products and services, but they plan to expand in the future.
Figure 9: In 2010, the top 10 classes of vulnerabilities—as measured by their CWE category—accounted for 85% of all vulnerabilities disclosed that year. By 2019, the top 10 classes of vulnerabilities only accounted for 59% of reported vulnerabilities.
In addition, the CVE Project is currently working with organizations in 21 countries but expects the number of organizations to grow. More organizations from other countries could expand the number of products covered and cause a rise in the number of CVEs issued.
The increased coverage of products and relatively easier process for disclosing vulnerabilities has changed the mix of reported software issues as well, resulting in a more diverse body of reports. In 2010, the top 10 classes of vulnerabilities—as measured by their CWE category—accounted for 85% of all vulnerabilities disclosed that year. By 2019, the top 10 classes of vulnerabilities only accounted for 59% of reported vulnerabilities.
The diversification of the vulnerability reports could indicate that researchers are looking elsewhere for vulnerabilities, because better security measures protect what has usually been the low-hanging fruit. The broader reach could also indicate that the increase in CNAs has brought a commensurate increase in diverse vulnerability types.
One thing is certain: The CVE Program has a lot of room to grow, said MITRE's Levendis.
"In general, knowing how many vulnerabilities exist in the world is like figuring out how many stars are in the universe. Right? Nobody knows. You can just take a notional guess that there is a whole lot of them and we are not reporting them all."
—Chris Levendis
One common technological force is not necessarily at the heart of the growth in reported vulnerabilities: automation. For the most part, automation and machine-learning systems cannot evaluate vulnerability reports.
While fuzzing—a common technique for finding potential vulnerabilities—does allow the vulnerability discovery process to be automated to some extent, the number of CVEs for which the automation techniques is responsible is not clear.
"We are not close to a machine being able to automatically assign a vulnerability. The technology is not good enough for that."
—Chris Levendis
How to stay on your toes
For application-security experts, the lessons from the latest data fall into three broad areas.
First, expect the number of reported vulnerabilities—those assigned a CVE—to grow. The expansion in the number of CNAs will lead to more products and services being covered, which in turn will lead to more vulnerabilities reported. Moreover, the move to incorporate organizations from more nations into the CVE process will lead to more recorded vulnerabilities as well.
While the number of vulnerabilities will continue to rocket higher, the number that affect a particular company will remain fairly constant, because a business's use of software will not dramatically change. Organizations that focus on identifying their assets and using that as a first filter for paring down the passel of software issues every week can dramatically reduce their workload.
Some application security professionals have urged companies to create an application infrastructure that can easily incorporate patches while mitigating the risk of patch failure. However, adopting such an agile approach is not easy.
"Looking at this with a heavy dose of reality, even for companies that are in this transition to more maintainable systems, what do we do with all the legacy stuff?"
—Jonathan Cran
In the meantime, companies should focus on exploitability as another metric that can help significantly pare down the number of vulnerabilities that IT teams need to mitigate. The two factors of exploitability and whether the company is running an affected product can reduce the number of vulnerabilities relevant to an organization by a factor of 20.
