Incident Response Plan Template Github

Standard Operating Procedure: GitHub Incident Response Plan Execution

Document ID: SOP-ENG-GH-042
Effective Date: October 24, 2023
Version: 2.1.0
Review Cadence: Semi-Annual
Classification: Internal Restricted / Engineering Operations

---

1. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the institutional protocol for executing, maintaining, and executing Incident Response Plans (IRP) stored and managed via GitHub repositories. The objective is to standardize containment, mitigation, remediation, and post-incident analysis for security and infrastructure breaches impacting code repositories, CI/CD pipelines, and associated artifact registries. Adherence to this SOP ensures cryptographic chain-of-custody, minimal MTTR (Mean Time To Resolution), and strict regulatory compliance.

---

2. Scope & Prerequisites

Scope

• All GitHub Enterprise Cloud (GHEC) organizations, GitHub Enterprise Server (GHES) instances, and connected GitHub Actions runners owned or operated by Template Registry.
• Encompasses source code leakage, credential exposure, unauthorized access, supply chain tampering, and denial-of-service vectors.

Prerequisites & Required Tooling

• GitHub CLI (gh): Authenticated with repo, admin:org, and audit_log scopes.
• Git: Configured with GPG-signed commit capabilities.
• Access Control: PagerDuty / Opsgenie administrative access, SIEM dashboard access (Datadog/Splunk), and Vault break-glass tokens.
• Infrastructure: Isolated forensic analysis workstation (Air-gapped or ephemeral cloud sandbox).

---

3. Roles & Responsibilities (RACI Matrix)

• Responsible (R): The operational actor executing the procedure.
• Accountable (A): The sole decision-maker with ultimate ownership.
• Consulted (C): Subject matter experts providing critical inputs.
• Informed (I): Stakeholders updated on status milestones.

---

4. Step-by-Step Procedure

Phase 1: Detection, Triage, and Escalation

• 1.1 Acknowledge automated alert from SIEM, GitHub Secret Scanning, or manual report within 5 minutes of paging.
• 1.2 Open an emergency incident bridge via PagerDuty and spin up a dedicated private Slack channel (#incident-YYYYMMDD-[slug]).
• 1.3 Classify the incident severity using the matrix below:
  • SEV-1 (Critical): Active data exfiltration, root access compromise, supply chain poisoning.
  • SEV-2 (High): Secret exposure without confirmed exfiltration, unauthorized PR merges to production branches.
  • SEV-3 (Moderate): Internal-only data exposure, non-critical dependency vulnerability exploited.
• 1.4 Assign the Incident Commander (IC) and log initial metadata in the master GitHub Security Incident tracking repository.

Phase 2: Containment and Eradication

• 2.1 Revoke compromised Personal Access Tokens (PATs), OAuth tokens, and SSH keys instantly via GitHub API:

  gh api -X DELETE /user/keys/{key_id}
  

• 2.2 Isolate affected repositories by changing visibility to private or suspending the compromised organization member:

  gh api -X PATCH /orgs/{org}/memberships/{username} -f role='member'
  

• 2.3 Lock down CI/CD pipelines by disabling GitHub Actions workflows globally or at the repository level:

  gh api -X PUT /repos/{owner}/{repo}/actions/permissions -f enabled=false
  

• 2.4 Purge poisoned git history if malicious commits were pushed (utilizing git filter-repo or BFG Repo-Cleaner) and force-push clean HEAD state after coordination:

  git push origin main --force-with-lease
  

Phase 3: Forensic Analysis and Evidence Gathering

• 3.1 Export complete GitHub audit logs for the affected window using the GraphQL or REST API:

  gh api graphql -f query='{ enterprise(slug: "template-registry") { auditLog(first: 100) { nodes { ... on AuditLogEntry { action } } } } }' > forensic_audit_$(date +%s).json
  

• 3.2 Capture SHA-256 checksums of all affected release artifacts and build logs.
• 3.3 Securely archive runner execution logs and container images for static and dynamic analysis.

Phase 4: Recovery and Post-Incident Validation

• 4.1 Rotate all system secrets, database credentials, and cloud IAM roles that intersected with the compromised environment.
• 4.2 Re-enable GitHub Actions workflows incrementally, enforcing mandatory branch protection rules:
  • Require pull request reviews before merging.
  • Require status checks to pass (e.g., SAST, SCA, Secret Scanning).
• 4.3 Conduct automated vulnerability sweeps and dependency checks across all restored repositories.
• 4.4 Formally close the incident bridge once system stability and data integrity are cryptographically verified.

---

5. Quality Assurance & Pro-Tips

Best Practices

• Immutability: Never edit operational logs directly on production systems; pipe outputs directly to secure S3 buckets with Object Lock enabled.
• Principle of Least Privilege: Ensure CI/CD tokens scoped to workflows possess only the minimum required permissions (contents: read).
• Automated Drills: Conduct quarterly game-day simulations executing this exact SOP via simulated GitHub token leaks.

Common Pitfalls

• Pitfall: Force-pushing without notifying active developers, resulting in chaotic merge conflicts and fragmented local states.
  Mitigation: Issue a global broadcast freeze on the affected repository prior to history rewrites.
• Pitfall: Forgetting to revoke fine-grained PATs tied to organization webhooks.
  Mitigation: Always audit active webhook integrations during Phase 2 containment.

Metric Thresholds

• MTTA (Mean Time To Acknowledge): $\le 5$ minutes.
• MTTC (Mean Time To Contain): $\le 30$ minutes (SEV-1).
• Post-Mortem Publication Window: $\le 48$ hours post-incident.

---

6. Frequently Asked Questions (FAQ)

Q1: What is the immediate protocol if a production-grade GitHub Personal Access Token (PAT) is accidentally committed to a public repository?
A: Treat it as a SEV-1 event immediately. GitHub's automated secret scanning will typically revoke the token automatically within seconds, but you must manually verify revocation via the API, audit the token's last used IP address, and review repository access logs for anomalous data retrieval during the exposure window.

Q2: How do we handle third-party GitHub Actions that have been compromised upstream?
A: Immediately pin all GitHub Actions workflows to immutable SHA hashes rather than mutable version tags (e.g., actions/checkout@v3.5.2 $\rightarrow$ actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3). If an upstream action is compromised, fork and patch internally or replace it with a verified alternative while executing Phase 2 containment.