GitLab.com and self-managed GitLab setup

Before connecting GitLab

Use this page when the customer wants WebRiskOps to create or update GitLab Issues in GitLab.com or a self-managed GitLab project. GitLab setup decides which GitLab host and project boundary can receive tickets before labels, milestones or confidential issue settings are mapped. Start from `/settings` after Cloud and self-hosted integrations confirms the deployment mode. Do not save GitLab credentials until the customer-owned namespace, base URL, auth method and network path are clear.

Connect a GitLab Issues target

Follow the path `Cloud and self-hosted integrations → GitLab target → Auth and network check → Project issue mapping → GitLab Issues export or fallback`.

1. Open /settings and review Integration status, then choose GitLab.com or self-managed GitLab setup. Result: provider_key is recorded as gitlab_issues or gitlab_self_managed_issues before project fields are requested.
2. For GitLab.com, confirm the customer-owned group or project namespace and choose OAuth or scoped token auth_method. Result: credentials are limited to the GitLab SaaS projects that can receive issues.
3. For self-managed GitLab, enter base_url only after the customer confirms ownership, reachable API root and scan or export authorization. Result: deployment_mode is self-hosted and private-network checks run before tokens are accepted.
4. Select scopes for project metadata, issue creation and issue updates. Result: WebRiskOps can validate gitlab_project_id, labels, milestone and confidential issue state later without asking for broader access.
5. Confirm project discovery uses only the approved group, namespace or project path. Result: unrelated GitLab projects do not appear in ticket export mapping.
6. Review allowlist_status for self-managed GitLab. Result: firewall, VPN or approved tunnel state is visible before WebRiskOps tries provider API calls.
7. Save only when provider auth and network checks are ready. Result: the GitLab Issues target is available to ticket export without exposing secrets in documentation or support messages.
8. If PROVIDER_AUTH_REQUIRED appears, reconnect OAuth or the access token before retrying. Result: the target stays blocked until valid credentials exist.
9. If PROVIDER_BASE_URL_BLOCKED or PROVIDER_SCOPE_UNAVAILABLE appears, fix the URL or scope, or use portable fallback. Result: unsafe self-managed hosts and unavailable GitLab permissions do not receive evidence.
10. Continue to GitLab Issues export after setup. Result: project mapping and duplicate handling use the same GitLab provider record.

Configure GitLab authorization

GitLab setup should keep issue export scoped to the customer's approved project boundary.

• `gitlab_issues` is for GitLab.com issue export into customer-owned groups or projects.
• `gitlab_self_managed_issues` is for self-managed GitLab hosts with `base_url`, explicit authorization and network checks.
• `auth_method` should identify OAuth or access token setup before a credential is saved.
• `scopes` should allow project metadata, issue creation and issue updates, not unrelated admin access.
• Project discovery should be constrained to the approved group, namespace or project path.
• Revoke access in GitLab first, then disconnect the GitLab target in WebRiskOps so historical reports keep references without keeping live credentials.

Ready GitLab integration states

Continue only when the target and project boundary are clear.

• GitLab.com target ready means `provider_key` is `gitlab_issues`, the customer-owned namespace is confirmed and credentials are active.
• Self-managed target ready means `provider_key` is `gitlab_self_managed_issues`, `deployment_mode` is self-hosted and `base_url` passed URL safety checks.
• Issue scope ready means `scopes` allow project metadata, issue creation and issue updates for the approved project boundary.
• Network ready means `allowlist_status` shows the self-managed target is reachable through a safe direct, allowlisted or customer-approved tunnel path.
• Project boundary ready means GitLab project discovery is constrained before GitLab Issues export mapping begins.

Blocked GitLab setup states

Blocked GitLab setup should fail closed when host, auth or project access is unclear.

• `PROVIDER_AUTH_REQUIRED` means reconnect OAuth or the GitLab access token before saving or retrying export.
• `PROVIDER_BASE_URL_BLOCKED` means the self-managed GitLab URL failed ownership, redirect, DNS, reserved-IP or private-network checks.
• `PROVIDER_SCOPE_UNAVAILABLE` means the saved auth method cannot read project metadata, create issues or update GitLab issues.
• Missing `allowlist_status` means the self-managed target cannot be trusted for automated provider calls yet.
• Disabled Issues, missing group membership, protected network rules or unavailable project permissions can still block GitLab Issues export after setup.

Continue after GitLab setup

Continue to GitLab Issues export when the target is active and project mapping can begin. Use Status sync and duplicate handling when a GitLab Issue already exists, Portable export fallbacks when GitLab cannot be made safe, or Bitbucket Cloud and Data Center setup when the remediation team works from Bitbucket instead.