In case you have multiple distributed teams, which will work on threat analyses (TARAs) collaboratively, you may need a workflow that serves this purpose. You may want to split the TARA for organizational reasons or to make large projects manageable. The team shall be able to refine its target of evaluation (TOE) and create its own TARA iterations. In the end, it shall be possible to have a complete TARA which includes all sub-TARA results.


  • Use your version control system (e.g., Git)
  • Have a common starting point (e.g., “master”)
  • Branch off per dedicated team or sub-chunk (e.g., “function1”, “function2”)
  • Use tool supported merge to get changes back

The corresponding git graph should look about like this. In this example we have a “master” branch which is synchronized with two feature branches.

Sample Git graph


Create a new project and model your initial TOE. Have these changes on a dedicated branch in your version control system, let’s call it “master”. The following example contains two shared components and a common data flow which transfers “D.1”.

Initial System Model

Having this common ground, we may create several branches that shall contain the individual sub-function threat analyses. (e.g., a branch per team or per sub function) The TOE can be refined, and an initial threat analysis can be started independent of each other. In our showcase these branches are called “Sub-Function-1” and “Sub-Function-2”. In the example below, on each branch new components, data flows and data elements have been created. “Sub Function 1 Component” with contained data on the one hand and “Sub Function 2 Component 1” with a data flow to “Shared Component 1” on the other hand.

Changes “Sub Function 1”

Changes in “Sub Function 2”

Once the individual teams are done with their first TARA iteration you may merge back the changes to the common “master”-branch. itemis SECURE supports graphical merging within the tool so that we can see the changes in the model instead of messing with text files.  After the merging, the resulting system diagram and security graphing including some example damage scenarios, security objectives and threats looks as follows.

Merged Attack Tree

Merged System Model


The proposed workflow works flawlessly if we start from a common TARA and take care of potential naming conflicts either beforehand or during the merge process. Starting from a common project is important since this avoids conflicts on lower abstraction levels. (e.g., unique IDs that are used internally)
Either way, it is suggested that the branches are as short-lived as possible and get synchronized from time to time.