Vulnerability Prioritization: Are You Getting It Right?

The past few years have seen an exponential rise in the volume of reported security vulnerabilities. Combined with the increase in headline-grabbing security breaches, it's no surprise that organizations are upping their application-security game. This includes a heightened focus on the detection and remediation of security vulnerabilities as early as possible in their DevOps pipeline — leaving developers with the added task of handling an increasingly high number of security alerts.

But they can't remediate everything. This is why they must find a way to zero in on the security vulnerabilities that present the most risk and quickly address them without slowing down the pace of development.

The prioritization of vulnerabilities has become a burning issue for software development outfits that want to stay ahead of security while not falling behind on AppSec release dates. Unfortunately, there is currently no set standard or practice for how to prioritize them. Different teams prioritize security alerts based on a variety of parameters and considerations — not necessarily the most effective ones, either. As a result, they are spending a lot of valuable time figuring out what to tackle first, to varying degrees of success.

To understand which prioritization methods are currently most common, we surveyed 300 of our customers and asked them how they prioritize vulnerability alerts. The top five considerations that arose were vulnerability severity, application type, the popularity of the vulnerable open source component, vulnerability disclosure date, and ease of remediation.

To learn more, we added a new perspective: the hacker community. We took the 100 most common open source vulnerabilities reported in 2019 based on the WhiteSource vulnerabilities database and compared characteristics, such as popularity, disclosure date, and severity score, to the level of discussion in the hacker community based on data from CYR3CON, which predicts cyberattacks based on artificial intelligence gathered from hacker communities.

In doing so, were able to gain insights about the effectiveness of common prioritization methods are and how they measure up when it comes to the hacker community's preferences.

Vulnerability Severity
Many organizations consider the Common Vulnerability Scoring System (CVSS) vulnerability score first when prioritizing remediation since it's so easily accessible and seemingly straightforward. Unfortunately, this parameter does little to shorten the long list of security vulnerabilities that teams need to address since data shows over 55% of the top open source security vulnerabilities were rated as high or critical.

This doesn't mean organizations should disregard a vulnerability's severity score, but it's important to remember that this score doesn't indicate risk. Risk is the impact times the likelihood, but severity only indicates the impact. Organizations need to add additional parameters in order to ensure they are addressing the right issues and not wasting time on security vulnerabilities that pose less of a threat just because they got a high severity score.

Application Type and System Architecture
Many businesses prioritize remediation on vulnerabilities that threaten critical applications related to business data, confidential data, intellectual property, or financial transactions. 

This is an extremely important consideration, but it's challenging to create a one-size-fits-all methodology based on application type when there are so many subjective variables, such as user audience and mobile or web application.

The Popularity of the Vulnerable Open Source Component
Naturally, the more popular an open source component, the more exploit opportunities it provides to hackers.

While we found that 85 out of the 100 most common open source security vulnerabilities in 2019 came up in hacker communities, there wasn't a direct correlation between popularity and the level of discussion.

Clearly, a popular open source component will get the hacker community's attention, but other characteristics also attract hackers to a vulnerability.

Vulnerability Disclosure Date
Many organizations, understanding they can't address the backlog of alerts in their systems, create a cut-off point and decide to only address alerts from a chosen date.

While this is a quick way to lighten the load, CYR3CON data shows many vulnerabilities featured in hacker community discussions occur over six months following disclosure.

Ease of Remediation
As previously mentioned, time constraints and the industry's increasingly competitive release cycles drive development teams to try to address security tasks as quickly as possible. This consideration also factors into prioritization, and the security issues that are attended to first are the easiest, quickest, and cheapest to fix.

While this is another way to cross items off a seemingly never-ending list of alerts, it often leaves critical issues unattended.

How to Prioritize the Security Issues That Matter
One of the most important insights we learned from our study is that when considering which security issues to prioritize, most teams tend to look to the most easily accessible data, which isn't the most indicative of the risk that a security vulnerability poses to an organization.

The research didn't cancel the validity of the five parameters we studied. Rather, it reinforces the understanding that prioritizing security vulnerabilities remediation is complex work. When assessing security alerts in order to fix the most critical issues first, it's important to create a methodology that focuses on the data that matters, going beyond the data that is the easiest or cheapest to access or resolve. 

Related Content: