GitLab and Bitbucket repositories
Connect read-only GitLab or Bitbucket account boundaries, discover projects, and explicitly choose which exact revisions Hyperoru may audit.
Hyperoru brings GitLab and Bitbucket repositories through the same evidence pipeline as GitHub without treating account access as permission to audit every project. An Owner or Admin creates a provider connection, Hyperoru discovers visible projects, and every newly discovered project starts outside the audit scope.
Permission boundary
| Provider | Credential | Minimum access | Audit behavior |
|---|---|---|---|
| GitLab.com or self-managed GitLab | Personal, project, or group access token | read_api and read_repository | Clone one selected project at an exact 40-character commit SHA |
| Bitbucket Cloud | Repository or workspace access token | Repositories read | Clone one selected repository at an exact 40-character commit SHA |
Hyperoru encrypts the token with workspace and connection identity as associated data. The API returns only has_credential; neither a workspace response nor the operator dashboard can retrieve the token. Repository contents are processed by the isolated runner and are not made available to the admin control plane.
Read does not become write
GitLab and Bitbucket connections are audit-only. Remediation publication requires a separate, provider-specific write authorization and is currently available only through a human-approved GitHub workflow. Hyperoru never reuses a read token to push code.
Connect and select projects
- Open Repositories → Repository providers.
- Choose GitLab or Bitbucket.
- Name the connection and enter its account boundary and write-only token.
- Review the discovered project inventory.
- Select only the projects Hyperoru may audit.
A later sync preserves existing selections. Newly discovered projects remain unselected, and projects no longer visible to the provider token are archived and disabled instead of silently disappearing from history. Revoking the connection disables every linked project while preserving past audits and reports.
GitLab host validation
GitLab.com is supported directly. A self-managed GitLab base URL must use public HTTPS, must not contain credentials, and must resolve outside loopback, link-local, private, multicast, reserved, and unspecified networks. API redirects are disabled. Project clone and web URLs must stay on the authorized GitLab host.
Bitbucket connections use the fixed api.bitbucket.org and bitbucket.org boundaries. A workspace slug identifies the inventory boundary.
Sync and support diagnostics
The workspace sees connection state, account, project count, last sync time, and a safe error code. Platform operators see the same boundary and health metadata plus the number of projects explicitly selected. Tokens, repository archives, and source payloads are excluded from operator responses.
Use deterministic merge checks after selecting a project. The check submits the provider's full merge commit and refuses to enforce a result produced by a different concurrent audit.