Connecting Repositories

GitHub

GitHub is connected via a GitHub App — not a personal access token, not OAuth-with-broad-scopes. This means:

• Access is scoped to exactly the repositories you pick during installation, not every repo you can see.
• The app authenticates as itself using short-lived installation tokens, minted on demand and never stored — nothing long-lived to leak.
• Webhooks (push, pull request) are delivered automatically the moment you grant access; there's nothing separate to configure per-repository.

To connect: Settings → Git Providers → GitHub. You'll be redirected to GitHub to pick an account/organization and choose "All repositories" or select specific ones — you can change this later from GitHub's own installation settings page, linked from the "Edit GitHub access" button next to your connection.

If your GitHub App's access to a repository is ever revoked or suspended, a banner appears across the app immediately (driven by GitHub's installation webhook — no need to wait for a scan to fail first), with a direct link back to reconnect.

GitLab

GitLab is connected via OAuth2, scoped to gitlab.com (not self-hosted GitLab instances). Unlike GitHub Apps, GitLab has no installation-level access model — the connection covers whatever projects the authorizing GitLab account can see, at the time you connect.

A few things that work differently from GitHub as a result:

• Webhooks are registered per-project, not automatically — this happens the first time you enable scanning on a given repository, not at connect time.
• Access tokens expire (2 hours) and are refreshed automatically in the background — you won't notice this, but it's why GitLab's connection, unlike GitHub's, has to persist a (encrypted) credential rather than minting one fresh per request.
• If the OAuth authorization is revoked from GitLab's side, this is discovered the next time we try to use it (there's no equivalent push notification GitLab sends us the way GitHub's installation webhook does) — you'll see the same access-issue banner once that happens.

To connect: Settings → Git Providers → GitLab, authorize on GitLab's consent screen, then pick which projects to enable from the picker.

Selecting repositories

Neither connection method turns scanning on by default. After connecting, you land on a picker listing everything the provider granted access to — toggle on the repositories you actually want scanned. This list is also where you'll notice if a repository you expected isn't showing up, which usually means the provider-side access grant needs adjusting (the picker links directly to the right settings page for that).

Disconnecting

Disconnecting a provider from Settings → Git Providers permanently deletes every repository, scan, and finding connected through it — this does not undo the access grant on GitHub/GitLab's side. If you also want to revoke access there, do that separately from the provider's own settings (linked from the connection row).