With applications containing more and more open source, and 40+ open source vulnerabilities disclosed daily, how do you prioritize your remediation efforts?
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 open source 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 open source 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?
To answer that question, let’s first try to dissect the key attributes of a vulnerability.
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.
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.
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.
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.
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.
Learn more in our webinar Effective Vulnerability Remediation Requires More than One Data Point, available on demand.