Why We're Getting Vulnerability Management Wrong

Sometimes, too much information is a mixed blessing. Security teams use multiple vulnerability scanners in an attempt to cope with a significant rise in both attack surface diversity and software vulnerabilities.

But they soon find themselves overwhelmed with results, which leads to a growing backlog of bugs that need to be fixed. This backlog has multiple negative impacts. It slows the development process because the flaws take time to patch, and ignoring them leads to an excessive amount of tech debt.

Many teams are using outdated practices and limited data, which studies find do not lead to a reduction in risk to an organization's attack surface. In fact, a recent analysis from RAND Corporation found no notable reduction of breaches in organizations with mature vulnerability management programs.

There has to be a better way to handle vulnerability management. I propose a rethink on vulnerability management.

Too Much Noise, Too Few Signals
The new way forward in vulnerability management requires changing the perception that vulnerability management is simply about scanning your software for threats. Why? Because the information scanners give you lack context for any meaningful next steps that reduce risk.

Rezilion's own runtime research analysis finds, on average, only 15% of discovered vulnerabilities are loaded into memory, which makes them exploitable. That means, on average, only 15% of flaws require priority patching — or patching at all. There is more value to be had from applying risk context. Security teams must be able to glean how those gaps could be exploited and the consequences that could occur if they are not addressed.

Most significantly, vulnerabilities must be prioritized based on their severity. But I am not talking about severity based on the common vulnerability scoring system (CVSS). With traditional approaches, security teams are often spinning their wheels scanning and then remediating vulnerabilities that may not pose a serious or immediate threat simply because the scoring system deems them to be critical.

This lack of understanding on criticality can also cause added friction between security and DevOps teams, which typically spar over the need for speed and business agility while maintaining security.

Patch What Matters
Rezilion conducted an analysis of 20 of the most popular container images on DockerHub along with several base operating system images from the three major cloud providers: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). The idea was to assess how many vulnerabilities are not relevant and which ones pose a real risk.

The findings showed more than 4,347 known vulnerabilities. Of those, 75% of those rated as critical or high in severity did not load to memory and posed no risk. Of course, it would be time-consuming and nearly impossible to patch all of these at once. The takeaway is that organizations can use runtime analysis to prioritize remediation of vulnerabilities — and not be daunted by the growing backlog. A vulnerability in a package that isn't being loaded to memory can't be exploited by an attacker.

With this new approach, organizations can utilize their limited resources to remediate the vulnerabilities that actually pose a real threat of exploitation and patch them accordingly. This level of knowledge and prioritization also saves development time and prevents time-to-market delays.

When a risk-based approach is implemented to prioritize vulnerability remediation, the work shifts to containing the threats that pose a significant threat. That in turn reduces overhead and the vulnerability backlog. It also shrinks the software attack surface, making it more manageable to apply patches appropriately.

It's Time for a Change in Vulnerability Management

It's time for a new vulnerability management strategy and it's appropriate to reiterate a few things to think about as you do. Instead of applying static, score-based, or manual policy-driven allow or block decisions, use more context and runtime visibility to make risk-based decisions that are continuous and adaptive.

We are advocating for a rethink in which security teams don't just prioritize vulnerability remediation by using CVSS severity scores alone. Instead, look to tools that allow you to concentrate on the vulnerabilities that pose the greatest risk to your organization. Rezilion provides tools to see into your software environment and determine which vulnerabilities pose a risk and which do not require patching. Security teams should utilize real-time contextualized security controls to understand their true software attack surface. But in order to apply context, you need data that will help identify weak spots in order to refocus remediation efforts on the most critical risks. Otherwise, you're just wasting valuable time finding signals in the noise.

About the Author

Liran Tancman, CEO and co-founder of Rezilion, is one of the founders of the Israeli cyber command and spent a decade in Israel's intelligence corps. In 2013, Liran co-founded CyActive, a company that built a technology capable of predicting how cyber threats could evolve and offer future-proof security. Liran served as CyActive's CEO and led it from its inception to its acquisition by PayPal in 2015. Following the acquisition, Liran headed PayPal's global Security Products Center responsible for developing cutting-edge technologies to secure PayPal's customers.