Over the past several years, I have spoken to hundreds of customers about how to get developers to take action on vulnerabilities. The majority of developers use Jira to track work so typically, security teams piggyback on that process to assign vulnerabilities. When it comes down to the process details, each customer has their own story. But at a high level, most customers fit into the following three use cases:
- Centralized Jira Security Project: Appsec team has one “security” Jira project to manage their security work.
- In Developer Jira Projects: Appsec team pushes security tickets into developer’s Jira projects while respecting developer’s ownership.
- Hybrid: a hybrid of both with one “security” project and a linked issue in developer’s Jira projects.
In general, there are pros and cons to each use case. I’ve summarized them below:
Supported By Bugcrowd
|Centralized Jira Security Project||
|In Developer Jira Projects||
Whichever method works best for your organization, one thing is clear: integrating application security into Jira requires flexibility.
Common Jira Integration Considerations
Fix validation workflow: This concept is born out of the painful realization that remediating appsec vulns is hard. As a result, patches need to be retested for verification. Bugcrowd syncs the Jira issue status to the Bugcrowd Crowdcontrol platform for quick retesting validation.
Submission Updates: Resolution steps may be edited with more comprehensive details upon learning the specific tech stack used. Crowdcontrol provides updates to inform developers of these changes to ensure faster remediation.
Respecting developer’s notes: Jira’s success is built on the wiki-like structure that enables developers to add their own context to their assigned work. To avoid overwriting the developers’ work, Crowdcontrol respects developer’s Jira notes in multiple ways:
- Configurable field syncing
- Syncs comments as Jira comments
- Preserves existing Jira labels
Supporting Major Jira Project Instances
Centralized Jira Security Project
Having one security Jira project between security and development is a great way to centralize work; it is simple to maintain as there is no logic needed to understand where tickets are created. Bugcrowd supports this model with Automatic JIRA Ticket Creation, transferring all the vulnerability details from Crowdcontrol upon moving a submission from Triaged to an Unresolved state.
In Developer Jira Projects
Enterprise organizations typically have more than one development team or business application, which requires more than one Jira project. Bugcrowd provides multi-project support with just one click for as many Jira projects needed. I’ve also seen the use of one Jira project in SaaS organizations, that delineate issues via custom fields. This way, all the work is in one Jira project but the engineering teams can be assigned work by modifying the custom “team” field. Understanding and aligning to each team’s preferences will reduce friction on them actioning your work. Bugcrowd supports multiple configurations, Jira Components, custom labels and custom fields for the same Jira project, enabling easy to use templates.
Hybrid combines the pros of each, but it’s more to manage. The primary benefit is maintaining control if development makes edits. This provides an additional layer of accountability and visibility. Bugcrowd supports custom fields allowing for trackability and reporting.
Planning is half the battle
By creating Jira tickets in the right project with the right configuration from the beginning, you gain automatic visibility and accountability of security work. This integration should be done in partnership with engineering so they are not surprised by these new tickets.
We firmly believe that it takes a partnership between engineering and security to help secure your organization and customers, which is why we have invested so much in this integration. Regardless of your Jira integration you choose, Bugcrowd supports it.