GitHub: Your SOC 2 Compliance Configuration Checklist

GitHub configurations account for a significant portion of SOC2 technical requirements. It includes security controls that satisfy many audit requirements out of the box. The challenge is knowing which settings to enable and how to configure them properly for compliance. Here are the essential configurations that consistently appear in SOC2 audit findings and form the basis of automated compliance testing.

Common GitHub Configuration Requirements for SOC 2

These core settings form your compliance foundation and are actively monitored by automated testing platforms:

1. Enforce Branch Protection on Main

Branch protection is the cornerstone of secure development workflows. This control ensures that no single developer can push untested or unreviewed code directly to production branches. Configure your main branch with pull request requirements, ensuring every change undergoes peer review. This creates an audit trail and catches potential security issues before they reach production.

2. Enable Multi-Factor Authentication (MFA) for All Organization Members

MFA is non-negotiable for SOC 2 compliance. Every organization member, including contractors and temporary contributors, must have MFA enabled on their GitHub accounts. This prevents unauthorized access even if credentials are compromised. Set this as an organization-wide requirement and regularly audit compliance - automated tests will flag any accounts missing this critical security control.

3. Configure CODEOWNERS Files

CODEOWNERS files ensure that changes to critical code paths receive appropriate review from designated experts. Place CODEOWNERS files in your repository root and define ownership for security-sensitive directories like authentication modules, payment processing, or infrastructure configuration. This guarantees that domain experts review changes to their areas of responsibility.

4. Enable Dependency Scanning with Dependabot

GitHub's Dependabot provides automated dependency vulnerability scanning that satisfies SOC 2 requirements for supply chain security. Enable Dependabot security updates across all repositories to automatically detect and alert on vulnerable dependencies. Configure it to create pull requests for security updates, ensuring your dependencies stay current and secure.

5. Set Up Audit Log Streaming

Comprehensive audit logging is essential for SOC 2 compliance. Configure audit log streaming to send all GitHub organization events to your SIEM solution or S3 bucket for long-term retention. This provides the evidence auditors need and enables security monitoring for suspicious activities.

A common question we hear is: "Do I really need to stop pushing directly to main?"

The answer depends on your audit scope, but most auditors will accept a documented exception process for emergency fixes, provided it includes proper review and documentation after the fact.

Repository Security Essentials

Branch Protection Configuration

Branch protection rules enforce your development workflow and security policies at the repository level:

• Require pull request reviews before merging - This ensures at least one other person reviews every change to protected branches. Configure this to require reviews from CODEOWNERS when applicable, adding an extra layer of domain-specific oversight.
• Dismiss stale reviews when new commits are pushed - This critical setting prevents developers from getting approval and then adding unreviewed changes. Any new commits after approval require fresh reviews, maintaining the integrity of the review process.
• Require status checks to pass before merge - Integrate your CI/CD pipeline status checks, ensuring all tests pass and security scans complete successfully before code can merge. This creates a quality gate that prevents broken or vulnerable code from reaching protected branches.
• Restrict force pushes to protected branches - Force pushes can rewrite history and potentially introduce unreviewed code. Blocking them on protected branches maintains audit trail integrity and prevents accidental or malicious history manipulation.

Access Control Implementation

Proper access control forms the foundation of GitHub security:

• Multi-factor authentication (MFA) enforced at organization level - Use GitHub's organization security settings to require MFA for all members. This prevents access to your code even if passwords are compromised, and automated tests will continuously verify 100% MFA coverage.
• Team-based permissions instead of individual access grants - Create teams aligned with your organizational structure and assign repository permissions to teams rather than individuals. This simplifies access management and makes quarterly access reviews more manageable.
• Regular access reviews and cleanup procedures - Establish quarterly reviews of GitHub access, removing permissions for users who no longer need them. Document this process and maintain evidence of completed reviews for auditors.
• Least-privilege access to repositories - Default to read-only access and escalate permissions only as needed. Admin access should be limited to a small group of infrastructure or security team members.

Code Security Measures

Protecting your code requires multiple layers of security:

• CODEOWNERS files for security-sensitive directories - Beyond just having CODEOWNERS files, ensure they cover all critical paths including authentication, authorization, payment processing, and infrastructure configuration. Regular audits should verify these files remain current as team members change.
• Secret scanning enabled for all repositories - GitHub's secret scanning detects accidentally committed credentials and alerts you immediately. Configure this organization-wide and establish a response process for when secrets are detected.
• Dependency scanning configured and monitored - Use Dependabot to continuously scan dependencies for known vulnerabilities. Set up automated pull requests for security updates and establish SLAs for reviewing and merging these updates.
• No secrets committed to repositories - Beyond scanning, implement pre-commit hooks and developer training to prevent secrets from ever reaching your repositories. Use GitHub Secrets or external secret management solutions for all credentials.

Development Workflow Compliance

Pull Request Requirements

A compliant development workflow balances security with developer productivity:

• Code review process documented and enforced - Document your code review standards including what reviewers should check for, how to handle disagreements, and expected response times. Enforce these through branch protection rules and automated checks.
• Automated testing in CI/CD pipeline - Every pull request should trigger comprehensive test suites including unit tests, integration tests, and security scans. Make these checks required for merging to ensure consistent quality.
• Security scanning integrated into workflow - Include SAST (Static Application Security Testing) tools in your CI/CD pipeline. These should run automatically on every pull request, with findings blocking merge for high-severity issues.
• Documentation of emergency fix procedures - Create and maintain a documented process for emergency fixes that bypass normal review procedures. This should include post-incident review requirements and audit trail maintenance.

