Repository Connection & Security

CodeDD connects to repositories through industry-standard authentication. Cloud audits clone to ephemeral processing environments; the CLI offers a local-first alternative where source never leaves your infrastructure.

Supported Git providers#

OAuth-integrated (recommended in the web UI):

• GitHub (github.com)
• GitLab (gitlab.com)
• Azure DevOps
• Bitbucket

Self-managed servers — GitLab self-managed and GitHub Enterprise Server (also for a *.ghe.com address) connect with a personal access token. See Self-managed GitLab and GitHub Enterprise Server.

Additional HTTPS hosts may be accepted when the URL matches CodeDD's validated hosting allowlist (e.g. Codeberg, Gitee). A self-hosted URL is accepted once its server is connected to your account; other self-hosted URLs are rejected at validation.

CLI local scope: any Git repository root on your machine — no cloud clone required.

Authentication methods#

OAuth (recommended)#

For GitHub, GitLab, Azure DevOps, and Bitbucket:

1. Click Connect in the repository import flow
2. Sign in at your Git provider and approve CodeDD's access request
3. Pick the organization, group, or workspace, then the repositories to import

The connection belongs to your CodeDD account, one per Git host. The same token clones repositories for audits and reads delivery data for DORA metrics. CodeDD never pushes, comments, or changes settings with it.

How each provider connects#

GitHub (github.com) uses a GitHub App, not an OAuth App, so there are no OAuth scopes. Access has three limits at once: the App's read-only permissions, the repositories an organization owner selected when installing the App, and your own GitHub access. A repository missing from any of the three cannot be read. Installing the App on another organization adds that organization's selected repositories; it does not create a second login. An organization owner may have to approve the installation first. User access tokens expire after eight hours and are refreshed automatically.

What each GitHub App permission is used for:

When CodeDD adds a permission, GitHub asks an organization owner to approve it. Until then, the dashboard shows Additional Git permissions needed and the features that rely on it stay off.

GitHub Enterprise Server has no CodeDD GitHub App. Your administrator registers an OAuth App on the instance and enters its client ID and secret in CodeDD. GitHub OAuth has no read-only repository scope, so repo technically allows writes; CodeDD only issues read requests. The administrator can narrow the requested scopes per instance.

GitLab scopes are all read-only: read_user identifies you, read_repository clones over HTTPS, and read_api lists groups and projects and reads merge requests, pipelines, deployments, environments, and issues. For a self-managed instance, your administrator registers an OAuth application on it and enters the client ID and secret in CodeDD.

Bitbucket Cloud scopes are the read variants: account identifies you, repository clones and lists repositories, pullrequest reads pull requests, and pipeline reads pipeline runs and deployments. CodeDD requests none of the :write or :admin scopes. Bitbucket Data Center and Server are not supported through OAuth.

Azure DevOps signs in through Microsoft Entra ID. Azure DevOps has one delegated OAuth scope, user_impersonation, which acts with your own Azure DevOps permissions; it is not narrower than your user. CodeDD uses it only to read repositories, pull requests, builds, releases, environments, and work items. openid, profile, and email identify you; offline_access issues the refresh token. To limit what CodeDD can reach, connect with a service account that only has Reader access to the projects in scope. Azure DevOps Server (on-premises) is not supported through OAuth.

Sign-in and token handling#

• Every authorization uses PKCE and a one-time state value bound to your CodeDD account; it expires after ten minutes and works only once.
• Access and refresh tokens are encrypted (Fernet) before storage, together with the granted scopes and expiry.
• Expired access tokens are refreshed automatically. If the provider refuses the refresh (grant revoked, refresh token expired), CodeDD asks you to reconnect.
• Disconnect in Account Settings deletes the stored tokens and the DORA access granted through them. CodeDD also revokes the token at GitLab; for GitHub, Bitbucket, and Azure DevOps, revoke the authorization at the provider as well:
  • GitHub: Settings → Applications → Authorized GitHub Apps; organization owners uninstall under Installed GitHub Apps
  • Bitbucket: Personal settings → App authorizations
  • Azure DevOps / Entra ID: My Apps → Manage your applications (myapps.microsoft.com)

Personal access tokens (PAT)#

Use when OAuth is unavailable or for automation. Scope to minimum read permissions:

• GitHub — repo, read:user, read:org
• GitLab — read_api, read_repository
• Azure DevOps — Code (Read)
• Bitbucket — repository read

