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. Policies are made up of Summary, Inheritance, Constraints, Actions, and Notifications.

1. Summary

The summary section lets you define the Policy Name and Threat Level.

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.

Threat Level

The Threat Level is a subjective value placed on the perceived risk of a policy violation. 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:

InformationalDark Blue1
NoneLight Blue0

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 violations, if used at all.

2. 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 Applications in [organization] - 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.

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 IQ for Nexus Repository Manager.

3. Constraints

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 at least one condition.

If the conditions within a constraint are satisfied, then the containing constraint is satisfied. Multiple constraints inside a policy are combined with OR - therefore a policy is violated if any one constraint in that policy is violated.

Constraints are made up of the following parts:

Constraint NameThis 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.
ConditionsIQ 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. See the section below for details on setting conditions.

Constraints and Conditions 

Setting Conditions

Select a value for “Any or All" and then a condition and its parameters from the drop down menus. For more details on any of the conditions and their parameters, please see Application Composition Report.

When setting conditions, you will also want to consider Policy Type (one of the available filters for the Dashboard). Based on the condition that is chosen, a policy type will be assigned. This is done automatically and can't be overridden. The following rules are used to determine a policy’s type:

  • Security if it has any security conditions, it is considered a Security policy.
  • License if it has any license conditions, it is considered a License policy.
  • Quality if it has any age or popularity conditions, it is considered a Quality policy.
  • Other if none of its conditions are of types mentioned above, it is considered to be of type Other.

NOTE: A policy can only ever be of one type. In cases where a policy has conditions that meet more than one of the rules above, the order above dictates the type of policy. For example, if a policy has security and license conditions, it is considered to be of type Security.

Any or All---

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.
LabelOtherVerify if a specific component label is or is not assigned to a component.
LicenseLicenseVerify 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.
License StatusLicense

Verify if the status of a user-defined license is or is not one of the following values: Open, Acknowledged, Overridden, Selected, Confirmed.

License Threat GroupLicenseVerify if a component’s license is or is not in a license threat group. The special value [unassigned] can be used to check whether a license has not been assigned to any of your license threat groups, i.e. represents an unknown risk.
License Threat Group LevelLicenseVerify 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.
Security VulnerabilitySecurityVerify if a security vulnerability is present or absent in data sources searched by IQ Server.
Security Vulnerability SeveritySecurityVerify if a security vulnerability with a numeric severity is =, <, ⇐, >, or >= to a specified value.

If a vulnerability identifier is prefixed with SONATYPE or CVE, then the vulnerability severity is its Common Vulnerability Scoring System (CVSS) version 3 score.

In a case that a version 3 score is not available, the severity compared will be to the CVSS version 2 score.

Security Vulnerability StatusSecurity

Verify if a component’s security vulnerability status is or is not one of the following values: Open, Acknowledged, Not Applicable, Confirmed.

Relative Popularity (Percentage)QualityVerify 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.
AgeQualityVerify if a component is older than or younger than a specified value.
Match StateOtherVerify 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.

Verify if a component matches or does not match Maven, A-Name or PyPI coordinates. For each type of coordinates, you enter specific attributes. You can use a wildcard (*) at the end of an attribute to broaden the search.

Maven: You fill in a component’s GAVEC, i.e. Group ID, Artifact ID, Version, Extension, and a Classifier. For example:

Group ID: org.sonatype.nexus
Artifact ID: nexus-indexer
Version: 1.0
Extension: jar
Classifier: sources
Group ID: org.sonatype*
Artifact ID: nexus-indexer
Version: 1.*
Extension: *

A-Name: A-Name is short for Authoritative Name, an identifier created by Sonatype to identify components agnostic of the repository format. You fill in a Name, Qualifier, and Version, for example:

Name: log4net
Qualifier: Framework 3.5
Version: 2.0.5
Name: log4net
Version: 1.*

PyPI : The Python Package Index format. You fill in a Name, Version, Qualifier, and Extension. For example:

Name: MarkupSafe
Version: 1.1.0
Extension: *
Package URL 

Verify if a component matches or does not match a specified package URL. You can use a wildcard (*) at the end of an optional attribute to broaden the search. The package URL must have the format below:



  • type: the package "type" or package "protocol" such as maven, npm, etc. Required
  • namespace: some name prefix such as a Maven groupid (optional and type specific). Optional
  • name: name of the package. Required
  • version: version of the package. Optional
  • qualifiers: extra qualifying data for a package such as type, classifier for maven (optional and type specific). Optional

