Azure DevOps Boards Integration with DefectDojo

Azure DevOps Boards Integration with DefectDojo

Azure DevOps is Microsoft's suite of development services, and Azure Boards is its work tracking component. Teams use it to plan and track work items such as user stories, bugs, and tasks on backlogs, boards, and sprints, with fields like State and Priority driving how work moves. Azure DevOps is available as the hosted Azure DevOps Services at dev.azure.com and as the on-premises Azure DevOps Server.

Azure DevOps Boards Integration with DefectDojo

We push DefectDojo findings into Azure DevOps Boards because that is where our development teams plan sprints, and security work that isn't on the board doesn't get scheduled. DefectDojo remains the place where findings from every scanner are deduplicated, triaged, and held to SLAs. The DefectDojo Pro Azure DevOps Boards Downstream Connector creates work items for the findings that need a developer, sets their Priority from the finding's severity, and moves them to Done when the finding is mitigated, marked false positive, or risk-accepted. Developers stay in Azure DevOps, and the security team keeps the record.

Why Azure DevOps Boards Matters

In organizations built on Microsoft tooling, Azure Boards is often the one place every engineering team agrees to look.

• Work items sit in the same backlog and sprint as feature work, so security fixes get capacity planned for them rather than squeezed in.
• Priority and State are standard work item fields, so security items sort and filter the same way as everything else on the board.
• Azure DevOps projects tend to map to product teams, which gives each finding an obvious destination.
• Findings left only in a security tool are easy to postpone. A work item with an owner and a sprint is much harder to forget.

Advantages of This Integration

What we gained by pushing findings from DefectDojo into Azure DevOps Boards:

• Triaged findings, not raw scanner output. Deduplication and triage happen in DefectDojo first, so each work item represents one real issue.
• Severity drives Priority. By default Critical maps to Priority 1, High to 2, Medium to 3, and Low and Info to 4, matching Azure DevOps' convention that 1 is the most urgent.
• State follows the finding. Active findings map to To Do. Closed, false positive, and risk-accepted findings map to Done by default, and each mapping can be changed.
• Choice of push behavior. Assignments can push only on demand, create work items for new findings automatically, update linked work items on edit, or both, with filters for minimum severity and active findings only.
• Custom fields. Since DefectDojo Pro 3.3.200, the Azure DevOps connector applies your custom field mappings to work items, which helps when a project expects fields beyond the defaults.
• Traceability. Every linked finding shows the work item ID, a direct link, and a changelog of when DefectDojo created or last changed it.
• Finding Groups as one work item. Related findings grouped in DefectDojo can be pushed as a single work item.

How This Integration Works

Pushing findings to Azure DevOps Boards is a Downstream Connector, which is a DefectDojo Pro feature. Community Edition's built-in issue tracking integration supports Jira only. A superuser configures the connector under Connect > Downstream.

Keep this separate from the Azure DevOps Upstream Connector, also part of DefectDojo Pro. That connector is an Asset Connector that reads the git repositories in your Azure DevOps organization and creates a DefectDojo Asset for each, grouped into Organizations by Azure DevOps project. It imports no findings, needs only read scopes (Code: Read and Project and Team: Read), and per the docs supports Azure DevOps Services only. The two connectors use different tokens with different permissions, and you can run both.

Setup has three layers: an Instance holds one or more Mappings, and each Mapping holds one or more Assignments.

1. Create the Integration Instance.

• Label: a name for this Azure DevOps connection.
• Location: your organization URL, for example https://dev.azure.com/{your organization}.
• Token: an Azure DevOps personal access token with Read, Write and Manage permission for Work Items on the project you plan to push to. Create it from a dedicated service account so work item history shows the integration, not a person.

2. Create an Issue Tracker Mapping. Enter the Project ID, which can be the name or the ID of the Azure DevOps project. Then review the field mappings. The defaults are:

• Severity Field Name /fields/Microsoft.VSTS.Common.Priority: Info 4, Low 4, Medium 3, High 2, Critical 1
• Status Field Name /fields/System.State: Active To Do, Closed Done, False Positive Done, Risk Accepted Done

The default state names come from Azure Boards' Basic process. Projects on the Agile, Scrum, or CMMI process use different state names (for example New, Active, Resolved, and Closed in Agile), so set the status mapping to states your project's process actually has. Create one Mapping per target project.

3. Assign Assets or Engagements. Each Issue Tracker Assignment links one Asset or Engagement to a Mapping and picks a push mode:

• Only Explicitly Publish Changes to Target: manual only, through Push to Integrator.
• Automatically Link New Finding to Target: new findings create work items; later edits need a manual push.
• Automatically Update Existing Link on Finding Edit: edits update work items that were linked by hand.
• Automatically Link New and Update Existing Link on Finding Edit: both.

Minimum Severity and Active findings only filters narrow automatic creation. They never stop updates to an existing work item, and a manual push ignores them.

Data Granularity: What Gets Sent

Data flows outward. Built-in two-way sync from ticket back to finding is documented for Jira only at this point.

Use Cases

Sprint-ready security work: A team with one Azure DevOps project per product maps each project to its DefectDojo Asset and auto-creates work items for High and Critical findings. They show up in the backlog with Priority already set, ready for sprint planning.

Automatic closure after a fix: When a reimport mitigates a finding, update-on-edit moves its work item to Done. The finding in DefectDojo keeps the link to the work item, which gives auditors both the scan evidence and the engineering record.

Grouped dependency upgrades: Dozens of CVEs in one outdated library are grouped into a Finding Group in DefectDojo and pushed as a single work item to upgrade the library.

Triage before escalation: Some teams keep the assignment on explicit publish. An AppSec engineer reviews findings in DefectDojo and pushes only the ones that need development time.

Operational Tips

• Check your project's process template before going live. If To Do or Done isn't a valid state in that process, change the status mapping first rather than discovering it through push errors.
• Info and Low both map to Priority 4 by default. If you push Low findings at all, consider a Minimum Severity filter so the board isn't filled with Priority 4 items.
• Scope the personal access token to Work Items with Read, Write and Manage, and track its expiration date. Azure DevOps personal access tokens expire, and the connector can't push with an expired one.
• If your project requires fields the defaults don't set, add custom field mappings on the Mapping and confirm you are on DefectDojo Pro 3.3.200 or later.
• When a work item doesn't appear, check the mapping's Total Errors table, or filter Diagnostics to the downstream integrator to see failed or still-queued pushes.
• Make risk acceptance and false positive decisions on the finding in DefectDojo, where they affect SLAs and reporting, and let the connector carry the resulting state to Azure DevOps.