More authorities, more CVEs: What it means for app sec teams
The fact that the number of vulnerabilities out there continues to rise isn't the only thing your security team should be concerned about right now, according to an exclusive TechBeacon analysis of the latest National Vulnerability Database (NVD).
The threat landscape is changing rapidly, many more types of vulnerabilities are being identified, and your organization's exposure to vulnerabilities in open source components may not be fully visible to your developers because of dependencies that they're not even be aware of. What's more, many organizations lack an effective strategy for assessing which vulnerabilities pose the greatest risk — and Patch Tuesday is only adding to the stress.
Overloading operations on Patch Tuesday and software flaws hidden in dependencies are the two biggest problems facing companies right now, Brian Martin, vice president of vulnerability intelligence for Risk Based Security, said in the report.
Companies need to adjust their development, application security, and patching processes to better prioritize the increasing number of software issues that present the greatest potential risk to their IT assets and environments, according to TechBeacon's Special Report: National Vulnerability Database Analysis.
Here are the key takeaways from this in-depth report that application security practitioners need to know.
Expect more vulnerabilities in more classes
More than 17,300 software security issues were assigned Common Vulnerability Enumeration (CVE) identifiers in 2019—up by 5% year over year. Part of the increase is due to an expansion in the number companies collecting and disclosing vulnerability information, which has resulted not just an increase in vulnerabilities, but an increased focus on a wider variety of software and hardware.
That means you should be ready to cope with a greater variety in the number of vulnerability classes, also known as weaknesses, that make up the lion's share of vulnerability issues. Until 2016, more than 80% of software security issues assigned a CVE identifier belonged to only 10 classes, or weaknesses, as classified by their Common Weakness Enumeration (CWE) category. But in 2019, the top 10 weaknesses only accounted for 59% of reported vulnerabilities.
There will be a lot of room for the number of software issues found annually to grow, Chris Levendis, principal systems engineer and CVE project lead at MITRE, said in the report.
"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."
More code repositories as CNAs could greatly increase the number of identified vulnerabilities
It's an open question whether the addition of coding repositories will lead to another expansion in the number of vulnerabilities.
With coding repositories GitHub, GitLab, and Bitbucket now all accepted as CVE Numbering Authorities (CNAs)—those organizations permitted to categorize official vulnerabilities—the number of issues could skyrocket. These companies are not only responsible for assigning CVEs to their own software projects, but they can do so for all the projects hosted on their sites as well.
For instance, GitHub, now owned by Microsoft, is responsible for "all libraries and products hosted on github.com in a public repository, unless they are otherwise covered by another CNA," according to MITRE's list of CNAs. GitLab has a similar mandate.
Atlassian, however, is only currently responsible for its own products and Atlassian-maintained software on Bitbucket.
As these companies work with their hosted projects to assign CVEs to vulnerabilities that affect a significant installed base, the number of vulnerabilities may greatly expand yet again.
Open source vulnerabilities: Do you know what's in your software?
Increasing numbers of vulnerabilities discovered in open source software are creating a software supply chain security issue for developers because open source may be in the libraries they use—and the code those libraries incorporate from other open source projects. For example, 85% of the vulnerabilities identified in node.js occur in indirect dependencies, not in the imported component, according to the State of Open Source Security 2020 report by the software security firm Snyk.
"Companies have to know about the vulnerability in the first place, before they can make a strategy to fix it," said Risk Based Security's Martin in the Special Report. That means you need to have better visibility into your software development processes and what's included in your software assets.
Patch Tuesday is becoming a bottleneck
Because of the growing number of vulnerabilities, the second Tuesday of the month, known as Patch Tuesday, is becoming a logjam. Why? Because while Patch Tuesday originated with Microsoft, other vendors have piled on. Today anywhere from three to a dozen companies may release patches on that day, creating a potential patching bottleneck.
To cope, you need to find ways to prioritize patching and vulnerability mitigation, said Brian Martin, vice president of vulnerability intelligence for Risk Based Security, in TechBeacon's Special Report.
"As these patch cycles grow, especially as more vendors jump on the Tuesday bandwagon, organizations are going to have to look past simple CVSS [Common Vulnerability Scoring System] scores to assess risk."
How to triage: What's exploitable and what's not
Just the current 17,000 new vulnerabilites per year comes to more than 65 vulnerabilities a day that teams must deal with. So how do you sort those out - and prioritize? You can automate the process of weeding out any vulnerabilities that don't apply and lower the priority for less critical issues. Then assess the risk: What's the severity, potential impact on the business, and has the vulnerability been turned into an exploit — or is there a high probability that an exploit will arise?
The software-security industry has focused on the likelihood of exploitation as a primary indicator of whether a vulnerability should be given a higher priority. In the future "we may see more modeling based on likelihood of exploitation," said Jonathan Cran, head of research at Kenna Security, a maker of vulnerability-management platforms, in the Special Report. This approach could cut down the number of vulnerabilities that need to be patched by as much as 77%, he says.
But exploitability alone doesn't solve the problem—three quarters of the 17,300 vulnerabilities identified ranked CVSS exploitability rating of 8.0 or higher. And determining likelihood is a difficult problem, Cran admits. "Software is not getting less complex."
Applications with the most vulnerabilities aren't always the most vulnerable
Of the 15 applications with the most disclosed vulnerabilities, two perennial contenders—Adobe's Acrobat and Google—led the pack. The list also includes quite a few newcomers. Three Apple programs or services—Apple iTunes, iCloud, and Safari—had three to four times the number of issues that they had the previous year, taking the fourth, fifth, and sixth places on the list. The repository management software vendor GitLab revealed 166 issues in 2019, more than triple the number of vulnerabilities disclosed the previous year.
Two codebases that had not previously contributed much to the vulnerability count—the cPanel management software and the Magento e-commerce platform—both had significant numbers of vulnerabilities disclosed in 2019.
But these rankings don't tell the full story. The number of vulnerabilities reported can increase when the developer launches a bug bounty program, when it moves from a private to public vulnerability reporting strategy, or when popularity of the software rises. Google Chrome, for example, is widely considered to be one of the most secure browsers, despite having the second highest number of reported vulnerabilities in the list.
Time to prioritize
So what's the best approach? While the number of vulnerabilities is only likely to grow, keep in mind that the number of those that will affect your company is likely to stay fairly constant, unless the the software you use changes.
So assemble a list of vulnerabilities that affect your organization's specific assets, fix those that have public exploit code, then fix any vulnerability that has a high probability of being exploited. By filtering out vulnerabilities based on which affect your software and assessing the exploitability of what remains, you can reduce the number of vulnerabilities you need to worry about by a factor of 20, the report concludes.
For more in-depth analysis of these issues, as well as the rankings of application vulnerabilities, see the Special Report: National Vulnerability Database Analysis. The report also incorporates information from MITRE, Risk Based Security, and Kenna Security.