Package URL examples




ProprietaryOtherVerify if a component is or is not considered proprietary.

Proprietary Name Conflict NEW IN RELEASE 106 FIREWALL


Determine whether a component from a proxy repository has a name that matches the name of any proprietary component in a hosted.

Note that this policy condition is only relevant to Nexus Firewall and the Proxy stage.

Identification SourceOther

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.
    • Clair - When the identification is done based on a Clair scan result.
    • Package Manifest - When the identification is done based on any manifest file scan.
    • Sonatype IaC - When the identification source is done based on the IaC Pack scan results. 

Component Category NEW IN RELEASE 85

OtherVerify if the component category is or is not a specified category.  If you've used the Component Information Panel, the Category is specified there.  If a parent category is selected, a match will occur on any child category as well.

Data Source NEW IN RELEASE 91


Verify whether or not the data source where the component information was found has support for one of the following features: Identity or Licence

Dependency Type NEW IN RELEASE 96


Verify if the dependency type is or is not the following:

  • Direct - When the dependency is determined to be defined in the application/project
  • Transitive - When the dependency is brought in from another dependency
  • InnerSource - When the dependency is determined as internally developed module

For more information see dependency type section in Reviewing a Report

NOTE: Policy is not evaluated on components with dependency type of unknown.

Security Vulnerability Category NEW IN RELEASE 97

SecurityVerify if the security vulnerability category is or is not a specified category.  If you've used the Component Information Panel, the vulnerability category values can be seen when viewing vulnerability information.

Hygiene Rating



QualityVerify if the Hygiene Rating of a component is or is not one of the following: Laggard, Exemplar.

Integrity Rating



QualityVerify if the Integrity Rating of a component is or is not one of the following: Normal, Suspicious.

Note: Unknown components can only ever meet the "Match State", "Proprietary" and "Data Source" conditions. All other conditions will never be satisfied by an unknown component, regardless of which operator or value the condition employs. For example, an unknown component has no defined relative popularity, not even 0, so even a condition like "Relative Popularity >= 0" would not be met by an unknown component. Likewise, an unknown component has no specific coordinates, and consequently, not even a condition like "Coordinates do not match ..." would be satisfied by it.

4. Actions

Policy actions allow you to designate an action to take when violations occur at a particular stage in the development lifecycle. For each stage, you can assign one of the following actions:

  • No Action - This is the default setting.
  • Warn - Policy violations are worthy of a warning.
  • Fail - Policy violations are severe enough to potentially halt the development lifecycle.

If you connected IQ Server with an external tool, the action can have a direct effect on the tool. When an external tool requests a policy evaluation (of an application, repository or component), IQ Server provides policy violation information along with the action, which the tool may (or may not) implement. For example, if you set the Build stage to Fail in a policy, a CI tool (such as Bamboo, Jenkins, or Hudson) may stop the build of an application when that policy is violated. Similarly, in a different tool, if you set a stage to Warn, a warning message may be displayed or logged in a file when policy violations occur. For more details on using actions, see Usage Suggestions for Each Stage.

To add actions to a policy:

  1. In the Organization & Policy area, create a new policy or open an existing one for an organization or application.
  2. In the Policy editor, click the Actions button to scroll to the Actions section.
  3. Click the desired action — No Action, Warn, or Fail  at specific stage(s).
  4. Click Update (or Create) to save the policy.

Usage Suggestions for Each Stage

Sonatype provides various tools and plugins to enable policy evaluation during each stage of development lifecycle:

  • CLI
  • Maven plugin
  • Nexus Firewall
  • IDE plugins
  • CI plugins
StageUsage Suggestion

Available only with the Nexus Firewall solution. 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, see the IQ for Nexus Repository Manager topic.

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.


The ‘develop’ stage is intended for policy evaluation snapshots where changes to application dependencies and any associated policy violations are not tracked linearly. While actions and notifications can be configured for this stage, they will not affect the functionality of an IDE.

Evaluations made with the Develop stage do not show up in the dashboard or the reporting view.



This stage is intended for scans that target the contents of the source control repository itself.  All scans for the configured default branch that Nexus IQ itself initiates will use this stage.  It is recommended that externally initiated scans, from a CI environment for example, should likewise only target the contents of the source code repository or a subset thereof when using this stage.
BuildThis stage is typically used with the CI plugins. As you manage policies, 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.
Stage ReleaseCan be used with Nexus IQ Server plugins, typically as part of the SDLC pipeline as you deploy of publish applications for testing. This stage gives the opportunity to prevent an application from being promoted through the SDLC with components that have violated policies, setting the action for a Stage Release to WARN is recommended, further encouraging or allowing developers to remediate violations without impacting the project schedule.

