About security risk

Black Duck helps security and development teams identify security risks across their applications.

By mapping vulnerabilities to your open source software, Black Duck can provide you with high-level overview information on security risk of your projects, along with detailed information on security vulnerabilities which you can use to investigate and remediate your security vulnerabilities.

Vulnerabilities are linked to the open source components by the Common Vulnerabilities and Exposures numbers (CVEs), as reported in the National Vulnerabilities Database (NVD) maintained by the National Institutes of Standards and Technology (NIST) and/or by (BDSA) numbers If you have licensed Black Duck Security Advisories. Note that Black Duck displays the numbers together in reports and in the UI because they represent the same vulnerability from different sources.

Security risk levels

NVD and BDSA use the Common Vulnerability Scoring System (CVSS) which provides a numerical score reflecting the severity of a vulnerability. The numerical score is then translated into a risk level to help you assess and prioritize security vulnerabilities.

Black Duck provides you with the option of viewing CVSS v2 or CVSS v3.x scores. By default, Black Duck displays CVSS v3.x scores.

  • CVSS v2 scores have the following values:

    • Low risk: 0.0 - 3.9

    • Medium risk: 4.0 - 6.9

    • High risk: 7.0-10.0

    Note that Black Duck shows vulnerabilities with a 0.0 score as no risk.

    Although CVSS v2 does not have a Critical risk category, the security graphs In the Black Duck UI display a Critical risk category. This category will display a value of 0 for CVSS v2.

  • CVSS v3.x scores have the following values:

    • None: 0.0

    • Low risk: 0.1 - 3.9

    • Medium risk: 4.0 - 6.9

    • High risk: 7.0 - 8.9

    • Critical risk: 9.0 - 10.0

    Note that the scores shown for CVSS v3.x can be v3.0 or v3.1 scores.

Estimated Security Risk

This estimated risk statistic is formulated by looking at all the versions of a component sorted by security vulnerability severity category and calculating the maximum vulnerability count for each severity category for each component version. The maximum vulnerability count for each severity category is shown in the “Estimated Security Risk by Severity Category" on the Bill of Material for Security risk. The highest severity category counts may reference different component versions. For example:

  • Version 1.1 has 2 Critical, 3 High, 15 Medium, 4 Low

  • Version 1.2 has 2 Critical, 4 High, 12 Medium, 1 Low

  • Estimated Security Risk by severity category for components with unknown versions would return as 2 Critical, 4 High, 15 Medium, 4 Low on the BoM.

Users should choose the exact version used in the application to view the accurate risk instead of the estimated risk. This estimated risk information is provided to help prioritize what components to review first. Users are encouraged to use estimated risk information in conjunction with BD Policy Management to further prioritize what components to triage first based on their company’s security policies.

Note: The information presented is only a statistical data estimation. As a result, the estimated security risks will not have CVE data.

Suggested work flow

To manage security risk using Black Duck:

  1. With the assistance of your security team, determine your security risk policies.

  2. If necessary, users with the system administrator role can define the default security ranking.

    Note that the security ranking also defines how vulnerabilities appear in reports. Depending on the data available, the vulnerability will be presented as either: BDSA (NVD) or NVD (BDSA). For example, if the security ranking is NVD2, BDSA2, BDSA3, NVD3 then:

    • Vulnerability A has data for just NVD3. The vulnerability is listed as NVD-1234-5678 in the report.

    • Vulnerability B has data for NVD3 and BDSA3. The report lists it as BDSA (NVD).

    • Vulnerability C has data for everything. The report lists it as NVD (BDSA).

  3. Create policies that trigger violations when components do not comply with your security policies.

  4. Depending on your interests:

    • Use the Summary Dashboard to view the overall health of your projects and identify areas of concern. Use this page to quickly assess areas where you need to focus your attention.

    • Use these Dashboard pages for a high-level overview of risk:
    • Use these pages for project version-level information:
  5. Investigate vulnerabilities and policy violations. For detailed information on security vulnerabilities, view the:

  6. After reviewing the severity of the vulnerability, users with the appropriate role can change the remediation status of the security vulnerability.

  7. Monitor notifications for any new security vulnerabilities.

    You will receive notification alerts if security vulnerabilities are published or updated against components that are included in one or more of your projects.