One of the most important things you can do with regards to understanding the components in your application, is to identify them. What remains unidentified is of obvious concern.
Components can be identified in a number of ways, including:
In this section, we’ll describe all of these in detail, within the context of identifying components using the Application Composition Report, as well as offer our suggestion for best practices.
When an evaluation is performed, hashes of the components in your application are created. This in many ways is like a fingerprint, which is unique to a component. That fingerprint (hash), is compared back to components known to the IQ Server, which will provide all the available component info. This includes: usage statistics, security vulnerability, and license information.
All of this information can be used as parameters in your policy, which translates to more understanding of the component usage in your organization. That data however, can only be linked based on a matching of hashes, which can be exact or similar, and in some cases, unknown. We discuss these three match types below.
However, there is a chance that component is something malicious introduced into the application. Either way, an unknown component should prompt an investigation. Of course, if during your investigation, you are able to identify the component, you can claim that component, via the Claim Components section, which we will walk you through in more detail a little bit later. An example is displayed in Figure 12.30, “Unknown Component”.
Unknown components will not be displayed in the License tab until they have been claimed. |
In addition to the main filters above, you can also control whether all violations for each component will be displayed. By default the summary of violations is shown. This means that only the worst violation for a component will be shown, and the component will only appear once in the list. Choosing All or Waived, will show all violations (including those waived), or only the waived violations, respectively.
Changing the Violations filter can result in the components being displayed in the component list more than once. |
Proprietary components are unique to your organization. In many cases, these are developed by your organization and distributed among the applications you create.
In the Application Composition Report, you can view proprietary components on the Policy Violations tab as shown below. While Proprietary is listed under Filter, the process for matching exact, similar, and unknown components is separate from identifying a component as proprietary. You can have proprietary components that are an exact match, similar match, or unknown match. If you’re trying to determine which of your components are proprietary, a good place to start is to review unknown components.
IQ Server uses proprietary component matchers to identify proprietary components when applications are evaluated. Proprietary component matchers are configured in the Organization & Policies area, but you can also add them from within the Application Composition Report. This is especially useful when the report contains unknown components that you know are proprietary.
You need to be assigned to a role with "Edit Proprietary Components" permission in order to add proprietary component matchers. The built-in Policy Administrator and Owner roles have this permission. |
To add proprietary component matchers:
Existing reports are unaffected by additions to the Proprietary Component Matchers list; only after the next evaluation will you see the newly added components identified as proprietary. |
For more information about the Proprietary Component Matchers, see Proprietary Component Configuration in the Basic Policy Management chapter.
When a component is similar or unknown, yet you are certain the component is recognized by your organization, you can prevent that component from being identified as similar or unknown in future reports. In other words, you can claim the component as your own.
Once claimed, that component will be known to the IQ Server. It will no longer be treated it as similar or unknown, and instead result in an exact match.
On review of the existing report, as well as those in the future, there is now an indicator that information about the component has been edited. When hovered over, a tooltip is displayed identifying that the component has been claimed.
We refer to this as the edited component tick mark (a small red triangle) on all future scans for this application, as well as any application with a valid Application ID on the IQ Server.
In addition, the Component Info section for the claimed component will now have two new fields, one indicating the Identification Source is Manual, and the other, Identification Comment will include any comments that were entered. While any policy violations will be displayed, the component graph will not.
Finally, if you have made a mistake and wish to revoke the claim on the component or make an edit, click on the Claim Component tab. Then, use the Revoke or Update buttons respectively.
Use the cancel button to undo any changes you made but haven’t saved. |
Terms of Service Privacy Policy
Copyright ©
2008-present, Sonatype Inc. All rights reserved. Includes the
third-party code listed here. Sonatype and Sonatype Nexus are trademarks
of Sonatype, Inc. Apache Maven and Maven are trademarks of the Apache
Software Foundation. M2Eclipse is a trademark of the Eclipse Foundation.
All other trademarks are the property of their respective owners.
Sonatype Headquarters - 8161
Maple Lawn Blvd #250, Fulton, MD 20759
Tysons Office - 8251 Greensboro Drive #610, McLean, VA
22102
Australia Office - 5 Martin Place, Level 14, Sydney 2000, NSW, Australia