GitHub Security Checklist for SOC 2 Compliance
Auditors will examine your GitHub configuration carefully. Branch protection, secret scanning, MFA — here's exactly what they look for and how to fix it fast.
Your GitHub organization is one of the first things a SOC 2 auditor will ask about. It's the heart of your change management process, and the Trust Services Criteria have explicit requirements around code review, access controls, and secret management. Here's what they look for — and how to fix each gap.
1. Branch Protection Rules
Auditors want to see that code cannot be pushed directly to production branches without review. This maps to CC8.1 (Change Management) in the Common Criteria.
What to configure on your main/master branch:
- Require pull request reviews before merging (minimum: 1 reviewer)
- Require status checks to pass before merging
- Require branches to be up to date before merging
- Restrict who can push directly (ideally: nobody, not even admins)
- Require signed commits (bonus: shows strong identity assurance)
2. MFA Enforcement
All members of your GitHub organization must have two-factor authentication enabled. This maps to CC6.1 (Logical and Physical Access Controls).
Go to Organization Settings > Authentication security > Require two-factor authentication for everyone in your organization. GitHub will immediately remove any member who doesn't comply — warn your team first.
3. Secret Scanning
Accidentally committed API keys and credentials are one of the most common SOC 2 findings. GitHub's built-in secret scanning detects over 200 token patterns and can block pushes that contain secrets.
- Enable secret scanning: Settings > Code security and analysis > Secret scanning
- Enable push protection: Blocks pushes containing detected secrets before they land
- Review the secret scanning alerts page and resolve any historical leaks
- Rotate any credentials that were exposed, even briefly
4. Public Repository Exposure
Auditors will ask you to demonstrate that no sensitive code or configuration is in public repositories. This is particularly important if your organization has a mix of open-source and proprietary repos.
- Audit all public repositories — document which ones are intentionally public
- Enable private repository forking settings to prevent accidental exposure
- Consider setting your organization's default repository visibility to Private
- Review collaborator access on any public repos
5. Access Reviews
Beyond configuration, auditors want to see a process. CC6.2 requires that access is reviewed periodically and revoked when employees leave.
- Conduct and document access reviews at least quarterly (bi-annually is minimum)
- Remove former employees from the organization immediately upon offboarding
- Use GitHub Teams to manage access by role rather than individually
- Document your offboarding checklist and follow it every time
How Long Does This Take?
Most of these controls can be enabled in a single afternoon. The branch protection configuration takes 20 minutes. MFA enforcement is a one-click setting. Secret scanning enablement takes 5 minutes. The real work is the organizational process changes — making sure your team follows the code review process and that you document your access reviews.
Run a gap analysis against your GitHub configuration to get a precise list of what's passing and what needs attention before you engage an auditor.