GitLab Issues Integration with DefectDojo

GitLab Issues Integration with DefectDojo

GitLab is a DevSecOps platform from GitLab Inc., offered as the hosted GitLab.com service and as a self-managed installation. Every GitLab project includes an issue tracker, and issues can be planned on boards, assigned, labeled, and linked to the merge requests that resolve them. For many engineering teams it is where planned work lives, which makes it the natural destination for security findings that need a developer to fix them.

GitLab Issues Integration with DefectDojo

We send DefectDojo findings to GitLab Issues because our developers already plan their week from GitLab, and asking them to check a second tool for security work never stuck. DefectDojo stays where findings are deduplicated, prioritized, and measured against SLAs. The DefectDojo Pro GitLab Downstream Connector turns the findings that need action into issues in the right GitLab project, sets a priority from the finding's severity, and moves the issue to closed when the finding is mitigated, marked false positive, or risk-accepted. Developers work the issue, and the security team keeps the full history in DefectDojo.

Why GitLab Issues Matters

Findings only get fixed when they reach the people who own the code. For teams that build in GitLab, that means a GitLab issue.

• Developers see security work in the same backlog, boards, and milestones as feature work, so it gets estimated and scheduled instead of deferred.
• Issues can be referenced from merge requests, which ties a fix back to the change that delivered it.
• Project-level issue trackers match how GitLab teams are already organized, so routing a finding to a project usually routes it to the right team.
• A finding that never becomes a ticket tends to stay open. A finding that becomes a ticket with no link back to the scanner result is hard to verify once closed.

Advantages of This Integration

What we gained by pushing findings from DefectDojo into GitLab Issues:

• Only deduplicated findings become tickets. Scanner output is deduplicated and triaged in DefectDojo first, so developers get one issue per real problem rather than one per scanner hit.
• Severity becomes priority. The default mapping writes DefectDojo severity to a Priority value from 1 (Info) to 5 (Critical), so the issue carries the same urgency the finding has in DefectDojo.
• Status stays in step. Active findings map to opened. Closed, false positive, and risk-accepted findings map to closed by default, and you can map them to separate GitLab statuses if your projects define them.
• Control over what gets pushed. Each assignment can push manually, create issues automatically for new findings, update existing issues on edit, or both, with optional filters for minimum severity and active findings only.
• Traceability in both directions. Each linked finding shows the ticket ID, a direct link to the issue, and a changelog of when DefectDojo created or last changed it.
• Finding Groups as single issues. When related findings are grouped in DefectDojo, the group can be pushed as one issue instead of dozens.

How This Integration Works

Pushing findings to GitLab Issues is a Downstream Connector, and Downstream Connectors are a DefectDojo Pro feature. Community Edition's built-in issue tracking integration is Jira only. The connector is set up by a superuser under Connect > Downstream, and some DefectDojo docs list it as GitLab Boards.

Do not confuse this with the GitLab Upstream Connector, which is also a DefectDojo Pro feature but works in the other direction. That one is an Asset Connector: it reads the projects your token can access and creates a DefectDojo Asset for each, grouped into Organizations by GitLab namespace, and it imports no findings. Results from GitLab's own security scanners come in through separate parsers such as GitLab SAST Report and GitLab Dependency Scanning Report. You can run all three together.

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

1. Create the Integration Instance.

• Label: a name that identifies this GitLab connection.
• Location: your GitLab URL, for example https://gitlab.com/ or the base URL of a self-managed instance.
• Token: a GitLab personal access token with API scope. A dedicated service account keeps ticket activity separate from individual users.

2. Create an Issue Tracker Mapping. Enter the Project Name of the GitLab project that should receive issues. Then review the severity and status mappings. The defaults are:

• Severity Field Name Priority: Info 1, Low 2, Medium 3, High 4, Critical 5
• Status Field Name Status: Active opened, Closed closed, False Positive closed, Risk Accepted closed

GitLab issues are opened or closed by default. If you want false positives or accepted risks to stay distinguishable in GitLab, add the extra statuses on the GitLab side (GitLab documents this under work item status) and point the mappings at them. Create one Mapping per GitLab project you push to.

3. Assign Assets or Engagements. An Issue Tracker Assignment links one Asset or one Engagement to a Mapping and sets how pushes happen:

• Only Explicitly Publish Changes to Target: nothing automatic. Use Push to Integrator on a finding or Finding Group.
• Automatically Link New Finding to Target: new findings create issues, but later edits wait for a manual push.
• Automatically Update Existing Link on Finding Edit: edits update issues that were already linked by hand.
• Automatically Link New and Update Existing Link on Finding Edit: both.

Optional push filters limit automatic creation to a Minimum Severity and to Active findings only. Filters never block updates to an issue that already exists, so closures keep flowing, and a manual push ignores them. To cover several Assets, create one Assignment for each.

Data Granularity: What Gets Sent

The connector pushes outward. Built-in two-way sync, where ticket changes flow back to findings, is documented for Jira only today.

Use Cases

Routing findings to the owning team: A company with one GitLab project per service maps each project to its DefectDojo Asset. New High and Critical findings from that Asset's scans become issues in that project automatically, and lower severities stay in DefectDojo for scheduled review.

Closing the loop on fixes: A developer fixes a dependency and the next scan reimport mitigates the finding in DefectDojo. With update-on-edit enabled, the GitLab issue moves to closed without anyone touching it, and the finding keeps the link to the issue as evidence.

Grouping noisy results: A container base image carries 40 package CVEs. The security team groups them into one Finding Group and pushes a single issue, "update the base image," instead of flooding the board.

Selective escalation: Teams that prefer triage first use explicit publish only. An AppSec engineer reviews each finding, then uses Push to Integrator on the ones worth a developer's time.

Operational Tips

• Start with manual or new-findings-only pushing on one Asset, confirm the issue content and priorities look right, then turn on updates and widen the scope.
• Set Minimum Severity on automatic assignments. Pushing every Info and Low finding is the fastest way to get the integration ignored.
• Decide whether false positives and accepted risks need their own GitLab status. With the defaults they all look like a normal closed issue on the GitLab side.
• Check that the GitLab Priority values in your Mapping match how your projects actually prioritize issues, and adjust the defaults if they don't.
• Give the service account access to every project you map. Authentication and permission failures are recorded in the mapping's error table, so check there first after adding a project.
• When a ticket doesn't appear, open the mapping's Total Errors table, or filter Diagnostics to the downstream integrator to see failed or queued pushes across all connectors.
• Keep remediation decisions in DefectDojo. Risk acceptance and false positive marking belong on the finding, where they drive SLAs and reporting, and the connector carries the result to GitLab.