How do you effectively remediate the increasing sea of vulnerabilities?

Mar 11, 2020 / 4 min read

Table of Contents

What’s the problem?
Dissecting a vulnerability
Scoring
CWE
Exploit
Solution or workaround
Effective remediation through prioritization

What’s the problem?

If there’s one conclusion we can all agree on about open source software, it’s that it has blown way past the tipping point in terms of usage. Development teams have embraced open source for its inherent strengths: efficiency, speed, quality, and innovation. Gartner even claims, “In most modern DevOps development projects, the majority of code used in an application is made up of open source” (Gartner, Technology Insight for Software Composition Analysis).

But with those advantages come responsibilities that teams also need to consider. And with more than 16,000 vulnerabilities disclosed each year (that’s more than 40 per day!), those responsibilities include understanding and mitigating potential security risks.

So if applications are increasingly built on the foundation of open source, and more than 40 vulnerabilities are disclosed per day, how do development teams wade through the sea of vulnerabilities flooding their notification stream so they can prioritize their remediation efforts on the most critical?

Dissecting a vulnerability

To answer that question, let’s first try to dissect the key attributes of a vulnerability.

Graphical Representation of Open Source Software Vulnerabilities

Scoring

First, and at the highest level, is the risk score. The Common Vulnerability Scoring System (CVSS) is an industry standard for assessing the severity of a vulnerability. Vulnerabilities in the National Vulnerability Database (NVD) have a base score that aids in calculating the severity and can be used as a factor for prioritizing remediation. The CVSS score (v2 and v3) provides an overall base score that takes both exploitability and impact into account.

One thing the Black Duck product does is provide users with a temporal score in addition to the base, exploitability, and impact scores. Temporal scores are important because they take into account metrics that change over time due to events that are external to the vulnerability. Things like remediation level—in other words, is there an official fix available? And report confidence—is the report confirmed? These are extremely helpful in tempering the overall score to an appropriate level of risk.

CWE

Common Weakness Enumeration (CWE) is a list of software or hardware weaknesses that have security ramifications. A CWE tells developers which weakness leads to the vulnerability in question. This information helps teams understand what they’re dealing with and adds one more piece to assessing the severity of the vulnerability. Teams may prioritize a SQL injection differently than a buffer overflow or denial of service.

Exploit

The existence of an exploit is a key piece to understand when wading through the sea of vulnerabilities. Understanding whether a published exploit exists can help a team prioritize highest-risk vulnerabilities first and remediate them quickly.

The existence of an exploit will raise the risk score. And the ability to quickly identify vulnerabilities that already have an exploit (and to understand the exploit) helps teams fix those critical vulns faster.

Solution or workaround

Understanding whether there is an existing solution or workaround is another key piece of information to look to once you have assessed the overall risk. If you have two medium-risk vulnerabilities without exploits available, the final determination of which to fix first might come down to whether either has a solution or workaround available.

Effective remediation through prioritization

Now that we’ve dissected some of the various ways to understand and assess the risk a vulnerability, we can start to understand how complex the prioritization of remediation efforts can be. At Synopsys, we take a different approach than other SCA vendors when it comes to prioritizing the ever-increasing number of vulnerability alerts teams receive daily.

The Black Duck SCA product is backed by a team of experienced cyber security professionals from our Cybersecurity Research Center (CyRC) who have researched thousands of vulnerabilities to understand all the attributes described above (and more!). That research is curated and funneled back into the Black Duck KnowledgeBase™ in the form of Black Duck Security Advisories (BDSAs) and made available to Black Duck customers in the product. But we don’t expect developers to dig into each and every vulnerability, consume our research, and prioritize based on their findings. We allow you to filter based on the attributes above as well as automate prioritization efforts using our policy management functionality. That way, you can set it once and then feel confident that you’re seeing the most critical issues first.

When you have hundreds or thousands of alerts to get through, it’s powerful to be able to get down to, for example, critical vulnerabilities with a risk score of 8+ that are SQL injections with a published exploit and an available solution. Suddenly, you’ve created a list of vulnerabilities based on the attributes most important to your team, so you can get to work on following the remediation guidance provided.

We understand that each team and each application are different, and no two applications should be assumed the same when it comes to calculating each one’s individual risk. That’s why Black Duck assesses vulnerabilities across many attributes and lets you harness that intelligence to reduce the noise and focus on what’s most important to you.