Today’s release of Black Duck adds vulnerability impact analysis, which indicates whether your application executes vulnerable code. Let’s look at how this addition further augments your prioritization efforts.
Black Duck has always recognized the importance of prioritizing open source security tasks by providing several key data points to help customers focus on what’s most critical. After all, with over 40 new software vulnerabilities being uncovered every day, it’s easy to become overwhelmed. In addition to offering detailed descriptions, expanded severity scoring, exploit information, and remediation guidance, today’s release of Black Duck adds vulnerability impact analysis, which indicates whether your application executes vulnerable code. Let’s look at how this addition further augments your prioritization efforts.
A large part of determining which security flaws present the most risk is understanding how they affect your operations. Regardless of severity or remediation requirements, vulnerability impact varies across different applications. When determining how a vulnerability affects your applications, one important consideration should be whether the vulnerable code is being executed.
One of the characteristics of open source is that nothing is customized for your specific use. This makes the components more modular and reusable, but it also means that unused code is included in your applications. After all, just because you pull in an entire Java library doesn’t mean you’re going to utilize every method in it.
Understanding whether a vulnerability is in your call path is another important factor in prioritizing remediation efforts, and Black Duck now provides that information. When customers scan projects with Black Duck, in addition to detailed Black Duck Security Advisories (BDSAs), they also receive a vulnerability impact analysis.
Focusing first on Java components used most commonly by our customers, the Synopsys Cybersecurity Research Center (CyRC) indicates whether a particular vulnerability is executed by an application. Should the flaw be in the execution path, it is tagged as “reachable” and a call graph is created that reveals both the method in which the vulnerability exists and the method that calls it, down to the line number. With this information in hand, you can gain visibility into where and how a vulnerability is being executed by the application, making your prioritization efforts simple and pointing you directly to the code that needs to be addressed.
The severity of a vulnerability is an important factor in understanding the risk that it exposes your organization to. In order to keep the vulnerability determination as objective as possible, and to keep everyone speaking the same language, most organizations recognize the Common Vulnerability Scoring System (CVSS) as the industry standard.
The experts at the CyRC utilize this framework to rank the severity based on metrics like exploitability, impact, and temporal factors. The severity is often a key data point in determining which vulnerabilities demand the most attention.
In addition to providing scores consistent with multiple CVSS versions, Black Duck also allows organizations to set policies based on CVSS scores and exploitability. This enables teams to automatically fail builds that contain unpatched vulnerabilities that exceed a certain severity threshold, or that contain an existing exploit.
While not always intuitive, this question shouldn’t be saved until work has started fixing a vulnerability. Consider t-shirt sizing a project. First you must understand the work required to complete a task before being able to properly budget the time and effort required. Without detailed information regarding how to find and fix a vulnerability, your team is going to spend countless hours researching it. And this can easily take resources away from fixing an equally severe vulnerability that required a fraction of the development effort.
Every BDSA comes with a detailed vulnerability description as well as actionable remediation advice. This includes suggested minor and major upgrade chains, patches, and even workarounds since upgrades are not always the best short-term solution. Given this level of detail, your team can pair the BDSA information with severity metrics to confidently decide when vulnerabilities need to be addressed.
Prioritizing open source vulnerabilities is no easy task, especially considering the multiple pieces of information needed from numerous sources. Black Duck finds all that information for you; qualifies, augments, and combines it; and delivers it to you in the form of a BDSA. With the addition of vulnerability impact analysis, your prioritization efforts become more informed, and they will continue to improve as Black Duck enhances its prioritization feature set in every release.
Mike McGuire is a senior software solutions manager at Synopsys where he has spent several years leading go-to-market efforts for open source risk and software supply chain security solutions. After beginning his career as a software engineer, Mike transitioned into product management and strategy roles, as he enjoyed interfacing with the buyers and users of the products he worked on. Leveraging several years of development experience, Mike enjoys connecting the market’s complex AppSec problems with Synopsys’ comprehensive solutions.