Policy Notifications
Policy notifications are email notifications that contain a summary of policy violations that occur during an application evaluation. These 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.
Policy notifications are sent by email, regardless of the nature of the application evaluation, i.e.:
Manual (using the Evaluate a File option from the UI)
Automatic (via continuous monitoring)
Automatic (using integration plugins like Sonatype Platform Plugin for Jenkins)
When are notifications sent:
Policy notifications are sent to email addresses, for all new policy violations that occurred since the last evaluation of the exact same application, at the exact same stage. If an application is being evaluated multiple times, and there are no new policy violations since the last scan, policy notifications will not be sent.
When you have a repository auditing setup, then policy notifications via email 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.
Using Webhooks to Receive Violation Alerts
You can also configure webhooks to receive violation alerts. Refer to Lifecycle Webhook Event - Violation Alert for more details on configuring webhooks for the Violation Alert event.
The Violation Alert is triggered for every violation detected during an evaluation or subsequent re-evaluations. This behavior is different from the Policy Notifications (sent via email), which are only generated when there is a new policy violation which was not detected in previous scans.
To set notifications in a policy:
In the Organization & Policy area, create a new policy or open an existing one for repositories or an organization or application.
In the Policy editor, click the Notifications button to scroll to the Notifications section.
Provide recipient information:
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.
Click Add to insert the recipient.
Click to select the stage(s) for which to send notifications to a recipient. In case of repositories, all stages except Proxy are disabled.
Note
For the Continuous Monitoring stage, you must have monitoring activated for the application or a parent organization.
Click Create (or Update) to save the new policy.
To remove a recipient, click on the delete icon.
Notifications at root organization or organization or application level
 |
Notifications at Repositories level
 |
Usage Suggestions for Notifications at Each Stage
Stage | Usage Suggestion |
|---|---|
Proxy | Consider setting up notifications to inform repository owners or Nexus Repository administrators that are responsible for safeguarding components entering the organization. You can also view any policy violations that occur during this stage in the Repository Results. |
Develop | Policy violations triggered by IDE-related activity generally do not send any notifications. |
Source | If not sending notifications at the build or later stages consider setting up notifications to inform developers here. |
Build | Consider setting up notifications to inform owners, as well as developers. |
Stage Release | If 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. |
Release | Similar to Stage Release, make sure to notify anyone responsible for ensuring an application does not go into production with policy violations. |
Operate | Typically the application owner or anyone responsible for ongoing maintenance of an application in production should be notified. |