Each CodeDD account holds one token per provider. Saving a new GitLab or GitHub token replaces the previous one, whether it was for the cloud or for a self-managed server.

Self-managed GitLab and GitHub Enterprise Server#

For a server your company runs, such as https://gitlab.example.com:

1. In the import dialog, choose Self-Managed on the GitLab card or GitHub Server on the GitHub card.
2. Enter the Server address and choose Continue to GitLab or Continue to GitHub. The token step opens with Self-managed GitLab or GitHub Enterprise Server selected and your address filled in.
3. Create a token on that server; the dialog links to the right page:
   • GitLab — a personal access token with read_api and read_repository
   • GitHub Enterprise Server — a classic personal access token with repo, read:user, and read:org
4. Paste the token and choose Connect & Continue. CodeDD checks it against your server before saving it and sends it to that server only.

Next time, the same steps list your repositories with the saved token. The or use a Personal Access Token link on a card opens the same token step while no token is saved for that provider; once one is saved, the link lists repositories with it, so add a token for another server with Self-Managed or GitHub Server.

The server must be reachable from the internet over HTTPS, with a certificate from a public certificate authority. Plain HTTP, IP addresses, and names that resolve to a private network are refused. If CodeDD has set up single sign-on for your server, Continue to GitLab or Continue to GitHub opens your server's sign-in window instead of the token step.

SSH keys#

Supported as a last resort when OAuth and PAT are unavailable. ED25519 (preferred) and RSA keys are stored encrypted. CodeDD does not silently fall back to SSH when PAT fails — you get an explicit error instead.

Connection order#

1. OAuth token (if previously authorized)
2. PAT (if provided)
3. Public HTTPS (public repos only)
4. SSH (only when configured)

If PAT authentication fails, CodeDD does not silently fall back to SSH. You receive an explicit error and can choose to configure SSH separately.

Clone to Ephemeral Environment#

Once authenticated:

• Repository cloned to an isolated processing environment
• Environment exists only for the audit duration
• Files encrypted at rest during processing (Fernet)
• Environment destroyed and source securely wiped on completion

Security Measures#

Credential Protection#

• Credentials encrypted at rest (Fernet) in secure storage
• Never logged or exposed in error messages
• Masked in all system outputs
• Revocable at any time from your Git provider

Credentials are not rotated automatically after each use — you control token lifecycle via your provider or by revoking CLI tokens in Account → CLI Access.

Repository Isolation#

• Ephemeral processing environments per audit
• Restricted network egress (required services only — LLM APIs, vulnerability DBs)
• Files encrypted immediately in the audit cache
• Sensitive data cleared from memory after use

Audit Trail#

• Repository access timestamps logged
• Authentication success/failure recorded (not credential values)
• Source code never written to application logs

What Happens After Connection#

During audit:

• One-time clone (cloud) or local scope registration (CLI)
• Read-only — no push access, no ongoing polling

After audit:

• Clone deleted via secure wipe
• Processing environment destroyed
• Only findings and metadata retained

Security measures#

• Credentials encrypted at rest, never logged in plaintext
• Ephemeral processing environments per audit
• Restricted network egress to required services only
• Files encrypted in the audit cache immediately after indexing
• Access timestamps and auth success/failure logged (not credential values)

Credentials are not rotated automatically — you control token lifecycle via your Git provider or by revoking CLI tokens in Account → CLI Access.

Common scenarios#

Private repositories — OAuth or read-only PAT; revoke after audit if desired.

Portfolio / group audits — OAuth or PAT on the person who imports; each repository is processed in isolation and results aggregate at portfolio level.

Portfolio Monitoring (an initial audit, then quarterly audits of changed code) — the Git token stays on that person; each enrolled company has its own approved repository list. Between audits CodeDD keeps each file's path and the Git identifier of the version it reviewed; the clone itself is deleted after each audit. See Portfolio Monitoring.

Enterprise / air-gapped — use the CLI to run analysis locally and sync only structured results. This also covers a self-managed Git server that is not reachable from the internet.

Best practices#

For investors & advisors: request read-only OAuth or PAT; use time-limited service accounts; prefer CLI for highly sensitive source.

For portfolio companies: dedicated audit service accounts; read-only scope; revoke tokens after due diligence.

Next steps#

• Portfolio Monitoring
• File Discovery & Indexing
• Data Encryption at Rest
• Secure Data Deletion
• CodeDD CLI Guide