Secrets Management

Proper secrets management prevents the most common security breaches:

• External secret managers for all credentials - Use solutions like AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault for production secrets. Never store credentials in code, configuration files, or GitHub Secrets for production use.
• GitHub Secrets for CI/CD pipeline secrets - Use GitHub's encrypted secrets feature for CI/CD credentials like deployment keys or test environment passwords. Limit access to these secrets using environment protection rules.
• Secret scanning alerts monitored and resolved - Establish a process for responding to secret scanning alerts within 24 hours. This should include credential rotation, audit of potential usage, and root cause analysis.
• Incident response for compromised credentials - Document and test procedures for handling exposed credentials including immediate revocation, impact assessment, and notification requirements.

Monitoring and Audit Logging

Audit Requirements

Comprehensive logging satisfies auditor requirements and enables security monitoring:

• Organization audit logs exported to external system - Configure audit log streaming to ensure logs are preserved even if GitHub access is compromised. Use webhooks or the audit log API to stream events to your SIEM or log management solution.
• Administrative actions logged and monitored - Pay special attention to high-risk actions like permission changes, repository deletions, or security setting modifications. Set up alerts for these events in your monitoring system.
• Access changes tracked and reviewed - Every permission grant or revocation should be logged and reviewed as part of your quarterly access certification process. Maintain these logs for at least one year.
• Retention periods configured appropriately - Ensure your log retention meets both SOC 2 requirements (typically 90 days minimum) and any industry-specific regulations. Consider longer retention for security-relevant events.

Security Monitoring

Proactive monitoring prevents minor issues from becoming major incidents:

• Dependency vulnerability alerts configured - Set up notifications for Dependabot alerts to ensure quick response to new vulnerabilities. Route these to your security team with defined SLAs for response.
• Security advisory notifications enabled - Subscribe to GitHub security advisories for early warning of vulnerabilities in GitHub itself or commonly used Actions.
• Third-party app access reviewed and restricted - Regularly audit OAuth apps and GitHub Apps with access to your organization. Remove unused integrations and restrict new installations to approved applications.
• Failed authentication attempts monitored - While GitHub handles most authentication security, monitor audit logs for patterns of failed authentication that might indicate attack attempts.

Scaling GitHub Compliance

Organization Structure

As your team grows, your GitHub structure must evolve:

• Separate organizations for different environments - Consider separate GitHub organizations for production and development code. This provides clear security boundaries and simplifies compliance scope definition.
• Centralized security policies across organizations - Use GitHub Enterprise's security policies or automation to ensure consistent security settings across multiple organizations.
• Automated user provisioning from identity provider - Integrate GitHub with your identity provider using SAML SSO for automated provisioning and deprovisioning, ensuring GitHub access mirrors your HR systems.
• Team-based access management at scale - Design team structures that map to your organization chart and use nested teams for inheritance. This simplifies quarterly access reviews as team membership can be validated against HR records.

Best Practices Checklist

Repository Management:

• [ ]  All repositories use branch protection rules - Every repository containing production code must have branch protection enabled on main/master branches
• [ ]  CODEOWNERS files configured for critical paths - Security-sensitive code paths have designated reviewers defined in CODEOWNERS
• [ ]  Default repositories are private - New repositories default to private visibility to prevent accidental exposure
• [ ]  Regular cleanup of unused repositories - Quarterly reviews remove obsolete repositories to minimize attack surface

Security Configuration:

• [ ]  Organization-wide MFA enforcement enabled - 100% of users have multi-factor authentication with no exceptions
• [ ]  Secret scanning enabled for all repositories - GitHub secret scanning active and alerts monitored
• [ ]  Dependency scanning configured with Dependabot - Automated vulnerability detection for all dependencies
• [ ]  Third-party application access restricted - OAuth and GitHub Apps require approval before installation

Access Control:

• [ ]  Team-based access management implemented - Permissions assigned via teams rather than individual users
• [ ]  Regular access reviews completed quarterly - Documented evidence of quarterly certification reviews
• [ ]  Offboarding process includes GitHub access removal - Integration with HR systems ensures timely access revocation
• [ ]  Admin access limited to essential personnel - Principle of least privilege enforced for administrative permissions

Development Practices:

• [ ]  Code review process documented and enforced - Pull request reviews required on all protected branches
• [ ]  Security scanning integrated in CI/CD pipeline - Automated security tests run on every pull request
• [ ]  Secrets management implemented properly - No credentials in code with external secret management in use
• [ ]  Emergency fix procedures documented - Clear process for handling critical production issues

Monitoring and Logging:

• [ ]  Audit logs exported to external system - GitHub audit events streamed to SIEM or log management
• [ ]  Security alerts monitored and responded to - Defined process for handling Dependabot and secret scanning alerts
• [ ]  Compliance evidence collection automated - API-based evidence collection replaces manual screenshots
• [ ]  Incident response procedures documented - Clear escalation paths for security incidents

For teams using modern development workflows, you can achieve SOC2 compliance with 10-15 hours of technical configuration work when using automated compliance platforms that integrate with GitHub.

GitHub security is a critical component of SOC2 compliance, and proper configuration with automated monitoring ensures you maintain compliance as your development team scales.