5 Steps to Harden Git Against Source Code Theft From Tokens and Insiders

How to Execute the Five-Step Git Hardening Protocol

1. Retire long-lived credentials for short-lived, scoped tokens.Audit every personal access token, deploy key, and SSH key in the organization. Revoke tokens with no expiration, admin scope, or access to repositories the owner no longer touches. Replace them with fine-grained tokens limited to specific repositories and permissions, or with just-in-time SSH certificates issued by a certificate authority for per-session authorization, a pattern that replaces long-lived keys and PATs with per-session credentials.Classic PATs are over-permissioned by default and rarely rotated, which makes them among the most frequent vectors for repository compromise. Where your platform supports it, prefer OIDC federation for CI workloads over stored cloud keys, and require phishing-resistant MFA for every account with write access.

   When you finish, the token inventory should show only scoped, expiring credentials, and the MFA enforcement policy should list every write-capable account as compliant.

2. Turn on Git behavior monitoring and anomaly alerting.Enable audit logging on the SCM and stream it to a system that can alert. Configure detections for mass git clone and fetch activity, sudden geographic IP changes for a single identity, off-hours repository downloads, new deploy keys or webhooks, and permission escalations.Monitoring is detective, not preventive. On its own it produces post-incident evidence; paired with Step 1 it shortens the window between a stolen token being used and that token being revoked. Tune alerts toward risky destinations and anomalous volume so legitimate pushes and CI operations do not drown the signal.

   Confirm success by triggering a test alert from a non-corporate IP and verifying it lands in your queue with the correct identity and repository context.

3. Separate fast and slow exfiltration controls.Fast exfiltration is automated API scraping from a compromised credential: hundreds of clones in minutes, from a handful of IPs, at machine speed. Slow exfiltration is a departing engineer pulling repositories incrementally over weeks, often from a sanctioned laptop during working hours. They need different controls, and a program that only addresses one leaves the other open.For fast threats, apply clone rate limits, anomaly detection on volume and velocity, and immediate token revocation on alert. For slow threats, rely on offboarding automation, DLP on endpoints and cloud destinations, and signals such as bulk zipping, external drive copies, and unusual terminal activity before a departure date. Teams building out the detection side of this split can review practical approaches to prevent source code exfiltration across both threat profiles.

   Verify coverage by mapping each alert rule to a threat type. Every fast-path rule should name the volume threshold that triggers it, and every slow-path signal should be tied to an owner in HR, IT, or security.

4. Isolate secrets and lock down the supply chain.Install pre-commit hooks that scan staged changes for secret patterns and block the commit locally. Enable server-side push protection so anything that slips past the hook is caught at push time, and run a full-history scan to find credentials already sitting in old commits. Microsoft’s own guidance on securing source code with GitHub Advanced Security documents push protection and historical secret scanning as the enforcement layer behind local hooks.On protected branches, require pull requests with at least one approving review, passing status checks, signed commits, and no force pushes. Use CODEOWNERS to require security review on CI configuration and deployment scripts. Pin CI actions to full commit SHAs rather than mutable tags, and scope pipeline credentials to the minimum each job needs.

   Confirm the controls by attempting a test commit containing a dummy credential pattern; the hook should reject it locally, and a bypass attempt should be blocked by push protection at the server.

5. Automate offboarding through your identity provider.Connect the SCM to Okta, Entra ID, or your equivalent IdP with SCIM provisioning enabled. When an account is disabled in the IdP, SCIM should remove SCM membership, revoke active sessions, and drop access to organization-owned forks and private repositories.Offboarding gaps are where most programs fail silently: access retained after a notice period, contractor accounts left active past contract end, role changes that never trigger a permission review. Align HR, IT, and security on a scenario-based workflow so termination, resignation, and role change each fire the correct deprovisioning event.

   Verify by running a deprovisioning test on a staging account and confirming the SCM shows no active session, no organization membership, and no repository access within minutes of the IdP disable.