Notifications & Monitoring in the IQ Server

IQ Server | Reading time: 9 minutes

Is this article helpful?

Automatically receive notifications of your application scans.

This guide explains the importance of setting up and receiving notifications and continuous monitoring (CM) for your IQ Server scans. We’ll cover email notifications, the Jira plugin, webhooks, continuous integration (CI) alerts, and continuous monitoring.

The primary desired outcomes of configuring IQ Server alerts and monitoring are to:

Reduce reaction time to problem areas & components Notifications let you tailor who receives alerts to new policy violations at different stages of the development lifecycle, while continuous monitoring lets you know if issues arise with your legacy applications.
Reduce technical debt When development teams are aware of any violations in new and legacy apps, they are able to add these as stories to their workflow and reduce technical debt.
Improve control of your deployment process You can enforce policy at software release and break builds that you had previously warned on during development. This means that no application goes out the door with violations.
Enhance compliance Timely alerts help your organization adhere to OSS policies (license, security, etc.) and follow your remediation plans.
Increase Developer Productivity Our Jira integration and webhooks are all about automating discovery and management of policy violations directly to your current ticketing process.


Before getting started with notifications and monitoring, it’s best to distinguish the importance of roles. This section will help you understand how roles work in the IQ Server, and how to apply notifications to the correct roles. Roles provide a set of permissions that grant various levels of access and control over the IQ Server as well as the connected suite of tools. To grant permissions, you assign a user to either a system-wide administrator role or an organizational role at one of the levels in the system hierarchy: root organization, organization, or application. Which role and level you choose for a user determines what permissions that the user receives.

IQ Server has several built-in roles, and also provides the ability to create custom roles. The built-in roles are shown here:

Administrator Roles

  • System Administrator - Manages system configuration and users, which includes LDAP and product license management as well as the ability to assign other users to the System Administrator role.
  • Policy Administrator - Provides full control over organizations, applications, policies, policy violations and custom roles. Only the Policy Administrator has the ability to create organizations.

Organizational Roles

  • Owner - Manages assigned organizations, applications, policies, and policy violations.
  • Developer - Views all information for their assigned organization or application.
  • Application Evaluator - Has minimum access to scan the application via the CI integrations. Evaluates applications and view policy violation summary results within the CI.
  • Component Evaluator - Evaluates individual components and view policy violation results for a specified application within the IDE integrations.

It’s important to understand roles because you will need to assign user roles to notifications. This can be done directly to a user’s email or via the roles assigned to the organization or application in IQ Server, or this can also be scoped by policy. In general, a best practice is to assign LDAP groups as particular roles to organizations/applications and use the roles for notifications on the required policies.

We go into role assignment a bit more in the Creating your Notification Plan section of this doc, and you can also check out our help docs on Role Management and LDAP Integration.


Automating notifications in IQ Server leads to a better understanding of application health and improved remediation workflow. In this section, we’ll go over the types of notifications available with IQ Server and how best to apply them to suit your needs.


The IQ Server can be configured to send email notifications for events such as policy violation notifications. This functionality requires an SMTP server, which is configured along with a number of other options in the Mail Configuration section of the config.yml file.

Email notifications from the IQ Server are automatically sent to recipients when a policy alert occurs. The email contains information about the application and violation, and provides a link to the full results for further investigation.

Email Notification

As mentioned, email is a simple way to start getting notifications to the application security team, and eventually developers once they have been notified to expect them. Once your process has matured, a best practice is to automate the ticket creation process, which will eliminate the manual process of adding each issue to your backlog.

For help configuring your email notifications, please see our help documentation on Notification Configuration.


Our IQ Jira plugin puts remediation right into the development workflow — letting you easily get violations in front of the people who can fix them. The IQ Jira plugin lets you automatically create Jira tickets for violations found in your applications, within the Jira projects associated with those applications. This provides an instinctive way to communicate policy violations for development teams that are already using Jira for feature development and bug reporting.

Example Jira ticket

For help installing the plugin, please see our Nexus IQ for Jira documentation.


IQ Server provides webhooks that let you receive notifications about various events — for example, when an application evaluation is completed. When these events happen, the IQ Server creates an object that has relevant information about the event, such as the type and any associated data associated. IQ Server then sends the event object to defined URLs using HTTP POST requests. Webhooks are a powerful way to set up custom notifications.

