GitHub.com and GitHub Enterprise Server setup

Before connecting GitHub

Use this page when the customer wants WebRiskOps to create or update GitHub Issues, or when they need to decide whether the repository remediation flow is a better fit. GitHub setup should separate issue-only ticket export from source-code remediation access before any credential is saved. Start from `/settings` after Cloud and self-hosted integrations confirms whether the target is GitHub.com or GitHub Enterprise Server. Do not save a GitHub target until the customer-owned account, repository boundary, auth method and network path are clear.

Connect a GitHub Issues target

Follow the path `Cloud and self-hosted integrations → GitHub target → Issue-only or repository-remediation decision → Auth and network check → GitHub Issues export or repository connection`.

1. Open /settings and review Integration status, then choose GitHub.com or GitHub Enterprise Server setup. Result: provider_key is recorded as github_issues or github_enterprise_issues before repository fields are requested.
2. For GitHub.com, confirm the customer-owned user or organization that owns the destination repository and choose GitHub App or token auth_method. Result: credentials are limited to selected repositories and Issues.
3. For GitHub Enterprise Server, 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. Choose issue-only scopes when the customer only needs GitHub Issues export. Result: WebRiskOps can create or update issues without repository remediation permissions.
5. Use GitHub repository connection instead when the customer needs code indexing, patch generation or pull requests. Result: the issue-only target is not over-scoped for remediation automation.
6. Review allowlist_status for GitHub Enterprise Server. 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 GitHub Issues target is available to ticket export without exposing secrets in documentation or support messages.
8. If PROVIDER_AUTH_REQUIRED appears, reconnect the GitHub App, OAuth grant or 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 Enterprise hosts and unavailable GitHub permissions do not receive evidence.
10. Continue to GitHub Issues export after setup. Result: repository mapping and duplicate handling use the same GitHub provider record.

Configure GitHub authorization

GitHub setup must explain whether the customer is authorizing issue-only export or repository remediation.

• `github_issues` is for GitHub.com issue-only ticket export into selected repositories.
• `github_enterprise_issues` is for customer-owned GitHub Enterprise Server issue-only export with `base_url`, explicit authorization and network checks.
• `auth_method` should identify GitHub App, OAuth or token setup before a credential is saved.
• `scopes` should grant issue creation and issue update only when the customer wants ticket export.
• Repository remediation access belongs to GitHub repository connection, not to the issue-only target.
• Revoke access in GitHub first, then disconnect the GitHub target in WebRiskOps so historical reports keep references without keeping live credentials.

Ready GitHub integration states

Continue only when the target and access mode match the customer workflow.

• GitHub.com issue target ready means `provider_key` is `github_issues`, the customer-owned user or organization is confirmed and credentials are active.
• GitHub Enterprise issue target ready means `provider_key` is `github_enterprise_issues`, `deployment_mode` is self-hosted and `base_url` passed URL safety checks.
• Issue-only scope ready means `scopes` allow Issues work without code indexing, patch generation or pull request access.
• Network ready means `allowlist_status` shows the Enterprise target is reachable through a safe direct, allowlisted or customer-approved tunnel path.
• Repository remediation decision ready means the customer knows when to switch from issue-only export to GitHub repository connection.

Blocked GitHub setup states

Blocked GitHub setup should stop at the exact missing condition.

• `PROVIDER_AUTH_REQUIRED` means reconnect the GitHub App, OAuth grant or token before saving or retrying export.
• `PROVIDER_BASE_URL_BLOCKED` means the GitHub Enterprise URL failed ownership, redirect, DNS, reserved-IP or private-network checks.
• `PROVIDER_SCOPE_UNAVAILABLE` means the saved auth method cannot create or update GitHub Issues for the selected repository.
• Missing `allowlist_status` means the Enterprise target cannot be trusted for automated provider calls yet.
• Disabled Issues, organization SSO, repository selection or missing repository permissions can still block GitHub Issues export after setup.
• A request for code remediation means use GitHub repository connection instead of broadening the issue-only target.

Continue after GitHub setup

Continue to GitHub Issues export when the target is active and issue-only mapping is enough. Use GitHub repository connection when the customer needs source-code remediation, GitHub Enterprise considerations when the Enterprise host is unclear, Status sync and duplicate handling when a GitHub Issue already exists, or GitLab.com and self-managed GitLab setup when the remediation team works from GitLab.