Reviewing a Report
 |
The Application Composition Report has several 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.
Report Summary
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:
Violation Counts
 |
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.
Identified Component Count
 |
This display indicates the total number of components along with the percentage of components that could be identified. This percentage is also reflected in the adjacent donut chart.
Legacy Violations Count
 |
This display indicates the number of violations that are Legacy violations 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.
 |
Types of dependencies reported
The dependency type indicators are auto-generated in the Application Composition Report. They are represented as shown below:
| Direct Dependency | |
|---|---|---|
| Transitive Dependency | |
| InnerSource Direct Dependency | |
| InnerSource Transitive Dependency | |
No Indicator | Unknown (dependency info is not available) |
Direct dependency: An external component or package you use in your application.
Transitive dependency: An external component or package required by other components or packages in the application, to execute successfully.
InnerSource direct dependency: A component or package developed internally, for reuse within the organization.
InnerSource transitive dependency: A component or package that is a transitive dependency of an InnerSource component.
The table below indicates the sources used to obtain the dependency information.
Format | Dependency Information Sources |
|---|---|
Maven |
|
NPM |
|
How dependencies are evaluated:
Sonatype Lifecycle reports dependencies, provided the dependency definition is available in the scan targets. Currently, the dependencies are reported for components belonging to Maven and npm ecosystems. It also detects dependencies in SBOMs (for any ecosystem) if the SBOM includes the dependency graph.
Maven: Dependencies will be evaluated when you run scans using
Maven or Gradle plugin
Sonatype IQ CLI
Sonatype Lifecycle UI to scan binaries
Sonatype Lifecycle uses the dependency definitions found in the scan targets to resolve direct and transitive dependencies.
If dependency definitions are not found in scan targets (.jars), Sonatype Lifecycle uses the dependency data found in the maven-central repository for those .jars, to resolve the direct and transitive dependencies. In such cases, the direct and transitive dependency data may not match the actual dependencies of the scan target. The dependency type will be reported as unknown (no indicator on the application composition report) if the dependency data is not found in the Maven Central Repository or if the component/application does not have any dependencies associated with it.
NPM: Dependencies will be evaluated for scans that contain the package.json and package-lock.json files in the same scan target.
SBOM: Dependencies will be evaluated using the SBOM files that contain the tag/attribute "Dependencies"
Note
For maven components, if the clm-maven-plugin is not used,
Dependency data 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
At the top right of the Application Composition Report is a Filter button.
 |
Click the Filter button to filter the report by the constraints shown above.
Seeing Waived Violations
To see all violations that have been waived, turn off the Aggregate by component, click the Filter button, open the Violation State chevron, and check the box marked Waived.
Aggregate by Component
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. If a component has no violations, or all of its violations are Legacy Violations or are waived, then it is displayed in a row with a policy name of "None" and a threat level of zero. However, if a component has multiple violations and only one or some are Legacy Violations or are waived, it will still appear under its highest remaining policy violation.
Note
Note that in the unaggregated view, the Legacy or Waived indicator will appear next to violations. In the aggregated view, the Legacy and Waived indicators will be shown only if all violations for the given component are Legacy Violations or are 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 the information displayed here is related specifically to license and security vulnerability 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:
 |
Vulnerabilities List
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 Legacy Violations or are waived appearing at the bottom. Note that the policy threat level for waived and Legacy 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.
 |