This page has been moved to Zendesk. Please, refer to this link for the latest version.
Issue trackers can have a default configuration for all products that can be overwritten with a specific per-product configuration so that different trackers or settings can be used for different products. Currently, we support integration with Atlassian JIRA, Redmine, CA Rally and Team Foundation Server issue trackers. Integration with other trackers can be built on request.
Default settings can be found in the settings menu. Different behaviours of the issue trackers can be configured, for example, creating tickets automatically for failed Weakness tests and closing tickets when a failed test is changed to passed (further details):
A different combination of settings can be configured for a particular product through the option Settings in the project's action menu:
When providing the settings of an issue tracker in the Global Settings, those settings will be inherited for each newly created product. If you add a password or an API key to these settings, these will also be inherited.
JIRA configuration can be provided in the same Global Settings or in the project settings window.
Issue type: Classification of the synchronized issues.
Issue priority: Preference of the Synchronized issues.
Open issue name: Status name for issues in progress.
Closed issue name: Resolution name for completed issues.
Rejected issue name: Resolution name for denied issues.
Issue link type name: type of link (i.e: relates to, is blocked by...)
Labels (Comma separed): Tags added to the issues.
Please note that we use the Status property of the Jira tickets for the Open Issue Name and the Resolution property for the Closed and Rejected tickets. This is because when a ticket is created, it should be mapped to the initial status of the Jira workflow, but when we synchronize back the action that was done for this ticket, the Resolution property is the one that holds the information as a ticket can be done within the workflow but with a Won't Fix resolution (i.e.).
Priorities: Priority of the issue (i.e: None, Resolve inmediately, High attention, Normal, Low)
Severities: Severity of the issue (i.e: None, Crash/Data loss, Major problem, Minor problem, Cosmetic)
Open issue name: State name for issues in progress.
Closed issue name: State name for completed issues.
Rejected issue name: State name for denied issues.
Tags (Comma separed): Labels added to the issues.
This sync action is performed in a background job on a 5-minute schedule. We can force the sync by using the Sync with issue Tracker option on the Countermeasures Action menu in real-time:
Once the synchronization is done, the Countermeasures with linked issues can be viewed on the Countermeasures Tab, Issue IDs are direct links to the specific issues on the external tracking system:
Linking Countermeasures to Issues
There are three routes to create tacker issues from the required Countermeasures. The first is through the New Project wizard where one of the final popup screens will prompt the user to upload Required countermeasures to an issue tracker.
The second option is to explicitly create new issues for all required countermeaures from the Countermeasures Tab's Action menu. Note that only countermeasures in the "Required" state will be uploaded.
And finally, issues can be created for individual countermeasures by using the Action menu on the countermeasure itself:
Once a Countermeasure has been linked to an issue, the issue acts as a master source for the status of the Countermeasure. This means that changes in the countermeasure status within IriusRisk will be overridden by the status of the ticket on the Issue Tracker.
The status of the Countermeasure is mapped as indicated by the configuration fields: Open issue name, Closed issue name and Rejected issue name. On the creation step, the issue will be assigned the type and priority based on the configuration fields: Issue type and Issue priority.
Linking Countermeasure Test Results
When a Countermeasure is tracked with an external issue tracker, the test result directly affects the issue status. If a Countermeasure status changes to Failed and the tracker issue was marked as "Closed", then the ticket is automatically reopened and a comment with the failure information is included on the ticket.
In the same way, if a Countermeasure's test changes to a Passed status, the related tracker issue is automatically closed. This behaviour can be changed using the settings for the tracker.
Linking Weakness Test Failures
If the configuration setting "Create tickets for failed Weakness Tests" is set and an issue tracker is configured then Weaknesses will also be associated with issues. We can force this process by using the Create issues for all failed weakness tests in threats tab. The links to weakness issues will be displayed in threat detail pannel:
This situation will happen when a Weakness test changes its status to Failed, in that moment, a new tracker issue will be created with information on the Weakness, testing steps and the results of the performed test. This issue will also include the related Countermeasures for reference purposes.
When the Weakness test is changed back to Passed, then, the associated issue will automatically be changed to a Closed status.
An example of an issue created for the JIRA tracker would be: