Documentation Nexus IQ Server 1.20

Our documentation site has moved. For the most current version, please see http://help.sonatype.com

7.7. Understanding the Parts of a Policy

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.

7.7.1. Policy Name

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.

7.7.2. Threat Level

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.

7.7.3. Inheritance

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:

  • All - The policy is applied to every application attached to the organization.
  • Applications of the specified Application Categories in [organization] - The policy is applied only to applications that have specific application categories assigned to them. With this setting, you select which application categories to use.

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.

figs/web/server-policy-inheritance.png

Figure 7.4. Inheritance Settings


[Note]

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.

figs/web/server-policy-inheritance-repos.png

Figure 7.5. Inheritance Settings for Repositories


7.7.4. Constraints and Conditions

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:

  • Constraint Name - This is a label for the constraint. It should describe the violation you want to detect, for example, 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:

    • Any - If any one of the conditions is met, then a policy violation is triggered. It is the equivalent of placing an or between each condition. This setting tends to produce a lot of policy violations.
    • All - If every condition is met, then a policy violation is triggered. This setting is the equivalent of placing an and between each condition. It tends to produce fewer policy violations.
  • Conditions - IQ Server can detect many types of violations such as security vulnerabilities, licensing problems, quality concerns (like popularity or age), and more. To define a condition, you choose the type of condition you want from a built-in list and set any applicable parameters.

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:

  • Click the Add Constraint button to create a new constraint.
  • Click the Add Condition button to create a new condition.
  • Click the Delete button (looks like a trash can) next to a constraint name or condition to delete the setting.
  • In the Conditions section, select one of the condition types from the drop-down list. To set its parameters, you may need to make selections from a list and/or enter a value into a text box.
figs/web/clm-server-policy-constraints-and-conditions.png

Figure 7.6. Constraints and Conditions


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.

Label
Verify if a specific component label is or is not assigned to a component. For information about creating and assigning component labels, see Component Labels in the Advanced Policy Management chapter.
License
Verify if the component license is or is not a specified license. If you’ve used the Component Information Panel to set a component’s license status to Overridden, then any licenses designated as Declared or Observed are ignored. If a component’s license status has not been overridden, then any occurrence (declared or observed) of the specified license is considered a match. To learn more about licenses, see License Analysis Tab in the Application Composition Report chapter.
License Status

Verify if the status of a user-defined license is or is not one of the following values:

  • Open
  • Acknowledged
  • Overridden
  • Selected
  • Confirmed

To learn more about licenses, see License Analysis Tab in the Application Composition Report chapter.

License Threat Group
Verify if a component’s license is or is not in a license threat group.
License Threat Group Level
Verify if the threat level of a component’s license threat group is less than or equal or greater than or equal to a specified threat level value. To learn more about license threat groups, see License Threat Groups in the Advanced Policy Management chapter.
Security Vulnerability
Verify if a security vulnerability is present or absent in data sources searched by IQ Server. To learn more about security vulnerabilities, see Security Issues in the Application Composition Report chapter.
Security Vulnerability Severity
Verify if a security vulnerability with a numeric severity is =, <, , >, or >= to a specified value. For more information about security vulnerability severity, see Security Issues in the Application Composition Report chapter.
Security Vulnerability Status

Verify if a component’s security vulnerability status is or is not one of the following values:

  • Open
  • Acknowledged
  • Not Applicable
  • Confirmed

For more information about security vulnerability status, see Security Issues in the Application Composition Report chapter.

