Integration overview
After using SD Elements to understand the risk posture of an application, you can export all Countermeasures or a subset of Countermeasures from your SD Elements project to your Issue Tracker project. Here, the Countermeasures appear as work items, such as tickets, features, or stories. When users "close" or otherwise resolve the work item in the Issue Tracker project, the status of the corresponding Countermeasure in SD Elements is changed to "DONE" when the two tools are synchronized.
You can select how frequently the Issue Tracker project is synchronized with SD Elements. The more frequent the synchronization, the more accurate the SD Element Countermeasure statuses will be at any given time. However, be aware that the overhead on the Issue Tracker and SD Elements servers is also increased with frequent synchronization.
Synchronization occurs as a scheduled “batch process”. |
Process
Synchronization between SD Elements and an Issue Tracker project follows the process below.
-
If the integration does not find the Countermeasure in the Issue Tracker project, a new Issue Tracker work item is created with the same title as the Countermeasure. SD Elements changes the Issue Tracker work item’s status, where possible and applicable, to match the Countermeasure status in SD Elements.
-
If the integration finds the Countermeasure in the Issue Tracker project, SD Elements checks the status of the work item in the Issue Tracker project. If the statuses do not match, SD Elements is updated to reflect the status of the Issue Tracker project.
For example, if a JIRA ticket is marked as "Fixed", then the corresponding SD Elements Countermeasure is marked as "DONE". You can configure synchronization in the reverse order, so that updates in SD Elements are reflected in the Issue Tracker project.
-
If the SD Elements Countermeasure was removed from the project, the integration will attempt to close the issue in the Issue Tracker project.
How changes in SD Elements affect Countermeasures in an Issue Tracker
There are five ways Countermeasures synchronized to an Issue Tracker are affected by changes in SD Elements:
-
Status Change: A Countermeasure status change in SD Elements can affect the Countermeasure’s status in a connected Issue Tracker project. The details of this behavior are governed by the status mapping configured for the integration.
-
Risk Policy Change: A risk policy defines the minimum set of Countermeasures needed to satisfy an internal security or policy objective. When a project is subject to a different risk policy or the definition of its current risk policy changes, its minimum set of Countermeasures change accordingly. If an integration is set up to Sync Risk Policy Countermeasures, the list of Countermeasures in a connected Issue Tracker will also change.
-
New Countermeasures applicable to the Risk Policy are added to the Issue Tracker project
-
Countermeasures no longer in the Risk Policy will be marked as Done or closed in the Issue Tracker (Atlassian Jira, GitLab and Pivotal Tracker integrations do not automatically mark such Countermeasures as Done or closed)
-
-
Project Survey Change: Changes to a project survey can affect the list of Countermeasures. Based on new information, the list of Countermeasures in the SD Elements project can change - newly identified Countermeasures are added and irrelevant Countermeasures are removed. These changes are reflected in the Issue Tracker:
-
New Countermeasures are added to the Issue Tracker if they satisfy the integration’s Countermeasures to Synchronize criteria
-
Removed Countermeasures are marked as Done or closed in the Issue Tracker
-
-
Countermeasure addition: Countermeasures manually added to SD Elements are also added to an Issue Tracker if they satisfy the integration’s Countermeasures to Synchronize criteria.
-
Content changes: Countermeasures are added to or removed from a project when a project administrator accepts content updates.
-
New Countermeasures are added to the Issue Tracker if they satisfy the integration’s Countermeasures to Synchronize criteria
-
Removed Countermeasures are assigned the configured
closed_status
(normally Done or Closed) in the Issue Tracker
-
Integration methods
There are two methods of performing integration, depending on your network setup.
If the SD Elements server can communicate directly with the Issue Tracker server, such as when they are both on the same internal network, or both are Software As A Service (SAAS) deployments, then you can use the normal integration process inside of the SD Elements application.
If the SD Elements and Issue Tracker servers cannot communicate directly, such as when SD Elements is accessed through the Internet and the Issue Tracker tool is located on the internal network, use the Remote Integration Agent. The Remote Integration Agent is an application and must be installed on a server or client machine that can communicate with both SD Elements and the Issue Tracker tool. For more information, see Remote Integration Agent.