I’m trying to integrate threat modeling into jira workflows for the app teams. For instance, once I have completed threat modeling for an application, I want to create a jira issue with the vulnerability findings and assign it to the app team’s product backlog.
How do i achieve this if we don’t have automatic integration with jira? Is it possible to directly assign an issue into an app team backlog? Can anyone share their views or help around the workflow to do this?
Hi - The short, unhelpful answer is. “it depends.” Let me provide a few pointers that may help:
- Jira has comprehensive documentation on its API. Depending on how you generate the threat model, setting up the API integration should be pretty straightforward. For instance, here’s an article on creating an issue through API calls. Of course, you always have the option of creating tickets manually, but that’s time-consuming (and boring :P)
- The trickier part is figuring out what access you have to the app team’s Jira board. Every company/team uses Jira differently, and you need to make sure you have access to create issue
- “Adding directly to App team’s backlog” depends on how they track backlogs. If they use a Kanban board, understanding their project configuration is important. Typically, not all issuetypes are added to the backlog. Furthermore, they may not appreciate having a lot of non-related things added to their backlog (some teams generate a lot of metrics based on what’s in their backlog). So, understanding how the app team prefers the issues tracked is important.
We’ve done a ton of internal work on Jira integrations. Feel free to DM if you have further questions. In general, publishing threat model results in the same place where developers track other bugs is a great idea. Good luck!
-Sandesh
1 Like
I agree with Sandesh’s points and wanted to add a little bit. Find out who the Jira application owner is and work with them. They likely have insight into how teams are working and if there’s a standard being applied (e.g. the Kanban board mentioned) or if you’ll have to work with differently configured projects. Establishing that relationship has been key for us. We’re currently working with them to create a new issue type for security reviews (we’re, thankfully, already using a threat modeling tool that integrates with Jira 
) as it’s a requirement for every product and working with the Jira app owners has been vital in understanding the best way to approach this. We’re also using Jira templates to create the skeletal structure for certain types of requests to minimize having to re-type or select specific items we know will be repeated.
2 Likes
Unfortunately we have to go the manual way for now until we figure out the automation capability of our tool. Do you think it makes sense for the jira project admin for the app to give us the required permissions to be able to create an issue in their backlog for tracking the threat model findings?
For other types of tickets (e.g. pentest findings), this is exactly what we do currently. We track internal pentests in our Jira project using a template and we create the findings in each teams Jira project. We worked with the Jira app admin and the various development teams to get permissions to create tickets in their projects.
As for whether it makes sense for you, that’s harder to say and I’ll steal Sandesh’s “it depends” comment. It really depends on the relationship you have with the dev teams and the jira admins. In our scenario, we work very closely with the dev teams. We advertise our group as a services and advisory group for security (i.e. we’re here to make the devs successful in delivering their products). If you don’t have that kind of relationship, it may be harder to get the devs to let you add work to their backlogs.
1 Like
Like to add:
If the team is part of the threat modeling ceremonies and gets to own decisions about mitigations, they will not be pissed if mitigations are added to their backlog.
It depends. 
2 Likes
That’s a great point! If they’re involved in the process they’ll know what to expect vs someone just coming in and saying here’s a bunch more work to do.
2 Likes
Another consideration might be adding those issues to a board you do have full access to and then using Jira workflows to only move items that meet the workflow conditions. I do this with a holding board that then routes GRC related items to a different board. This might let you get that automated sync working into jira where you have full control over board access and then use the jira workflows function to control what gets moved over to another teams backlog.
1 Like
Great insights shared here and lot of points I agree with.
In my view as well, it’s important to have an established relationship with the app team before starting the threat modeling activity. Additionally, the responsibility of creating tickets or adding in the backlog/kanban can be assigned to representative(s) from the app team, allowing them to take ownership and prioritize tasks effectively, instead of managing & tracking it centrally especially when there are multiple projects/teams.
This is how I visualize the manual workflow, until automation/integration is achieved:
Pre-req: App team already part of the threat modeling activity
- Identify and agree primary & backup representatives from the app team who would be responsible for creating tickets/adding to the backlog
- If capability exists, give these representatives access to threat modeling tool
- During threat modeling activity, convert controls/mitigations identified into “Actionable Items” with some tracking number from the threat modeling tool
- These Actionable Items can be given to the app team representatives to create tickets or add into their own backlog/kanban
- App team reps report back on the Actionable items with ticket numbers as ack/reference or if the capability exists directly add/update the threat modeling tool
- App team reps continue to report back on the status/closure of the tickets or directly update in the threat modeling tool if the capability exists
Hope this helps
2 Likes