Reviewing a Report
The Application Composition Report has several different sections: a summary, a Policy Violation Table along with a Filter Sidebar, a Raw Data View, and a Vulnerabilities List view.
It’s important to first understand a little bit about what a report represents and the basic sets of data it contains. In general, each report:
- Corresponds to a single, specific application, indicating the application name, date of the report, and the stage the scan took place in.
- Includes components found during a scan of the application, in most cases, including any dependencies.
- Records violations linked to an application’s policies, or the policies inherited from the application’s organization.
- Displays available security information for any identified components.
- Displays available license information for any components found to exactly, or partially, match components known to Sonatype, as well as any data recorded manually (e.g. through the claiming process).
- Distinguishes between external, proprietary, and internally identified/claimed components.
Now that you know what forms the basis of the report, let’s take a look at each section individually.
The Summary section is displayed at the top of the main content area of the report. It consists of the report title and date as well as several displays of high-level statistics:
This display indicates the total number of policy violations (excluding low-severity violations), and the number of policy violations within each threat severity from moderate to critical. It also displays a count of the total number of components which have violations, again excluding low-severity violations.
IQ versions 64 and older featured an older version of the Application Composition Report which had a statistics visualization that was very similar to this one but which counted differently. While this visualization counts violations, the older one counted violating components.
Identified Component Count
This display indicates the total number of components along with the percentage of components which could be identified. This percentage is also reflected in the adjacent donut chart.
Grandfathered Violations Count
This display indicates the number of violations which have been grandfathered in this report.
Policy Violations Table
The Policy Violations table displays a list of all components found during the scan of the application. By default components are ordered by their worst policy violation. This is an important distinction, because a component may have more than one violation, and the threat level severity for those violations could vary. If you wish to see all violations there are two options, using the Aggregation toggle described below, or the Component Information Panel (CIP). The Policy Violations table includes the ability to sort by threat level, policy name, and component name, as well as the ability to filter via the policy name and the component name. Clicking on a row for a component displays the Component Information Panel (CIP). For more information on the CIP, see The Component Information Panel.
Dependency Type Indicators
Dependency Type indicators are displayed for Maven components:
D - Direct Dependency
T - Transitive Dependency
No indicator - Unknown (dependency info is not available)
Dependency Type is only supported for maven components. Reports created prior to January 2, 2020 will show all non-maven components as a direct dependency type. Once the application is rescanned, the non-maven components will be shown as unknown dependency types.
The dependency info comes from two sources:
- explicit dependency info provided in scans from the clm-maven-plugin
- dependency relationships between components in maven central
If clm-maven-plugin is not used, dependency info will be derived from maven central. Component not from maven central will be shown as unknown dependency types. Any identified components which are dependencies of at least one other identified component in the scan (according to maven central) will be assumed to be transitive. Those that aren't will be assumed to be direct. This means that in the case where a dependency is in reality both direct and transitive (i.e. depended on directly by the scanned app and also by one of its other dependencies), it will be marked as transitive.
Components can be filtered by dependency type using the Dependency Type filter (see Filter Sidebar below).
To the left of the Summary and Policy Violations table is a sidebar with controls for violation Aggregation and additional filters.
By default, the policy violations are presented in an "aggregated" view. This means that only the highest-threat violation for each component is displayed, and the component will only appear once in the list, while all the other violations for that component will be hidden. Another effect of this is that waived and grandfathered violations will be hidden from the view. If a component has no violations, or all of its violations are waived or grandfathered, then it is displayed in a row with a policy name of "None" and a threat level of zero. The toggle at the top of the Filter Sidebar allows the user to disable this aggregating behavior. Changing the toggle to "All Violations" will show all violations per component, potentially resulting in multiple rows per component. Waived and grandfathered violations are also displayed, with appropriate indicators to convey their waived and/or grandfathered status. Components that do not have any violations at all still appear with a threat level of zero and a policy of "None".
Note that in aggregated view, the Grandfathered and Waived indicators will be shown only if all violations for the given component are Grandfathered or Waived.
The Filters section of the sidebar contains a series of multi-select filters across different categories of data, along with a slider-based filter for the Policy Threat Level. Each filter section is expandable and collapsible. There are filters here for:
- Component Match State
- Violation State
- Not Violating
- Dependency Type
- Direct Dependencies
- Transitive Dependencies
- Policy Type
- Policy Threat Level
Note that if any Policy Type filters are selected, non-violating components will not be displayed.
The Policy Type filter may only be used on reports evaluated in IQ Server release 61 and newer. It is disabled on older reports.
Raw Data View
The Raw Data View can be accessed via the Options drop-down at the top of the Summary Section. It is a way to view the raw, lower-level data that resulted from the analysis performed by Sonatype's Hosted Data Services. The Raw Data View does not include information that is the result of policies configured within IQ.
The view consists of a table which displays all components found within the application. For components that could be identified, the component identifier (e.g. maven coordinates) is displayed. Otherwise the component's file path within the application is displayed. For identified components, Additional columns display the declared and observed software licenses, the identifier of any security vulnerability known for that component, and the CVSS score (severity) of that security vulnerability. If a component has multiple known vulnerabilities it is given multiple rows in the table, one for each. An important thing to remember about this page is that information displayed here is related specifically to license and security vulnerabilities data that has been collected by Sonatype. This data however, is separate from policy violations, which are based on policies that you have created (or imported), and which are displayed in the Policy Violations Table. That is, you could certainly have a situation where there is a security vulnerability, and no policy violation. Because of this, it is important to treat them independently.
To sort the list, simply click the corresponding header. For example, if we wanted to sort by component name, finding a component with multiple vulnerabilities, we would click on the Component column. Additionally, you can search for a specific component by typing in the search field located directly below each header.
As mentioned above, the License column displays both the declared and observed software licenses. The declared licences are displayed in bold, while the observed licences are displayed in normal-weight font. If a license is both declared and observed, it is only shown in this view as being declared, and is not duplicated in the observed section. If a license is not declared, the text "Not Declared" will be displayed. Additionally, hovering over the license information for a component will display a tooltip laying out the full list of declared and observed licenses for the component. This may be helpful if the license text is truncated due to the column size or if a closer look without the deduplication logic is needed.
The security vulnerability identifiers displayed in the Security Issue column are clickable. When clicked, they open a modal window which displays details about the vulnerability as shown below:
The Vulnerabilities List is another view that can be accessed via the Options dropdown at the top of the Summary Section. This list allows the user to get an overview of all the security vulnerabilities that triggered policy violations. It consists of a table displaying all detected security vulnerabilities on each component. The following columns are displayed: policy threat level, security vulnerability ID, vulnerability CVSS score, and component identifier. Rows are sorted in decreasing order of severity, with vulnerabilities whose policy violations are waived or grandfathered appearing at the bottom. Note that the policy threat level for waived and grandfathered violations is shown as zero. Also note that security vulnerabilities which have not triggered a policy violation are not displayed in this view.
Detailed information on a given vulnerability can be accessed by clicking the vulnerability ID, which is a link to the corresponding Vulnerability Lookup page.
The Vulnerabilities List page is designed to work well with printing and/or exporting to PDF. To obtain a PDF of the page, use the "Print to PDF" functionality built into your browser or OS. When printed/exported, the destination URL of each security issue link will be explictly displayed. This helps make it clear how to access each vulnerability's details even when the report is in a medium that doesn't support hyperlinking, such as physical paper.