A policy is the set of rules or criteria used by IQ Server to evaluate components in your applications and repositories. It is made up of the following parts:
Each of these parts is described below in more detail.
The Policy Name should be descriptive of the risk or violation you’re trying to detect. In the text box, you can enter up to 60 characters: alphanumerics, underscores (_), periods (.), dashes (-), or spaces. The name you enter is used to identify the policy in IQ Server reports and views. To avoid confusion in your system hierarchy, it is recommended that you assign a unique name to every policy; try not to repeat names of policies created in other organizations.
The Threat Level is a subjective value placed on the perceived risk of a vulnerability. Its main purpose is for sorting policy violations in IQ Server reports and views; the violations with the highest threat level appear first followed by those with lower threat levels. The Threat Level values are grouped by severity and identified by specific colors as shown in the table below:
Table 7.1. Threat Levels
High |
Red |
8-10 |
Medium |
Orange |
4-7 |
Low |
Yellow |
2-3 |
Informational |
Dark Blue |
1 |
None |
Light Blue |
0 |
When setting the Threat Level, you should avoid causing unnecessary alarm for those who review policy violations. Select the lowest possible value that’s helpful to you, such as an informational level (1) or low level (2-3). Save the high level values (8-10) for only the most critical vulnerabilities, if used at all.
The Inheritance setting is available only for organizations (including the Root organization). It allows you to specify how a policy is implemented when there are multiple applications attached to a specific organization. There are two choices:
The latter choice lets you tailor the implementation of a policy to applications with similar characteristics by using application categories. For more information on how to create and assign application categories, see Application Categories in the Advanced Policy Management chapter.
For policies at the Root Organization level, if you are a user of the Firewall solution, the All setting will include repositories as well applications. This will impact the policies used for the Audit and Quarantine features of the Nexus IQ for Repository Manager. |
Constraints define the violations you want to detect. A constraint is essentially a container for conditions, and
conditions are like the if
part of an if/then
statement. A policy must have at least one constraint, and each
constraint must have a least one condition. When IQ Server evaluates your applications and the conditions of a
constraint are met, then the policy is considered violated.
Constraints are made up of the following parts:
High risk CVSS score
or License needs legal review
.
Any or All - It determines how constraints are evaluated. You can choose one of the following options:
or
between each condition. This setting tends to produce a lot of policy violations.
and
between each condition. It tends to produce fewer policy violations.
Adding or editing a constraint is basically the same process whether you’re creating a new policy or editing an existing one. Once you navigate to the New Policy view or Edit Policy view, the following options are available for managing constraints:
Available Condition Types
Below is a list of all available condition types in IQ Server with explanations of what each condition type means and the parameters you need to set for each one.
Verify if the status of a user-defined license is or is not one of the following values:
To learn more about licenses, see License Analysis Tab in the Application Composition Report chapter.
Verify if a component’s security vulnerability status is or is not one of the following values:
For more information about security vulnerability status, see Security Issues in the Application Composition Report chapter.
org.sonatype.nexus:nexus-indexer:1.0
) or use a wildcard at the end of a coordinate (e.g.
org.sonatype*:nexus-indexer:1.*
) to broaden the search.
Verify if the identification of a component is or is not one of the following:
For more information about the identification source see Component Identification in the Application Composition Report chapter.
Policy actions and notifications allow you to take a specific action when violations occur. For example, you can notify others by sending email to individuals or all users assigned to a particular role, like Owner or Developer. You can also force a particular action in one of the tools that interact with the IQ Server.
Actions are organized by a particular stage in the development lifecycle of an application (e.g. Build).
For each stage, you can assign one of the following actions when a policy violation occurs:
Make sure you have sufficient permissions to set actions and notifications. At a minimum, you should be assigned to the Owner role for the organization or application in which the policy was created. |
To add actions and notifications to an existing policy:
Navigate to the policy to which you want to add actions and notifications:
Click the desired stage and set the following options:
For a notification:
To remove actions and notifications from an existing policy:
Navigate to the policy from which you want to remove actions and notifications:
Click the desired stage and set the following options:
Click Update to remove the actions and notifications from a policy.
Available only with the Firewall solution.
Actions - Proxy refers to "Proxy Repository", or the point where components enter your repository manager. This is also referred to as the repository integration point. For more information on how to use the repository integration point, please review the Nexus IQ for Repository Manager chapter.
When setting actions, Warn will have no effect on what happens to components in the repository. However, if you have enabled Quarantine on a repository, and set the action to Fail, any new components added to the repository will be quarantined (unavailable via the Repository Manager).
Quarantined components will not be available to your development team, including any attempt to build existing projects using those components. |
Notifications: Similar to Stage Release, make sure to notify anyone responsible for ensuring an application does not go into production with policy violations.
If you have setup policy monitoring, it is a good idea to monitor your release stage, as this is likely the best representation of your production application. |
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