---
title: Repository Connection & Security
description: How CodeDD securely connects to your Git repositories
category: Software Audit
order: 2
---

# Repository Connection & Security

CodeDD connects to repositories through industry-standard authentication. Cloud audits clone to ephemeral processing environments; the [CLI](/documentation/codedd-cli-guide) 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](#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](/documentation/dora-metrics-and-deployment-mapping). CodeDD never pushes, comments, or changes settings with it.

#### How each provider connects

| Provider | Mechanism | Access requested | What limits it |
|----------|-----------|------------------|----------------|
| GitHub (github.com) | CodeDD **GitHub App**, user access token | Read-only App permissions: **Contents**, **Metadata**, **Pull requests**, **Issues**, **Deployments**; **Actions** only when CI runs count as deploys | Repositories selected on each App installation, intersected with what your GitHub user can see |
| GitHub Enterprise Server | OAuth App registered on your instance | `read:user`, `repo`, `read:org` | Repositories your GitHub user can see |
| GitLab (gitlab.com and self-managed) | OAuth application | `read_user`, `read_api`, `read_repository` | Projects your GitLab user can see |
| Bitbucket Cloud | OAuth consumer | `account`, `repository`, `pullrequest`, `pipeline` | Workspaces and repositories your Bitbucket user can see |
| Azure DevOps | Microsoft Entra ID app | Azure DevOps `user_impersonation`, plus `openid`, `profile`, `email`, `offline_access` | Organizations and projects your Microsoft account can see |

**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:

| Permission | Level | Used for |
|------------|-------|----------|
| Metadata | Read | Listing repositories, branches, and installation details (required by every GitHub App) |
| Contents | Read | Cloning the repository for audits; reading commits and release tags |
| Pull requests | Read | Lead time, rework, and change-failure linking for DORA |
| Issues | Read | Incident detection for DORA |
| Deployments | Read | Deployments and environments for DORA |
| Actions | Read | Workflow runs, only when the organization counts CI runs as deploys |

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](/documentation/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](/documentation/portfolio-monitoring)
- [File Discovery & Indexing](/documentation/file-discovery-indexing)
- [Data Encryption at Rest](/documentation/data-encryption-at-rest)
- [Secure Data Deletion](/documentation/secure-data-deletion)
- [CodeDD CLI Guide](/documentation/codedd-cli-guide)