While I might have made the process sound simple, there is nothing simple about it. It can be difficult to understand all the aspects of a vulnerability, and most organizations don’t have the in-house expertise or resources to do so. This is why Synopsys provides Black Duck® customers with Black Duck Security Advisories (BDSAs) about the vulnerabilities we identify in target codebases.
But just handing over a large list of components and vulnerabilities would be confusing and burdensome, so we augment it with information that has been researched, confirmed, and curated by our team of cybersecurity experts. Details such as severity scoring, descriptions, exploits, remediation guidance, reachability, and impacted versions give security teams the information needed to understand the impact of a vulnerability on an application. This is key to understanding the “so what?” of the findings, so you can best evaluate the security of the software you acquire and what it will take to bring it up to snuff.
Some of the information you get from a BDSAs in your audit report include
- Component. The name of the actual open source component. For example, Apache Log4J.
- Version. Think of the component as a vehicle model, and the version as the year. A safety recall will only affect certain versions/years. Very rarely will it impact the entire model.
- Severity. Low, medium, or high, as determined by the common vulnerability scoring standard (CVSS) explained below. This is crucial for understanding the impact of the vulnerability.
- Date published. Are there a lot of old, lingering vulnerabilities? This could signal an open source risk management issue.
- Description. A plain English description of what the vulnerability does. For example, it might open an application up to a cross-site scripting attack.
- CVSS score. The CVSS aggregates several metrics about the vulnerability, such as how easy it is for hackers to exploit and the environment it impacts, to determine severity. Audit reports break these metrics down further than base scores to paint clearer pictures of the risk.
- CWE. The common weakness enumeration (CWE) categorizes specific vulnerabilities into common types so that they can more easily be identified, evaluated, and fixed.
- Patch reference. If there is a patch, this is where it can be found. This offers a quick solution while longer-term solutions are considered.
- Suggested upgrade. The version of the component that fixes the vulnerability.
- Workaround. Upgrading might not always be an immediate option since it can have downstream impacts. Workarounds protect an application while upgrades can be planned.
These details are only a subset of what is provided by BDSAs in our open source risk analysis. Many audit and application security vendors claim to have some capability in this area, but BDSAs provide the most accurate and actionable security advisories offered.