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 that 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 that 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 Details Page. 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 Details Page.
For the Maven and npm ecosystems, dependency type indicators are automatically generated.
InnerSource Direct Dependency
|InnerSource Transitive Dependency|
|No Indicator||Unknown (dependency info is not available)|
The dependency information comes from different sources:
|Format||Dependency Information Sources|
For maven components, if the clm-maven-plugin is not used,
- Dependency information will only be derived by looking at their dependency relationships in maven-central.
- If the component does not originate from maven-central, then its dependency type will be unknown.
- 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 and those that aren't will be assumed to be direct. In this case, a maven dependency that is both direct and transitive (i.e. depended on directly by the scanned application and also by one of its other dependencies), will be marked as transitive.
Filter Sidebar and Aggregation
At the top right of the Application Composition Report are a Filter button and a switch to Aggregate by component.
Click the Filter button to filter the report by the constraints shown above.
By default, the policy violations are presented in an "aggregated" view. Click the switch to turn this behavior off.
When aggregated, components only appear on the list once under their highest policy violation. Waived and grandfathered violations will also be hidden. 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. Clicking on a component still brings up a Component Details Page that includes all violation associated with the component.
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.
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 that 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 licenses are displayed in bold, while the observed licenses are displayed in a 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 that 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.