Sonatype CLM Server - Policy Management
Policy actions and notifications allow you to tell CLM to perform a specific function when violations occur. In some cases this can include forcing a particular action in one of the Sonatype CLM Tools (e.g. Sonatype CLM for Bamboo - installed separately from the Sonatype CLM Server).
Alternatively, notifications can be set so that when violations occur, any combination of particular email addresses, or the email addresses associated with the members of a particular CLM role, will be notified.
Actions are organized by enforcement point. In Sonatype CLM, enforcement points represent a stage in Component Lifecycle Management (i.e. Development, Build, Stage, Stage Release, and Operate).
For each stage there are two degrees of action you can assign to each enforcement point:
- Warn - generally will not break the process, and only displays violations that have occurred (e.g. Nexus CLM will display a warning during staging).
- Fail - generally will break the process (e.g. prevent a build in Sonatype CLM for Bamboo).
To add actions:
-
First make sure you have:
- The policy open to edit (have clicked the edit icon - shaped like a pencil).
- A minimum of owner rights (a member of the owner role) for the application or organization the policy resides in.
- Next, click on either the warn or fail action in the column for the particular stage. An icon will confirm your selection.
- Click Save, or proceed to adding notification in the next section.
![[Tip]](images/icons/tip.png){kind=icon}
|
|
|
Take care in being too anxious to stop your development cycle using an action. For example, setting the Fail action at the Build enforcement point. |
When a new violation occurs, a notification will be sent. This includes any email addresses entered manually, as well as email addresses for the users that have been added to any roles selected.
To add notifications:
- Click anywhere within the notifications field. This will display a modal allowing you to select a role or enter a specific email address.
- Enter an email address manually, and or select any roles you wish to be notified.
- Click Save.
![[Note]](images/icons/note.png){kind=icon}
|
|
|
When a notification is sent, it will only display new violations found in the latest scan. If you find yourself not receiving notification, verify there are new violations, as well as confirm you have configured your Sonatype CLM server SMTP settings. |
Both Actions and Notifications are set by stage. A description for each stage as well as suggested actions and/or notifications have been listed below.
- Develop - (e.g.g Sonatype CLM for Eclipse)
-
- Definition
- The Develop stage represents development.
- Suggested Actions
- While actions and notifications can be configured for this stage, they will not affect the functionality of Eclipse.
- Build - (e.g.g Sonatype CLM for Bamboo or Hudson/Jenkins)
-
- Definition
- The Build stage represents actions in tools using during the building of your applications.
- Suggested 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 build for an application contains components that violate your policies.
- Suggested Notifications
- Consider setting up notifications to both inform Application Owners, as well as developers.
- Stage Release (Nexus Pro CLM)
-
- Definition
- The Stage Release stage is specific to Nexus CLM, and involves placing a near final build into a staging repository prior to having it officially released.
- Suggested 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 our recommendation. This is especially true for any policies that may include risk associated with security and/or licensing.
- Suggested Notifications
- If something fails, the development process can’t move forward. Make sure to notify any members of the team responsible for the release of the application and capable of researching and addressing any violations.
- Release (Nexus Pro CLM)
-
- Definition
- The Release stage is the final push for a project into production.
- Suggested Actions
- While there should be the closest scrutiny of policy violations at this point, there will be a similar recommendation to fail a release based on severe violations. In most cases, you should ideally be finding new violations only.
- Suggested Notifications
- Similar to Stage Release make sure all stakeholders, that is those members responsible for ensuring an application does not go into production with policy violations, are notified.
|
|
|
|
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
-
- Definition
- The Operate stage represents the best known example of the application in its production state. It can be set via a variety of tools, but in all of these cases, it is set manually.
- Suggested Actions
- For this reason, providing any warning or fail actions will not produce any different result.
- Suggested Notifications
- Typically the application owner, or anyone responsible for ongoing maintenance of an application in production should be notified. However, remember that evaluation in the Operate stage is manual.