Your source code repository is one of the most valuable assets in your organization. The credentials that provide access to it are correspondingly high-value targets. Yet many organizations treat Git credential management as an afterthought, relying on developer workstation configurations that were never designed for enterprise security.
Git supports multiple authentication mechanisms: HTTPS with passwords or tokens, SSH keys, and credential helpers. Each has different security properties, and the right choice depends on your threat model and organizational requirements.
HTTPS Authentication
Personal Access Tokens (PATs)
GitHub, GitLab, and Bitbucket all support PATs for HTTPS authentication. These tokens replace passwords and can be scoped to specific permissions and repositories.
Scope tokens minimally. A developer who only needs to push to their own repositories should not have a token with admin:org permissions. Use the minimum scope required for each use case.
Set expiration dates. PATs should expire. GitHub supports automatic expiration, and your organization should enforce maximum token lifetimes. A 90-day expiration is a reasonable default.
Rotate tokens on personnel changes. When a developer leaves the organization or changes roles, revoke their PATs immediately. This should be part of your offboarding process.
Credential Helpers
Git credential helpers cache authentication tokens to avoid repeated login prompts. The built-in helpers include store (plaintext file), cache (in-memory with timeout), and platform-specific helpers like osxkeychain and wincred.
Never use git credential-store. It stores tokens in a plaintext file (~/.git-credentials). Any process or user with read access to the home directory can steal the token.
Prefer platform-specific keychain helpers. macOS Keychain, Windows Credential Manager, and Linux Secret Service provide encrypted storage with access controls.
Use Git Credential Manager (GCM). Microsoft Git Credential Manager supports OAuth/OIDC flows, multi-factor authentication, and secure token storage across platforms. It is the recommended approach for organizations.
SSH Key Management
Key Generation
Use Ed25519 keys. Ed25519 provides strong security with shorter keys than RSA. Generate keys with ssh-keygen -t ed25519.
Protect keys with passphrases. SSH keys without passphrases are equivalent to storing passwords in plaintext. Every SSH key used for Git should have a strong passphrase.
Use SSH agent forwarding carefully. Agent forwarding allows your local SSH key to authenticate on remote servers, but a compromised remote server can use your forwarded agent to access any system your key can reach. Prefer ProxyJump or ProxyCommand instead.
Organizational Policies
Require SSH CA certificates. Instead of managing individual authorized_keys files, use SSH certificate authorities. The organization CA signs developer keys, and servers trust the CA. This enables centralized revocation and expiration.
Audit SSH key usage. GitHub Enterprise and GitLab provide audit logs for SSH key authentication. Review these logs regularly for unauthorized access patterns.
Enforce key rotation. SSH keys do not expire by default. Implement organizational policies requiring key rotation on a regular schedule (annually at minimum).
CI/CD Credential Security
CI/CD systems need Git credentials to clone repositories, push tags, and create releases. These credentials are often over-permissioned and poorly managed.
Use deploy keys or machine accounts. Do not use personal developer credentials in CI/CD. Create dedicated machine accounts or deploy keys with the minimum required permissions.
Use short-lived tokens. GitHub Actions supports GITHUB_TOKEN, an automatically generated token scoped to the repository and workflow. Prefer this over PATs stored as secrets.
Use OIDC token exchange. GitHub Actions, GitLab CI, and other platforms support OIDC token exchange, which eliminates the need for stored credentials entirely.
Restrict secret access. CI/CD secrets should be available only to the workflows and branches that need them. GitHub supports environment-based secret access with required approvals.
Monitoring and Detection
Monitor for credential exposure. Use secret scanning tools (GitHub secret scanning, truffleHog, GitLeaks) to detect credentials accidentally committed to repositories.
Alert on suspicious access patterns. Monitor for Git operations from unusual IP addresses, at unusual times, or involving repositories the user does not normally access.
Review access logs. Regularly review Git server access logs and audit events. Look for failed authentication attempts, privilege escalation, and bulk repository cloning.
How Safeguard.sh Helps
Safeguard.sh integrates with your source code management platform to monitor for supply chain risks that originate from credential compromise. Our platform detects unauthorized dependency modifications, monitors for suspicious commit patterns, and provides SBOM generation that tracks the provenance of every component. When combined with proper credential management, Safeguard.sh ensures your source code integrity from commit to deployment.