Soc 2 Compliance Checklist Github

Standard Operating Procedure: GitHub-Centric SOC 2 Type II Compliance Architecture

1. Document Control Block

• Document ID: SOP-TR-OPS-SOC2-GH-042
• Effective Date: October 24, 2023
• Version: 4.2.0
• Review Cadence: Semi-Annual (Every 6 Months)
• Target Audience: DevOps Engineers, Platform Security Engineers, Compliance Officers, Engineering Managers, Chief Technology Officer

---

2. Executive Summary & Scope

This Standard Operating Procedure (SOP) defines the mandatory engineering controls, configuration baselines, and verification workflows required to establish, maintain, and evidence SOC 2 Type II compliance (Trust Services Criteria: Security, Availability, and Confidentiality) within GitHub Enterprise Cloud organizations and repositories.

This document applies to all codebases, infrastructure-as-code (IaC) pipelines, CI/CD workflows, and access-control planes hosted under Template Registry GitHub organizations. Non-compliance with these operational parameters introduces unacceptable audit risk and potential breach of enterprise data protection agreements.

---

3. Prerequisites & Tool Requirements

• Software & Platform Access:
  • GitHub Enterprise Cloud (GHEC) with Enterprise Managed Users (EMU) or SAML Single Sign-On (SSO) enforced.
  • Organization Owner and Repository Admin permissions.
  • Terraform v1.5+ or GitHub REST API/GraphQL API access for programmatic governance.
  • Automated compliance monitoring platforms (e.g., Vanta, Drata, or Secureframe) integrated via GitHub App integrations with read-only audit scopes.
• Security Tooling:
  • Static Application Security Testing (SAST) engines (GitHub Advanced Security / CodeQL).
  • Secret Scanning and Push Protection enabled at the enterprise level.
  • Dependency Review Actions integrated into all Pull Request (PR) checks.
• Certifications & Training:
  • Personnel executing administrative changes must maintain active internal secure coding and access-control certifications.

---

4. Roles & Responsibilities (RACI Matrix Table)

---

5. Step-by-Step Operational Procedure

Phase 1: Identity, Access Management, and Authentication (Trust Services Criteria: CC6.1, CC6.2)

• 1.1 Enforce SAML Single Sign-On (SSO) at the GitHub Enterprise level, prohibiting native password authentication for all organizational users.
• 1.2 Mandate Two-Factor Authentication (2FA) for all external collaborators, service accounts, and fallback administrative users.
• 1.3 Configure automated provisioning and de-provisioning via System for Cross-domain Identity Management (SCIM) linked to the corporate Okta/Azure AD identity provider.
• 1.4 Conduct bi-weekly programmatic audits of organization membership; remove deactivated enterprise accounts within 24 hours of employment termination.
• 1.5 Restrict organization owner seats to a maximum of three (3) designated Platform Security and Infrastructure leads.

Phase 2: Repository Governance and Branch Protection Controls (Trust Services Criteria: CC6.6, CC8.1)

• 2.1 Enforce strict baseline branch protection rules on all default (main/master) and release branches across 100% of repositories via Terraform automation:
  • Require pull requests before merging (minimum 1 peer review for standard repos, 2 for core infrastructure/registry repos).
  • Dismiss stale pull request approvals when new commits are pushed.
  • Require status checks to pass before merging (CI pipeline completion, vulnerability scanning).
  • Require signed commits (GPG/SSH) to verify developer identity and prevent commit spoofing.
  • Enforce linear history to maintain an immutable audit trail of all changes.
  • Restrict who can push to matching branches (disable force pushes and direct deletions entirely).
• 2.2 Disable public repository creation organization-wide; restrict repository visibility changes strictly to Organization Owners.

Phase 3: CI/CD Pipeline Security and Vulnerability Management (Trust Services Criteria: CC7.1, CC7.2)