Relative Popularity (Percentage)
Verify if the relative popularity of a component’s version (as compared to other versions of the same component) is =, <, , >, or >= to a specified percentage value. For more information about a component’s popularity, see Component Information Panel in the Application Composition Report chapter.
Age
Verify if a component is older than or younger than a specified value.
Match State
Verify if the comparison of a component to known components is or is not a match in one of the following ways: Exact, Similar, or Unknown. For more information about matching components, see Matching Components in the Application Composition Report chapter.
Coordinates (GAV)
For Maven components only, verify if the GAV coordinates (Group, Artifact and Version) of a component match or do not match the specified coordinates. You can specify fixed coordinates (e.g. 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.
Proprietary
Verify if a component is or is not considered proprietary. For more information about proprietary components, see Managing Proprietary Components in the Application Composition Report chapter.
Identification Source

Verify if the identification of a component is or is not one of the following:

  • Sonatype - When the identification is done based on IQ Server data sources.
  • Manual - When the identification is done based on a component claimed by you.

For more information about the identification source see Component Identification in the Application Composition Report chapter.

7.7.5. Actions And Notifications

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.

Stage
Both actions and notifications are set to occur at a particular stage in the development lifecycle. If you have connected IQ Server with an external tool, the action can have a direct effect on the tool. For example, you can prevent a release in the repository manager. For more information on how to use actions and notifications, see Usage Suggestions for Each Stage.
Actions

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:

  • No Action - This is the default setting.
  • Warn - This generally will not break the process, and only displays violations that have occurred (e.g. in Nexus Firewall a warning during staging is displayed).
  • Fail - This generally will break the process (e.g. in Nexus Firewall the release could be prevented).
Notifications
When a new violation occurs, a notification is sent to the email addresses you provide. You can specify individual addresses or users of a particular role such as Owner or Application Evaluator.
[Tip]

When a notification is sent, it will only display new violations found in the latest evaluation. If you find yourself not receiving notifications, verify there are new violations, as well as confirm you have configured your IQ Server SMTP settings.

[Note]

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:

  1. Navigate to the policy to which you want to add actions and notifications:

    1. In the sidebar, select the organization or application in which the policy was created.
    2. In the Policy section, click the desired policy under the ‘Local’ heading. (It should have a chevron in its row to indicate that it’s editable.)
  2. In the Edit Policy view, click the ‘Actions and Notifications’ button.
  3. Click the desired stage and set the following options:

    • For an action, select either No action, Warn, or Fail.
    • For a notification:

      • Select a Notification Type. If Email, then enter an email address. If Role, then select user role from the list.
      • Click Add to save the notification.
  4. Click Update to add the actions and notifications to the policy.
figs/web/clm-server-policy-actions-notifications-example.png

Figure 7.7. Policy Actions and Notifications Example


To remove actions and notifications from an existing policy:

  1. Navigate to the policy from which you want to remove actions and notifications:

    1. In the sidebar, select the desired organization or application.
    2. In the Policy section, click the desired policy under the ‘Local’ heading. (It should have a chevron in its row to indicate that it’s editable.)
  2. In the Edit Policy view, click the ‘Actions and Notifications’ button.
  3. Click the desired stage and set the following options:

    • For an action, click No action to replace a Warn or Fail action.
    • For a notification, locate the email address or role in the list, then click the Delete button.
  4. Click Update to remove the actions and notifications from a policy.

    Usage Suggestions for Each Stage
    Proxy

    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).

      [Warning]

      Quarantined components will not be available to your development team, including any attempt to build existing projects using those components.

    • Notifications - While notifications can be configured for the Proxy stage, no notifications will be sent. If you have a Firewall license, you can view any policy violations that occur during this stage in the Repository Results.
    Develop
    While actions and notifications can be configured for this stage, they will not affect the functionality of an IDE.
    Build
    • Actions: As you manage policy, making necessary adjustments over time, it’s best to take an approach that allows for your development teams to be eased into dealing with violations. For this reason, it’s better to start by simply warning when the CI build for an application contains components that violate your policies.
    • Notifications: Consider setting up notifications to inform owners, as well as developers.
    Stage Release
    • Actions: Because this stage gives the opportunity to prevent an application from being released with components that have violated policy, setting the action for a Stage Release to Fail is recommended. This is especially true for any policies that may include risk associated with security and/or licensing.
    • Notifications: If something fails, the development process can’t move forward. Make sure to notify anyone who’s responsible for the application’s release and/or capable of researching and addressing any violations.
    Release
    • Actions: While there should be the closest scrutiny of policy violations at this point, it is recommened that you fail a release based on severe violations. Ideally in most cases, you should be finding only new violations.
    • Notifications: Similar to Stage Release, make sure to notify anyone responsible for ensuring an application does not go into production with policy violations.

      [Tip]

      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.

    Operate
    • Actions: Because the evaluation in the Operate stage is manual, a Warn or Fail action will not produce any different results.
    • Notifications: Typically the application owner, or anyone responsible for ongoing maintenance of an application in production should be notified.