The features discussed in this section require IQ Server and Nexus Repository Manager with the following licenses: Repository and Firewall. |
The Audit and Quarantine features provide a way to protect your development environment from risky or undesirable components. These features use Nexus IQ policy management to identify, and if desired, prevent a proxy repository from serving unwanted components.
Before activating Audit and Quarantine, there are several items you need to complete:
In Repository Manager, you need the following privileges to use Audit and Quarantine:
Read privilege for repositories, which lets you view a results column in the Repositories tab.
For information on assigning privileges, see the Managing Privileges section in the Nexus Repository Manager book. * For IQ Server, you must be assigned to a role in the root organization with permissions to view and edit CLM Elements. The built-in roles of CLM Administrator and Owner have these permissions. For more information on assigning roles and permissions, see the Security Administration chapter. To learn more about the root organization, see the Organization and Application Management chapter.
Once these items are completed, you are ready to configure Audit and Quarantine and view audit results. Each of these actions is described below in more detail.
You configure the Audit and Quarantine features by adding them to Repository Manager as a plug-in capability.
To configure Audit and Quarantine:
Configure Settings as follows:
At this point, an audit of the selected repository is automatically started. Repository Manager contacts IQ Server and evaluates the components within the selected repository against any associated policy. The results are displayed in Repository Results, which is described in the next section.
To successfully quarantine components when the Quarantine feature is enabled, the policy used to evaluate components must be configured to fail when policy violations occur at the proxy stage in the development lifecycle. If the policy is set to warn (rather than fail), the quarantining of components will not occur. For more information about setting policy and the proxy stage, see the Basic Policy Management chapter. |
After the IQ: Audit and Quarantine capability is added, it appears on the Capabilities tab in Repository Manager as shown in the figure below.
To disable Audit and/or Quarantine:
Click the Settings tab of the IQ: Audit and Quarantine capability and set the following attributes:
Click the Enabled check box to deselect it and disable the Audit feature.
When you disable the IQ: Audit and Quarantine capability, Quarantine is also disabled. |
Click the Quarantine check box to deselect it and disable only the Quarantine feature.
When Quarantine is disabled, all quarantined components are made available for download from your proxy repository. This remains true, if you re-enable Quarantine. That is, any previously quarantined components are not quarantined again; only new components are evaluated for quarantine when you re-enable the Quarantine feature. |
To re-enable Audit and/or Quarantine:
Click the Settings tab of the IQ: Audit and Quarantine capability and set the following attributes:
Click the Quarantine check box to enable to the Quarantine feature.
Any previously quarantined components are not quarantined again even though they were quarantined in the past. Only new components are evaluated for quarantine when the Quarantine feature is re-enabled. |
The creation, modification, and deletion of repositories is managed via Repository Manager. However, when connected to IQ Server, informational details of the repositories are also available.
To view these details:
Details on repositories include:
Clicking the Delete button (shaped like a trash can) allows you to delete the repository after you confirm the deletion in a dialog.
The deletion of a repository in IQ Server will NOT be replicated to Repository Manager. |
Repositories, which appears in the sidebar of the Organization & Policy area, lets you set security for repository evaluation results. The process is the same as managing roles and permissions for organizations and applications on IQ Server. Through role assignments, you have the ability to grant users different permissions for repository evaluation results without granting them access to organizations and applications. For example, to grant a user the ability to view repository results, you assign the user to a role with View CLM Elements permission. To edit repository results, you assign the user to a role with Edit CLM Elements permission. The role assignments affect all repositories, not individual ones. For more information about assigning user roles, see Role Management in the Security Administration chapter.
Any role assignments made at the Root Organization level are inherited automatically by Repositories. However, if you set a role in Repositories, the Root Organization is unaffected. |
Once the Audit and Quarantine features are enabled, whenever you add a component to a proxy repository (or delete one), Repository Manager contacts IQ Server to evaluate the components within the proxy repository against any associated policy. The IQ Policy Violations, are summarized in Repository Manager, and detailed in IQ Server.
In Repository Manager:
The audit results are summarized in the IQ Policy Violations column of the Repositories tab as shown in the figure below.
The IQ Policy Violations column includes the following items:
In IQ Server:
The IQ Policy Violations column will also alert you if there are any errors in the audit and quarantine process. If there is an error, for example if Repository Manager cannot communicate with IQ Server, a red exclamation mark will appear to the right of the Repository Results link along with text pertinent to the error that occurred. Additional information will be available in the Repository Manager logs.
If you have permissions to add capabilities in Repository Manager, then you can also access Repository Results from the Capabilities tab:
Both methods open Repository Results on IQ Server as shown in the figure below.
Repository Results is a display of policy violations and the components that violated those policies, as well as components that don’t have violations. At the top of the view is a summary section with the following information:
Below the summary section is a list of policy violations and the components that violated those policies. By default, this information is ordered by the highest policy threat level. You can refine the list using one of the following filter categories:
You can update the audit results for the entire proxy repository by clicking the Re-evaluate Policy button in the upper right corner of the Audit View. This is useful especially after an associated policy is added or modified on IQ Server. However, it may take some time, if the repository is large. During re-evaluation any previously quarantined components remain quarantined, no matter whether they still violate policy. With quarantine enabled, if you delete a quarantined component, its quarantine status is also deleted. If you add the component back in, it is evaluated again just like any new addition to the repository. Currently the only way to remove a component from quarantine is to change the policy accordingly, then delete and add back the component. Also, whenever you add or delete a component in the proxy repository, the audit results are automatically updated for the individual component only (not the entire repository). |
When you select a component listed in Repository Results, more detailed information is provided in the Component Information Panel (CIP) section of Repository Results.
Component Info
The Component Info tab displays the following information about a specific component:
Website - If available, an information icon providing a link to the project is displayed.
The graph itself is laid out like a grid, with each vertical column representing a particular version. The selected version being identified by a vertical line. The information displayed in the graph includes:
Policy
The Policy tab displays all policies that were violated by a 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.
Licenses
The Licenses tab displays all Effective licenses, any licenses identified as declared by the author of the component, as well as any license found during the scan of the component source code. It also allows you to override the Effective license. To do this:
Labels
The Labels tab displays any component labels that have been assigned previously at the root organization level on IQ Server. Component labels are essentially metadata that is assigned to a component within the context of a particular application or organization.
Assigning a Label
When assigning a label, you will only see labels defined on the root organization.
To assign a label:
Click the Label option from the CIP menu. Two boxes are displayed:
When applying a label, you have the following options:
Vulnerabilities
The Vulnerabilities tab displays all security vulnerabilities related to a component. The list of vulnerabilities is sorted by Threat Level from higher to lower risk. The Problem Code column displays unique identifiers obtained from security information web sites such as CVE and OSVDB. The Info button provides additional information about each security vulnerability. Lastly, the Status column tracks the state of your research regarding the vulnerability.
Policy violations for components found in your repositories can be waived with a number of options for the scope and target of the waiver. As with all features, make sure to verify you have the appropriate level of access provided by the role you have been assigned.
Waiving policy violations for components in your repository is different than waiving for an application. See Section 10.9.2, “Adding a Waiver” for additional information on waiving components at that level. |
A dialog is displayed with the following settings:
Determine the scope of the waiver:
Determine the targeted component of the waiver:
Waivers will not be applied until a re-evaluation of the Repository Results has occurred. This will occur automatically if the targeted component is left to the default settings (i.e. not set to All). In cases where the selected component is set to All, a manual re-evaluation will need to occur for any results previously applying the violation. |
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