GitHub Issues export

Before choosing GitHub Issues

Use this page when the customer wants an external GitHub Issue, not repository remediation access. GitHub Issues export creates or updates an issue in a repository issue tracker while WebRiskOps keeps evidence, source identifiers and duplicate state inside the product. Start from `/reports/{report}/ticket-exports` after the source finding or generated fix task is ready for handoff. If the customer needs source-code indexing, patch generation or pull request creation, use the repository remediation path instead of this issue-only export.

Export a GitHub Issue

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

1. Open /reports/{report}/ticket-exports and select the report issue or generated fix task that belongs in GitHub Issues. Result: source_type, source_id, severity, affected URL and evidence-safe links are visible before GitHub receives work.
2. Choose an active github_issues or github_enterprise_issues target for the same account and project. Result: provider_key and deployment mode match the repository issue tracker.
3. Confirm this is an issue-only handoff, not repository remediation access. Result: WebRiskOps does not request source-code indexing, patch generation or pull request permissions for this export.
4. Set repository_full_name in owner/repository format. Result: GitHub knows which repository owns the issue.
5. Map issue_labels, assignees and milestone when the customer configured them. Result: the GitHub Issue lands in the right repository workflow with useful routing context.
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 GitHub Issue instead of creating duplicate repository work.

Map repository issue fields

GitHub needs repository mapping before the export can be queued.

• repository_full_name identifies the GitHub repository in owner/repository format.
• issue_labels should map finding category, product area and an optional webriskops tracker label.
• assignees should be used only when the customer configured valid GitHub usernames for the destination repository.
• milestone should be set only when the customer routes remediation by release or sprint.
• external_issue_id links repeat exports back to the existing GitHub Issue instead of creating duplicate work.
• Issue body should include summary, affected URL, reproduction steps, evidence-safe links and acceptance criteria.

Ready GitHub Issues export states

Continue only when the issue-only target and repository mapping are clear.

• GitHub.com target ready means `github_issues` is active for the same account and project as the report.
• Enterprise target ready means `github_enterprise_issues` is active and the Enterprise base URL has passed self-hosted safety checks.
• Repository mapping ready means repository_full_name points to the repository that owns issue tracking for the affected product area.
• Preview ready means the issue body is evidence-safe and does not expose raw private artifacts.
• Duplicate reference ready means an existing external_issue_id can be opened or updated through Status sync and duplicate handling.

Blocked GitHub Issues states

Do not bypass GitHub Enterprise safety checks.

• `github_issues_repository_missing` means choose a GitHub repository mapping before exporting.
• `github_issues_target_inactive` or `github_issues_credential_missing` means reconnect or verify GitHub Issues before retrying.
• The GitHub Enterprise URL is not allowed when the self-hosted target fails private-network policy; use GitHub.com, an approved allowlist/tunnel policy or portable fallback.
• GitHub field validation errors mean review the repository, labels, milestone and assignee mapping, then retry.
• Rate limiting means wait for the automatic retry and avoid approving the same source again.
• `REPOSITORY_ACCESS_REQUIRED` means the customer chose a code-remediation path, not an issue-only export.
• Secret or private artifact in preview means redact evidence before creating or updating the GitHub Issue.

Continue after GitHub Issues export

Continue to GitLab Issues export when the customer uses GitLab instead of GitHub. 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, and Portable export fallbacks when GitHub Issues is unavailable.