Component Information Panel
Clicking on a specific component within the Policy Violations table opens the Component Information Panel (CIP). The CIP is divided into two areas. The top has a series of tabs for various sections, each providing more specific details and functionality related to the component. Below these tabs, the panel will display the corresponding information. A brief description of each section is included below. At the bottom of the CIP, navigation buttons to switch to the next and previous components in the Policy Violations Table can be found.
Any changes done in the Component Information Panel are visible only when the application is re-analyzed (via the re-evaluation button or a new evaluation being triggered from CI, CLI, policy monitoring, etc).
For ecosystems that include support for Dependency Types, the title of the CIP now includes a tag to indicate the dependency type of the component.
InnerSource Direct dependency
Transitive dependency brought in by an InnerSource
Our color-coding is changing over to a color palette that's easy to identify at a glance and better on most monitors. Upgrade to the latest version of IQ Server to see the new palette when it's ready.
This tab contains a version graph for viewing available versions of the selected component, information on the selected component and version, and also recommended versions for any components that have policy violations for the application.
The recommended version is based on the availability of a newer version of the same component that does not violate any configured policies for the application. If such a version exists a hyperlink is displayed with the suggested version. Clicking on the link will select the recommended version in the version graph and populate the table with information about this version.
In addition to non violating version, "Next version with no build failure violations" can be recommended if exists. None of the violations caused by this recommended version would fail the build for a given stage.
The version graph is laid out like a grid, with each vertical slice representing a particular version. The current version is identified by a vertical line with its popularity in a dark grey color. Previous versions are shown in light grey, and newer releases with a different major version show popularities in blue. Newer versions with the same major version as the current version show popularities in green. The information displayed in the graph includes:
|Popularity||The popularity for each version is shown as a bar graph. The taller the bar, the more popular the version.|
Indicates whether the specified version is likely to contain breaking changes.
|Policy Threat||The heatmap marker colors represent the highest policy threat levels for each version across all policy types, with no marker indicating no threat.|
The following table outlines the details provided for a chosen component in the Component Info tab:
|Declared License||Any license that has been declared by the author.|
|Observed License||Any license(s) found during the scan of the component’s source code.|
|Effective License||Either any licenses included in the Declared or Observed Group, or the overridden license.|
|Coordinates||The identifying information for a component. For known components, all available coordinate information will be displayed.|
|Highest Policy Threat||The highest threat level policy that has been violated, as well as the total number of violations. The value may be NA if all threats have been waived.|
|Highest CVSS Score||The highest threat level security vulnerability and the total number of security vulnerabilities. The value may be NA if all threats have been waived.|
The level of suspiciousness (Suspicious, Normal) of this version as determined by our machine-learning intelligence. Versions that are marked suspicious may be malicious. The value may be Not Applicable if no integrity data is applicable.
The quality (Laggard, Exemplar, None) of an open-source project. This is calculated based on the projects that exhibit the best and worst behaviors to producing quality open-source software. The hygiene rating is explained in more detail here.
|Cataloged||The age of the component based on when it was first added into the source from which it was identified.|
|Match State||How the component was matched (exact, similar, or unknown).|
|Identification Source||Whether a component is identified by Sonatype, or claimed during your own process.|
|Category||What the component is used for, as categorized by Sonatype. Possible values include designations like "Data Protocols," "Logging," "Networking Utilities," etc. This is the same Category that can be used to set a policy's Constraint.|
|Website||If available, an information icon providing a link to the project is displayed.|
The Policy tab shows details of any policy violations for the component. Here you can see the name of the policy that has been violated (and any action that was taken), the name of the constraint that has been violated, and the value that was found. While the Policy/Action and Constraint names are straight forward, the Condition Value may be a little confusing at first.
A condition is simply the if part of an if/then statement. If a certain condition value is found which is equivalent to a condition being met, then the policy will be violated. E.g. if we have a policy that has a condition such that if a security vulnerability is found, our Condition Value column would indicate, Found x Security Vulnerabilities. In the same regard, Constraints are simply multiple conditions joined together.
In addition to simply viewing the policy information details, a policy violation can also be waived in this section of the CIP using the Waive button.
Any components found to be similar to the selected component will be listed in the Similar tab. For example, a similar component could be a component that a developer has built locally using the source code of an open source component with minor modifications or additions.
When a file is scanned, it has a filename and location where it was found. In some cases, it may have more than one filename and location. Either way, the paths to the location(s), as well as the filename(s), of the component that was scanned are included in this section. In short, the Occurrences section lists the file names and locations where the component was encountered. This section can be especially useful to detect accidental shipping of duplicate component archives or a misconfiguration of your actual report creation target e.g. you might be scanning the deployment archive (e.g. a war file) as well as the build output folder used to create the archive.
The Licenses section is split into two areas. On the left, any licenses that were identified as declared by the author of the component, as well as any licenses found during the scan of the component source code are listed. On the right is the license status area where you can set the Status of the component license information. See Component License Information for a more in-depth description of licensing.
The Vulnerabilities tab is separated into two areas. On the left, all security vulnerabilities related to the component are displayed. Clicking the "i" info button on any of the vulnerability rows will show more details. On the right is the security vulnerability status area. See Resolving Security Issues for more information on using this tab.
The Labels tab allows you to assign and manage labels to the component. Learn more about labels in IQ Server here.
IQ Server labels components as "Component-Unknown" if it can't match the component to its database of extant components, or if can only find similar but not identical components. We recognize that, in many cases, you'll know what these components are. We provide this section so that you can manually identify these components by specifying their component identifier.
When changes are made to the status of a security vulnerability, or the status of a component’s license within the scope of a particular application, that information is recorded in the Audit Log tab of the CIP for that component.
Typically, resolving Policy violations with status changes is more risky than using Waivers because status changes are more difficult to track. When possible, use Waivers to accept the risk of a Policy violation.