In essence, webhooks are all about scripting automation anywhere. For example, you can use webhooks to create a message in Slack when a policy evaluation event occurs, as outlined in this guide, and webhooks are also how our Jira Plugin gets data for events.

Policy Notification in Slack

IQ Server lets you use webhooks for policy management, application evaluation, security vulnerability override management, and license override management events. For more information on setting up webhooks, see IQ Server Webhooks.

Continuous Integration

In addition to email, Jira, and Webhook notifications, IQ Server also integrates with CI servers, such as Jenkins, and provides scan notifications within those applications. If you’re using Jenkins, as builds complete, a link to the Application Composition Report displays on the project screen. Clicking on the link sends you to the report within the IQ Server. The three boxes (red, orange, and yellow) located below the link, give you counts for policy violations and are based on the associated severities (critical, severe, and moderate).

IQ policy chicklet in Jenkins

In addition to Jenkins, the IQ Server also provides CI notifications for Azure DevOps, Bamboo, and GitLab CI. For more information, see Nexus and Continuous Integration.

Continuous Monitoring

Continuous monitoring lets you use existing policies with notifications to watch for new violations at a specific development stage, such as release. The main use case for continuous monitoring is that you have released an application into production, and you want to be made aware of any new policy violations. The most common example would be a new CVE, or our research has found a new vulnerability and changed, or updated, the score.

Setting up continuous monitoring is a three-step process:

  1. Configure and enable notification(s) (email, Jira, and/or webhooks).
  2. Turn on continuous monitoring at the organization or application level and specify which stage of the development lifecycle to monitor.
  3. Turn on continuous monitoring at the policy level by creating a notification and selecting continuous monitoring in a policy.

Best Practices for Continuous Monitoring

When thinking about configuring continuous monitoring for your applications, there are a few things you should keep in mind:

  • In general, if an application is being built one or more times a day, it does not need to be monitored by CM. Good candidates for continuous monitoring are irregular builds and releases.
  • Continuous monitoring is not configured by default. You will need to enable notifications and then turn on CM at the org/app level and then the policy level.
  • You will need to set CM to a ‘stage’ where production or long-lived builds are scanned.
  • Emails for CM applications are not easily differentiated from emails for policy violation notifications.

For more information on CM setup, please see our continuous monitoring help documentation.

Creating your Notification and Monitoring Plan

All monitoring solutions simply do what you tell them to. To create a manageable notification plan for the IQ Server, we suggest the following:

Example IQ Server notification plan

  1. Plan and configure notifications that work for your organization
    A good place to start is with email notifications. From here, you can add dev support with the Jira plugin. Next, you can turn on continuous monitoring for legacy apps. Also, feel free to get creative with Webhooks — for example, set up policy scan notifications in Slack. Additionally, if you have builds in Jenkins, or another CI Server, use our integrations so you’ll receive notifications in those environments when a scan is done.
  2. Set priorities and classify your alerts based on importance
    Not all applications are as critical as others. Identify the most important applications and be sure those notifications are front and center. It is beneficial to your notification plan to prioritize the most important issues.
  3. Know your audience
    Because IQ Server provides a range of notifications and monitoring tools, it’s important to configure alerts so the right people see them. The best process is to set up LDAP groups, then IQ Roles set to org/app, and finally your policy notifications. It’s also important to socialize your intent so notifications don’t just start “showing up.” This will help avoid duplicate notifications that create noise. Finally, gather feedback on what’s effective and what’s not and then iterate on your notification plan.
  4. Create a process for how alerts are resolved
    Creating a process on how to handle notifications allows for the quickest resolution and is an important part of your organization’s remediation plan. For help, check out our guide on Getting Started with IQ Server Remediation.
  5. Ask for help
    The Sonatype team provides support and technical staff that are here to assist you. Be sure to take advantage of our product knowledge experiences with other customers. We can help you get a notification and monitoring setup that works best for your organization.

Talk to Us

Have more questions or comments? Learn more at, join us in the Sonatype Community, and view our course catalog at

And visit for all things Sonatype.