Working with Vulnerability Data

Where do I Find Vulnerability Information?

From the Updated Policy Report

The vulnerability data is available from the IQ Server Application Composition Report.

Component Details Page

In the Application Composition Report, select the violation that you are investigating to open the Component Details Page. Within the Component Details Page, select the Policy Violations tab to view the list of violations for this component:

Image of the Policy Violations tab on the Component Details page

Click on a security policy violation to open the Violation Details tile, then scroll down to access the violation details.

NEW IN RELEASE 152

The label Deep Dive indicates that this vulnerability data includes details and recommendations from the Sonatype Research Team.

The label Advanced Vulnerability Detection indicates that this vulnerability has been detected in entire files and embedded dependencies, typically beyond the public feeds.

Vulnerabilities List

In addition to the Component Details Page, you can also view vulnerability information by accessing the Vulnerability List. From the Application Composition report, go to the Options menu and select View Vulnerabilities.

This list gives you an overview of all security vulnerabilities that triggered policy violations. The table shows all detected security vulnerabilities on each component. Vulnerabilities are sorted in decreasing order of severity, with waived or grandfathered violations appearing at the bottom. Note that the policy threat level for waived and grandfathered violations is shown as zero and that security vulnerabilities that haven’t triggered a policy violation are not displayed in this view.

Vulnerability Lookup

From the Vulnerabilities list, you can access detailed information on a given vulnerability by clicking the Vuln ID. This takes you to the corresponding Vulnerability Lookup page.

The Vulnerability Lookup page can also be accessed by selecting Vulnerability Lookup from the IQ Server toolbar:

From the Legacy Report

Sonatype-enriched vulnerability data is available from the IQ Server Application Composition Report. Select the Security Issues tab and then select the problem code you’re investigating:

Then view the detailed Vulnerability Information:

You can also access this information from the Vulnerabilities tab of the Component Information Panel.

Why is a vulnerability not found on the Violation Details page?

This happens when the vulnerability that triggered a policy violation previously, has been deleted by our research team.

At Sonatype, we strive for continuous improvement in our vulnerability detection system by maintaining high data quality. As part of continuous data refresh, in addition to new vulnerabilities, we re-evaluate older vulnerability data to determine its security implications in an evolving threat landscape and remove if non-relevant. This reduces false positives and eliminates unnecessary blockers in the development process.

As a result, you may notice that policy reports now have fewer security violations, or some links do not return the same vulnerability data as before.

What are the most common causes?

  1. The vulnerability does not exist anymore.
  2. It is a duplicate vulnerability.
  3. The vulnerability which was previously discovered on a fast-track process queue by our vulnerability detection systems has been transitioned to a deep-dive process queue by our research team. Deep Dive vulnerabilities will show accurate version ranges for the affected components accompanied by detailed recommendations.

Self-help Troubleshooting

  1. Run a new application scan from CLI or Jenkins or any other Sonatype-supported continuous integration server you use. You can also run an application scan by clicking on "Evaluate a File."



    This will generate a new bill of materials and the latest vulnerability data. The violation will not appear on the Violations Reports page.

  2. Alternatively, you can waive the violation to clear it in the current report.
    Have more questions on a specific vulnerability? Please consult https://support.sonatype.com/home or contact support at support@sonatype.com.

How do I Use Vulnerability Data?

The important thing to remember is that evaluating your application and seeing security vulnerabilities should create motivation for further investigation.

For example, if it’s recommended to do a component upgrade, use the Component Details Page to identify a recommended non-vulnerable and popular version:

If the new version has the same API as the previous component, simply run unit and integration tests and make sure everything passes to successfully remediate the policy violation.

NEW IN RELEASE 161 Customizing Vulnerability Attributes

This feature is designed to be used by security advisors or security professionals to augment the vulnerability data provided by Sonatype products. This functionality allows users to customize the details and attributes of a vulnerability to better match their environments and aid developers in remediation and prioritization.

In this section:

Customizable Vulnerability Attributes

Customizable Vulnerability AttributesBenefits
CWE-ID

The CWE-ID is a community-developed list of software and hardware weakness types. The CWE classification and taxonomy serves as a common baseline for weakness identification and remediation efforts across developer and security practitioner communities.

You can customize the CWE-IDs to better reflect the weakness identification and remediation efforts specifically for your development environment. The new custom CWE-ID can then be used by policy constraints to enforce remediation or development practices.

CVSS Vector String

The CVSS vector string is a combination of base metrics (reflect the exploitability, impact and scope of the vulnerability,) environmental metrics (reflect the confidentiality,) integrity and availability of information systems and temporal metrics (reflect the exploit code maturity, remediation level, and report confidence.)

You can customize the CVSS vector string by modifying the temporal metrics or environmental metrics to match the specific impact and requirements of your infrastructure. Alternatively, if you disagree with certain base metrics that our researchers have chosen in the base score, you can override that with your own research or conclusions.

