GitLab Issues export

Before choosing GitLab Issues

Use GitLab Issues export when the customer tracks remediation in GitLab SaaS or a self-managed GitLab project. GitLab needs the destination project, labels, milestone and confidential issue state before WebRiskOps can safely create or update an issue. Start from `/reports/{report}/ticket-exports` after the report finding or generated fix task is ready for handoff. For self-managed GitLab, confirm the host is safe before sending issue data.

Export a GitLab Issue

Follow the path `Ticket export source → GitLab Issues target → Project mapping → Duplicate check → GitLab Issue or fallback`.

1. Open /reports/{report}/ticket-exports and select the report issue or generated fix task that belongs in GitLab Issues. Result: source_type, source_id, severity, affected URL and evidence-safe links are visible before GitLab receives work.
2. Choose an active gitlab_issues or gitlab_self_managed_issues target for the same account and project. Result: provider_key and deployment mode match the GitLab project that will receive the issue.
3. For self-managed GitLab, confirm the base URL passed URL safety and private-network policy checks. Result: WebRiskOps does not send issue data to an unsafe or unreachable GitLab host.
4. Set gitlab_project_id or the approved project path before export. Result: GitLab knows which project owns the issue.
5. Map labels, milestone and confidential state from the customer project settings. Result: the issue lands in the right GitLab workflow with the expected visibility.
6. Review summary, affected URL, reproduction steps, evidence-safe links and acceptance criteria. Result: the issue body is useful without exposing raw private artifacts or secrets.
7. Check external_issue_id and TICKET_EXPORT_DUPLICATE before approval. Result: repeat exports update or link the existing GitLab Issue instead of creating duplicate project work.

Map GitLab fields

GitLab export needs explicit destination fields.

• gitlab_project_id or an approved project path identifies the GitLab project that owns remediation work.
• labels and milestone mapping should connect finding category, severity, customer routing tags and release planning without exposing private artifact details; review labels and milestone together before approval.
• milestone should be set only when the customer routes remediation by release or sprint.
• confidential should match the customer's policy for sensitive security findings.
• external_issue_id links repeat exports back to the existing GitLab Issue instead of creating duplicate work.
• Issue body should include summary, affected URL, reproduction steps, evidence-safe links and acceptance criteria.

Ready GitLab Issues export states

Continue only when the GitLab target and project mapping are clear.

• GitLab SaaS target ready means `gitlab_issues` is active for the same account and project as the report.
• Self-managed target ready means `gitlab_self_managed_issues` is active and the self-managed base URL is safe.
• Project mapping ready means gitlab_project_id points to the project that owns issue tracking for the affected product area.
• Confidential state ready means the issue visibility matches the customer's security policy.
• Duplicate reference ready means an existing external_issue_id can be opened or updated through Status sync and duplicate handling.

Blocked GitLab Issues states

Self-managed GitLab must fail closed when the URL or credential is unsafe.

• `gitlab_project_mapping_missing` means choose a GitLab project mapping before exporting.
• `gitlab_target_inactive` or `gitlab_credential_missing` means reconnect GitLab before retrying.
• The GitLab self-managed URL is not allowed when the target fails private-network policy; use GitLab.com, an approved allowlist/tunnel policy or portable fallback.
• GitLab field validation errors mean review project, labels, milestone, assignee and confidential issue mapping.
• Rate limiting keeps the attempt retry scheduled; do not approve a duplicate source.
• Secret or private artifact in preview means redact evidence before creating or updating the GitLab Issue.

Continue after GitLab Issues export

Continue to Bitbucket export when the customer uses Bitbucket issue tracking instead of GitLab. Use Status sync and duplicate handling when a GitLab Issue already exists, Portable export fallbacks when GitLab is unavailable, and Cloud and self-hosted distinctions when a self-managed GitLab host is not clearly safe.