Repository Connection & Security

Repository Connection & Security

Overview

CodeDD connects to your repositories through secure, industry-standard authentication methods. We support all major Git providers and employ multiple layers of security to protect your credentials and source code.

Supported Git Providers

CodeDD integrates with all major Git hosting platforms:

• GitHub (github.com and GitHub Enterprise)
• GitLab (gitlab.com and self-hosted GitLab)
• Azure DevOps (dev.azure.com)
• Bitbucket (bitbucket.org and Bitbucket Server)
• Generic Git (Any Git server accessible via HTTPS or SSH)

Authentication Methods

Personal Access Tokens (PAT) - Recommended

Personal Access Tokens are the preferred authentication method for most use cases:

Advantages:

• Fine-grained permissions control
• Easy to create and revoke
• No exposure of primary credentials
• Provider-specific scope configurations

GitHub:

Requires: repo (read) scope
Format: https://<token>@github.com/owner/repo.git

GitLab:

Requires: read_repository scope
Supports multiple authentication formats:
- oauth2 format (recommended)
- token-only format
- gitlab-ci-token format

Azure DevOps:

Requires: Code (Read) permission
Format: https://pat:<token>@dev.azure.com/org/project/_git/repo

Bitbucket:

Requires: Repository read permission
Format: https://email:token@bitbucket.org/workspace/repo.git

SSH Keys

CodeDD supports SSH key authentication for repositories requiring it:

• ED25519 keys (preferred for modern security)
• RSA keys (for legacy system compatibility)

SSH keys are securely stored in encrypted vaults and automatically rotated after use.

Connection Process

Step 1: Credential Validation

When you provide repository credentials:

1. Credentials are encrypted immediately upon receipt
2. Stored in secure, encrypted key vaults
3. Never logged or exposed in error messages
4. Access keys are masked in all system outputs

Step 2: Repository Access

CodeDD attempts authentication in this order:

1. PAT Authentication (if available)

   • Connects using your Personal Access Token
   • Validates read permissions
   • If authentication fails, provides clear guidance

2. Public Repository (if applicable)

   • Attempts unauthenticated HTTPS access
   • Only for publicly accessible repositories

3. SSH Authentication (fallback)

   • Uses stored SSH keys if PAT fails
   • Tries ED25519 first, then RSA

Step 3: Clone to Ephemeral Environment

Once authenticated:

• Repository is cloned to an isolated, encrypted container
• Container exists only for the duration of the audit
• No persistent storage—everything is in-memory where possible
• Network-isolated environment prevents data leakage

Security Measures

Credential Protection

Storage:

• All credentials encrypted at rest using AES-256
• Stored in dedicated, access-controlled vaults
• Automatically rotated after each use
• Separate encryption keys per customer

Access:

• Zero-knowledge architecture—our team cannot access your credentials
• Credentials never transmitted in plain text
• All communication over TLS 1.3
• Strict access logs for compliance

Repository Isolation

Each repository clone operates in complete isolation:

• Ephemeral Containers: Destroyed after audit completion
• Network Isolation: No internet access during processing
• File System Encryption: All files encrypted immediately after clone
• Memory Protection: Sensitive data cleared from memory after use

Audit Trail

Complete audit trail for compliance:

• When repositories were accessed
• Which credentials were used (not the actual credentials)
• Success/failure of authentication attempts
• No source code is ever logged

What Happens to Repository Access

During Audit

• Repository cloned to encrypted, ephemeral container
• Access token valid only for clone operation
• No ongoing repository access after initial clone
• Cannot push changes back to repository

After Audit

• Clone immediately deleted using secure wiping
• Access credentials purged from active memory
• Encryption keys destroyed
• Container completely removed

Common Scenarios

Private Repositories

For private repositories:

1. Create a read-only Personal Access Token
2. Scope token to minimum required permissions (read-only)
3. Provide token to CodeDD through secure interface
4. Token is encrypted and stored in vault
5. After audit, you can revoke the token (optional)

Enterprise Repositories

For enterprise Git servers:

1. Create service account with read-only access
2. Generate PAT or SSH key for service account
3. Provide connection details (URL, credentials)
4. CodeDD connects through your network (on-premise) or via secure tunnel (cloud)
5. All standard security measures apply

Multiple Repositories

For portfolio audits:

1. Use organization-level PAT (read-only across repos)
2. Or provide individual tokens per repository
3. CodeDD processes each repository in isolation
4. Results aggregated at portfolio level

Error Handling

Authentication Failures

If authentication fails, CodeDD provides clear guidance:

Permission Errors:

"PAT authentication failed: Please ensure your token has 
the 'read_repository' scope and access to this project."

Network Errors:

"Unable to reach repository: Please verify the URL and 
ensure your Git server is accessible."

Automatic Fallback

If PAT authentication fails:

• CodeDD does NOT automatically fall back to SSH
• This prevents unintended credential exposure
• You'll receive explicit error message
• Can then choose to provide SSH keys if appropriate

Best Practices

For Investors & Advisors

1. Request Read-Only Access: Always ask portfolio companies for read-only tokens
2. Time-Limited Tokens: Use tokens that expire after due diligence completes
3. Audit-Specific Accounts: Have portfolio companies create service accounts specifically for audits
4. Verify Scope: Confirm tokens have minimal required permissions

For Portfolio Companies

1. Create Service Accounts: Don't use personal developer accounts
2. Limit Token Scope: Repository read-only access only
3. Set Expiration: Configure tokens to expire after agreed period
4. Revoke After Audit: You can revoke tokens once audit completes
5. Monitor Access: Review audit logs in your Git provider

Compliance & Standards

CodeDD's repository connection process adheres to:

• SOC 2 Type II compliance for credential handling
• ISO 27001 information security standards
• GDPR requirements for data protection
• NIST cryptographic standards for encryption

Next Steps

• Learn about File Discovery & Indexing
• Understand Data Encryption
• Review Secure Data Deletion