Issue policies
Use issue policies to automate actions when issues with specific properties are detected in a test.
Issue policy overview
Rules
You can add up to five rules to each issue policy. Rules control what actions occur when test results violate a policy (when issues with specific properties are detected in a test). Set up rules to monitor tests for issues with any combination of the following properties:
- New and/or preexisting issues.
- Issues with different fix-by statuses.
Table 1. Fix-by statuses Fix-by status Description Overdue The issue was not fixed before its fix-by date. Due Soon There are 7 or fewer days before the issue must be fixed. On Track There are 8 or more days before the issue must be fixed. Not Set The issue does not have a fix-by date. - Issues captured in SAST, SCA, or DAST scans.
- Issues with specific severities.
- Issues with specific triage statuses (including dismissed due to a component being excluded).
- Issues from a particular standard (for example, OWASP® Web Top Ten 2017).
- Issues with specific Common Weakness Enumeration (CWE™) codes.
Actions
You can assign the following actions to each rule in an issue policy:
Action | Description | Prerequisites |
---|---|---|
Send Notification | Send an email notification to Organization Admins when issues with specific properties are found in a test. Each email includes the names of one or more violated issue policies, the violated rules in each policy, the total quantity of violating issues for each rule, and helpful links. Click an issue quantity to view the issues that violate the rule in Polaris. Note: Email notifications for issue and component policies are only sent to Organization Admins. One email is sent each time a test's results violate one or more policies, and each email can include issues that violate more than one of each policy's rules. If a test's results violate issue and component policies, violated issue and component policies are listed in the same email. |
Notifications must be enabled for the organization, and your personal notification settings must allow Policy notifications. |
Attempt Build Break | For tests run via Bridge (including the Synopsys Security Scan Extension for Azure DevOps, the GitHub Action, the GitLab Template, and Synopsys Security Scan Plugin for Jenkins), attempt to break a build after issues with specific properties are found in a test. | The action only affects tests run using Bridge. Additionally, polaris.waitForScan must be set to true (default) in your pipeline. |
Create and bundle to 1 Jira ticket | When issues with specific properties are found in a test of a project's default branch, create a Jira ticket. Each ticket includes the name of a violated policy, the violated rules in the policy, and helpful links. Click the name of a violated rule to view the issues that violate the rule in Polaris. Note: Jira tickets are only created for the default branch of a project. One ticket is created for each violated policy. |
The project must be connected to Jira via a Jira integration. Note: For more information, see Jira integration for Polaris and Set up Jira in an individual Project. |
Fix-by dates
Add fix-by dates to your issue policies to help your developers prioritize issues for remediation, and enforce your organization's security standards across projects and applications. A policy's active fix-by dates are automatically applied to issues based on their severity. Fix-by dates are:
- Optional properties you can add to any issue policy.
- Not dependent on an issue policy's rules.
- Day-based (between 1 and 365 days).
- Severity-specific, so different fix-by dates can be assigned to issues with different severities.
- Shared across branches in your projects.
If an issue with a fix-by date is resolved and later reintroduced, the fix-by date is restored. For example:
- A critical severity issue is detected on January 1 at 9:00 AM, and a policy applies a fix-by date of 7 days (January 8 at 9:00 PM).
- On January 5th, the issue is resolved (no longer detected in tests).
- On January 15th, the same issue is reintroduced (detected in a test), and violates the policy again.
In this scenario, the issue's fix-by date is restored to January 8 at 9:00 PM.
When multiple policies attempt to set an issue's fix-by date, the shortest fix-by date is used.
Fix-by dates don't depend on an issue policy's rules. For example:
- An issue policy is configured to send notifications for new critical severity issues.
- The issue policy includes active fix-by dates for critical, high, and medium severity issues.
In this example, fix-by dates are applied to all critical, high, and medium severity issues captured in tests subject to the policy (that don't already have fix-by dates).
Multiple rule violations, multiple policy violations
What happens when a test's results violate more than one rule in a policy?
- When multiple Send Notification actions are triggered (for multiple rules in the same policy), violating issues are grouped together and sent to Organization Admins in the same email.
- When multiple Create and bundle to 1 Jira ticket actions are triggered (for multiple rules in the same policy), Polaris creates a Jira ticket that includes the names of violated rules.
What happens when a test's results violate more than one policy?
- When Send Notification actions are triggered in different policies, one email is sent to Organization Admins that includes all violated policies.
- When Create and bundle to 1 Jira ticket actions are triggered in different policies, one ticket is created for each violated policy.
What happens when policies apply different fix-by dates to the same issue?
- When multiple policies attempt to set an issue's fix-by date, the shortest fix-by date is used.
Example issue policy
For example, say you create an issue policy with the following fix-by dates:
- Critical: 7 days
- High: 14 days
- Medium: 30 days
- Low or Informational: Not active
... and the following rules:
Rule | Issue properties | Actions |
---|---|---|
Rule one | New critical or high severity issues with not triaged or to be fixed triage statuses. | Send Notification and Attempt Build Break |
Rule two | Existing critical or high severity issues with not triaged or to be fixed triage statuses. | Attempt Build Break |
Rule three | New critical severity issues with not triaged or to be fixed triage statuses. | Create and bundle to 1 Jira ticket |
In tests subject to this example issue policy:
- If the different action prerequisites are met:
- Issues that were triaged and dismissed after an earlier test do not trigger actions.
- For tests run using Bridge, builds will break when new and existing critical or high severity issues are detected.
- An email notification is sent to Organization Admins when new critical or high severity issues are detected.
- A Jira ticket is created when new critical severity issues are detected in a project's default branch.
- Fix-by dates are applied to critical, high, and medium severity issues that don't already have fix-by dates.
View an issue policy's details
Create an issue policy
Modify an issue policy
- Go to Policies and open the Issue Policies tab.
- Click the options icon at the end of the policy's row and select Edit.
- Modify the policy, as required.
- Select Save.