• 3.1 Enable GitHub Advanced Security (GHAS) enterprise-wide, activating Secret Scanning, Push Protection, and CodeQL SAST scanning on all repositories.
• 3.2 Configure Dependency Review action on all pull requests to block the introduction of known vulnerabilities (CVEs) and unapproved software licenses.
• 3.3 Ensure all GitHub Actions workflows pin third-party actions to immutable SHA hashes rather than mutable semantic version tags (e.g., actions/checkout@v3 $\rightarrow$ actions/checkout@f43a0e5ff2bd294095638e18286ca9a3d1959744).
• 3.4 Implement least-privilege token permissions for GitHub Actions (permissions: read-all as baseline, explicitly elevating write permissions only where strictly required per workflow).

Phase 4: Audit Logging and SIEM Integration (Trust Services Criteria: CC7.3, CC4.1)

• 4.1 Stream all GitHub Enterprise audit logs, security logs, and webhooks in real-time to the centralized Security Information and Event Management (SIEM) / cloud logging bucket (e.g., AWS S3 / Datadog).
• 4.2 Configure automated alerts in the SIEM for high-risk security events:
  • Addition of external organization owners or outside collaborators.
  • Disabling of branch protection rules or secret scanning features.
  • Generation of personal access tokens (PATs) with elevated scopes.
  • Repository visibility modifications (Internal/Private to Public).
• 4.3 Retain all immutable audit logs for a minimum of 365 days to cover full SOC 2 Type II observation windows.

---

6. Quality Assurance & Verification Criteria

To certify compliance prior to external audit review, the platform architecture must meet the following absolute verification benchmarks:

• 100% Repository Coverage: Automated policy-as-code scripts (e.g., checkov, tflint, or GitHub Graph API compliance checkers) must report zero non-compliant repositories regarding branch protections and GHAS activation.
• Zero Critical Vulnerabilities: Zero unmitigated Critical or High severity CVEs in production dependencies past their SLA remediation window (7 days for Critical, 30 days for High).
• Access Reconciliation Completeness: 100% match between active enterprise identity provider directory (HR system/Okta) and active GitHub enterprise seats.
• Audit Trail Integrity: Continuous log delivery verification showing zero dropped payloads or ingestion gaps exceeding 60 seconds over the preceding 90-day rolling window.

---

7. Practical Troubleshooting Scenarios

Scenario A: Unauthorized Direct Push Detected on Protected Branch

• Symptom: SIEM alert triggers indicating a direct commit bypass or force-push event on the main branch of a core registry repository.
• Immediate Corrective Action Protocol:
  1. Revoke Access: Immediately suspend the user account and associated personal access token (PAT) / deploy key responsible for the push.
  2. Revert State: Execute a hard reset on the repository branch back to the last known cryptographically signed and verified commit hash:

     git checkout main
     git reset --hard <LAST_VERIFIED_COMMIT_SHA>
     git push origin main --force-with-lease
     

  3. Forensic Review: Platform Security exports the GitHub audit log slice for the offending user session to determine vector of bypass (e.g., temporary admin role misconfiguration).
  4. Remediation & Ticket: File an internal security incident ticket, review branch protection inheritance rules via Terraform, and re-apply policies globally within 2 hours.

Scenario B: GitHub Actions Workflow Dependency Failure / Expired SHA Pinning

• Symptom: CI/CD pipeline fails globally across repositories due to unresolvable third-party action mutations or revoked signing certificates.
• Immediate Corrective Action Protocol:
  1. Freeze Deployments: Temporarily halt all automated merge operations to prevent corrupted or unverified builds from reaching staging/production environments.
  2. Isolate Affected Workflow: Identify the specific workflow file referencing the compromised or deprecated action.
  3. Rollback to Valid Baseline: Update the workflow file to point to a verified internal enterprise-hosted action proxy or a securely pinned, audited SHA hash.
  4. Post-Incident Validation: Run a manual dry-run workflow execution, verify compliance check passage, and resume normal CI/CD operations while logging the event in the compliance tracker.