Can be used with Nexus IQ Server plugins; typically this stage represents the posting of the application into a READY for RELEASE state, i.e. it has been fully tested and approve for customer consumption. While there should be the closest scrutiny of policy violations at this point, it is recommended that you fail a release based on any remaining Critical violations. Ideally, you should be finding only new violations, this will highlight any violations that teams fail to mitigate.

If you configure continuous monitoring, it is a good idea to monitor your release stage, as this is likely the best representation of your production application.


This stage is meant for integrations with deployment tools (e.g udeploy) or for use with the CLI in a deployment script. In many enterprises' deployment into a production or live estate may happen sometime after the creation, testing and publishing of the release candidate. Capturing the state of the application as you deploy allows any new violations to be highlighted and setting enforcement actions to FAIL is recommended for Critical violations.

Evaluations made with the Operate stage do not show up in the reporting view.

5. Notifications

Notifications enable you to send a summary of new policy violations when they occur at a specific stage of development. Notifications are sent whenever an application is evaluated either manually (e.g. using the Evaluate Binary command in the Organization & Policy area) or automatically via any tool integrated into the IQ Server (e.g. Nexus IQ for Hudson/Jenkins 1.x) or if Continuous Monitoring is activated. The notifications can be delivered to email addresses. The emails are sent to individual addresses or users assigned to a particular role such as Owner or Application Evaluator.

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. For information on SMTP settings in IQ Server, see the Email Configuration section of the IQ Server Setup chapter.

When you have repository auditing setup, then notifications will be sent when a new component that violates policy enters your repository manager.

The initial repository audit and re-evaluations of policies on repositories do not send notifications.

To set notifications in a policy:

  1. In the Organization & Policy area, create a new policy or open an existing one for an organization or application.
  2. In the Policy editor, click the Notifications button to scroll to the Notifications section.
  3. Provide recipient information:
    1. Select a Recipient Type. If Email, then enter an email address. If Role, then select a user role from the list. For Jira notifications, enter a project and select an applicable issue type.
    2. Click Add to insert the recipient.
  4. Click to select the stage(s) for which to send notifications to a recipient.

    For the Continuous Monitoring stage, you must have monitoring activated for the application or a parent organization. To learn more about continuous monitoring, see Continuous Monitoring in Applications later in this chapter.

  5.  Click Create (or Update) to save the new policy.

To remove a recipient, click the Delete button (looks like a trash can) for a particular recipient.

Be sure to select a stage for a recipient; if omitted, no notifications will be sent to the recipient.

Usage Suggestions for Notifications at Each Stage

StageUsage Suggestion
ProxyConsider setting up notifications to inform repository owners or Nexus Repository Manager administrators that are responsible for safe-guarding components entering the organization. You can also view any policy violations that occur during this stage in the Repository Results.
DevelopPolicy violations triggered by IDE-related activity generally do not send any notifications.

If not sending notifications at the build or later stages consider setting up notifications to inform developers here.

BuildConsider setting up notifications to inform owners, as well as developers.
Stage ReleaseIf something fails, the development process can not move forward. Make sure to notify anyone who is responsible for the application’s release and/or capable of researching and addressing any violations.
ReleaseSimilar to Stage Release, make sure to notify anyone responsible for ensuring an application does not go into production with policy violations.
OperateTypically the application owner, or anyone responsible for ongoing maintenance of an application in production should be notified.

Jira Notifications

Using Notifications for Atlassian Jira is deprecated in favour of the IQ for Jira integration. All new users should use IQ for Jira and existing customers should look to take advantage of additional functionality from this plugin.

Jira notifications are only available if a Jira server is configured. See the Jira Notifications section below.

The Jira notifications will create a Jira issue when new policy violations are discovered during the development process. To create Jira notifications, you must have already configured a valid Jira server connection in your IQ Server’s config.yml. Without this configuration you will not see the Jira option in the Recipient Type drop-down. 

To configure Jira notifications:

  1. Select the Policy for which you will be notified when that policy is violated.
  2. Select Jira from the Recipient Type drop-down menu.
  3. Select the Project and an Issue Type.
  4. Click Add to add the notification.

Once you have created the notification, you can then choose at which stage(s) you would like to be notified.