SeverityYou are can modify the severity score of the vulnerability. Ideally, this should be used in conjunction with changes the vector strings temporal or environmental metrics.
Custom RemediationYou can customize the remediation message so that it can be used to provide additional instructions to developers. It can also describe or  document additional research that has been done on a vulnerability.

Use Cases & Scenarios to Customize Vulnerability Attributes

Customizing the CWE-ID

By customizing the CWE-ID you can have greater control over policy enforcement. For instance, if you have a policy requiring all data query logic to be sanitized (policy constraint on CWE-ID 943) and you have developers using org.hibernate : hibernate-core : 5.4.20.Final which is vulnerable to CVE-2020-25638, you can edit the CWE-ID to also include CWE-ID 943 expanding the default category of CWE-ID 89. Conversely, you could also narrow the category of a hibernate SQL injection weakness and use CWE-ID 564 if you wanted to have policy specifically around vulnerabilities of that category.

Customizing the CVSS Vector String and Severity

We have added the ability to add custom CVSS Vector String and Severity. Customizing this data is useful when you want to add temporal or environmental metrics to the CVSS vector string. For instance, if your developers are using a component vulnerable to CVE-2022-22965, and you have evidence that a proof of concept exploit exists but also know there is an official fix, you can modify the CVSS vector string from AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H to AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:P/RL:O/RC:C to reflect this data. Then the severity could be adjusted from 9.8 to 8.8 to reflect the temporal information. And, you can add a new policy with a constraint on the temporal metric representing the "official fix", "RL:O", to require developers patch any vulnerability with an official fix.

Customizing the Custom Remediation

The custom remediation text box can be utilized to provide additional guidance to developers or to detail research that has been done on a vulnerability. For example, if your developers are using org.apache.tomcat : tomcat-catalina : 10.0.0-M3 they are susceptible to CVE-2021-24122. However, that vulnerability is only accessible if the application is serving resources from a Windows NTFS file system. As part of your custom remediation, you can instruct developers to check with an authorized individual who can validate that they are using the component on a non-Windows NTFS file systems before granting a waiver.

Similarly, the text box can be used to provide proof of research or mitigation. For instance, if your developers are using com.fasterxml.jackson.core : jackson-databind : 2.10.0 it is susceptible to CVE-2020-9548 if developers are still using the deprecated default typing methods from 2.9.x. Within the custom remediation box the developer can now show how they migrated from version 2.9.x to 2.10.0 and that they are no longer calling the deprecated methods. This can be done by providing links to a Jira ticket or even links to code commits in SCM. When providing this level of detail it is recommended that changes be scoped to the application, as these details would have to be provided on a per-application basis.

Scopes and Application Category

You can customize vulnerability attributes at any scope (ROOT, Organization, or Application) or across an application category. When adding environmental metrics to a CVSS vector string, we recommend applying those changes either on an  application category (e.g. air-gapped applications might require "MAV:P" metric) , or application scope. Conversely, temporal metrics can be applied to all scopes so ROOT would be the most common choice. Confirm the applicable scope of the of your changes before saving the customized vulnerability attributes.

Steps to Customize Vulnerability Attributes 

This feature is available to users with Edit IQ Elements permission.

1. Click on the "Customize" button to start customizing the vulnerability details. The "Custom" indicator for the vulnerability attributes in the left panel indicates whether that attribute has been customized previously.

2. A "Edit <Vulnerability Attribute>" button on the right top section for each vulnerability attribute appears. Click on the edit button for the vulnerability attribute you want to customize.

3. Click on the "Edit Remediation Message" to customize the remediation for this vulnerability.

Enter the customized remediation message. Select the appropriate scope, i.e. root, organization or application from the dropdown. Select the application category to which this customization will be applicable. Click "Save" to complete customization of the remediation message.

4. Click on "Customize CWE ID" to customize the vulnerability attribute CWE ID.

Enter the custom CWE ID. Select the appropriate scope, i.e. root, organization or application from the dropdown. Enter the "Audit Comments" to explain the reason for customizing this vulnerability attribute. Audit comments will appear in the audit log for traceability and accountability. Click "Save" to complete customization.

5. Click on "Customize CVSS String " to customize the CVSS strings and severity for this vulnerability.

Enter the custom CVSS vector string. Select the appropriate scope, i.e. root, organization or application from the dropdown. Enter the "Audit Comments" to explain the reason for customizing this vulnerability attribute. Audit comments will appear in the audit log for traceability and accountability. Click "Save" to complete customization.

6. Click on "Customize CVSS Severity" to customize the CVSS severity for this vulnerability.

Enter the custom CVSS severity. Select the appropriate scope, i.e. root, organization or application from the dropdown. Enter the "Audit Comments" to explain the reason for customizing this vulnerability attribute. Audit comments will appear in the audit log for traceability and accountability. Click "Save" to complete customization.