Code Review Checklist Github

Standard Operating Procedure: code review checklist github

1. Document Control & Revision History

---

2. Executive Summary & Scope

2.1 Clinical Statement of Operational Boundaries

This Standard Operating Procedure (SOP) defines the mandatory, auditable workflow for executing, evaluating, and approving Pull Requests (PRs) via GitHub Enterprise Cloud/Server within the organization. The objective is to eliminate regression injection, verify code hygiene, enforce security compliance, and maintain an immutable audit trail for all software modifications entering production and staging branches.

2.2 Regulatory Standards & Compliance

Adherence to this SOP is mandatory for maintaining compliance with:

• SOC 2 Type II (Common Criteria CC8.1, CC8.2, CC8.3 regarding change management and software development lifecycles).
• ISO/IEC 27001:2022 (Control A.14.2 - Security in development and support processes).
• PCI-DSS v4.0 (Requirement 6.3 - Secure software engineering practices).
• FedRAMP Moderate (Configuration Management and System and Information Integrity baselines).

---

3. Prerequisites & Tool Requirements

Execution of this SOP requires explicit provisioning of software tools, hardware systems, and security credentials:

• Version Control Platform: GitHub Enterprise Cloud (Organization-level license with SAML SSO and Enforced 2FA).
• Integrated Development Environment (IDE): VS Code / IntelliJ IDEA with pre-commit hooks matching repository linters.
• Security Tooling:
  • GitHub Advanced Security (GHAS) enabled (Secret Scanning, Dependabot, CodeQL SAST).
  • Container security scanner (e.g., Trivy / Snyk) integrated via GitHub Actions.
• Command Line Utilities: git (v2.40+), GitHub CLI (gh v2.20+).
• Certifications & Access:
  • Active enterprise GitHub account mapped to internal Identity Provider (Okta/Azure AD).
  • Mandatory completion of the internal Secure Coding & Peer Review Masterclass (Certification ID: SEC-PR-101).

---

4. Roles & Responsibilities (RACI Matrix Table)

---

5. Step-by-Step Operational Procedure

Phase 1: Pre-Review Author Verification (Author Action)

• Ensure branch naming convention strictly follows feature/, bugfix/, or hotfix/ prefixed with the Jira/Linear ticket ID (e.g., feature/PROJ-4092-auth-refactor).
• Verify that all local tests pass (unit, integration, and linting) prior to raising the Pull Request.
• Confirm that no sensitive data (API keys, private keys, connection strings, personal identifiable information) exists in the commit history.
• Draft a comprehensive PR description utilizing the standard institutional template, explicitly linking the corresponding ticket and detailing breaking changes or migration steps.

Phase 2: Automated Validation & Gating (System Action)

• Verify that all required status checks have successfully passed (CI/CD Build, CodeQL Analysis, Unit Tests, Container Vulnerability Scan).
• Confirm zero high-severity or critical vulnerabilities reported by Dependabot and Secret Scanning.
• Ensure branch is fully rebased or merged with the target base branch (main/release/*) with zero unresolved merge conflicts.

Phase 3: Code Review Execution (Reviewer Action)

• Architectural & Design Review: Verify that the code adheres to established design patterns, does not introduce technical debt, and maintains separation of concerns.
• Security Review:
  • Check for OWASP Top 10 vulnerabilities (SQL injection, XSS, CSRF, insecure deserialization).
  • Ensure input validation and sanitization are implemented on all untrusted data boundaries.
  • Verify proper authentication and authorization checks (RBAC/ABAC) on new endpoints or methods.
• Performance & Resource Utilization: Inspect for algorithmic efficiency (avoiding $O(n^2)$ or worse loops where avoidable), memory leaks, unclosed database connections, or unoptimized database queries (N+1 query problems).
• Error Handling & Logging:
  • Confirm graceful degradation and explicit exception catching (no swallowed errors or bare except: blocks).
  • Verify that sensitive user data (passwords, tokens, PII) is redacted from all log outputs.
• Test Coverage Verification: Confirm that new or modified functionality includes corresponding unit and integration tests meeting or exceeding the 85% coverage threshold delta.

Phase 4: Resolution and Sign-Off (Collaborative Action)

• Author addresses all review comments, pushing targeted commits or amending interactively as required.
• Reviewer performs a differential re-review on updated commits.
• Technical Lead / Module Owner provides formal approval via GitHub (Approve review state).
• Squash and merge executed via GitHub UI utilizing the conventional commit message format.
• Verify source branch is automatically deleted upon successful merge.

---

6. Quality Assurance & Verification Criteria

To achieve compliance and pass automated/manual audit inspections, all merged code must satisfy the following thresholds:

• Reviewer Quota: Minimum of two (2) distinct peer approvals required for modifications to core infrastructure, authentication, or payment-processing modules; one (1) approval required for standard feature branches.
• Zero-Defect Policy: Zero critical or high SAST/Secret scanning flags allowed in the target branch.
• Test Coverage Benchmark: Overall repository test coverage must not drop below 85.0%, and new code blocks must maintain a minimum 90.0% coverage baseline.
• Audit Trail Integrity: All reviews, comment threads, dismissals, and approval timestamps must be permanently retained within the GitHub Enterprise audit log.

---

7. Practical Troubleshooting Scenarios

Scenario A: Automated Security Gate Fails Due to False Positive Secret Scanning / SAST Flag

• Symptom: A PR is blocked because CodeQL or Secret Scanning flags a dummy testing string or benign configuration key as a critical security vulnerability.
• Immediate Corrective Action Protocol:
  1. Do not bypass the security check via administrative override without authorization.
  2. Consult with the SecOps engineer via the designated Slack/Teams incident channel.
  3. If verified as a false positive, add an explicit, inline suppression comment containing the justification and ticket reference (e.g., // codeql[cs/hardcoded-credentials]: Verified test fixture string, non-production.); alternatively, update the .github/codeql/config.yml suppression rules.
  4. Re-run the failed GitHub Action workflow to clear the status check.

Scenario B: Stale Review Approvals Invalidated by Emergency Hotfix Push

• Symptom: A developer pushes a trivial formatting fix or late dependency update after approvals have been granted, automatically dismissing existing reviews due to branch protection rules (Dismiss stale pull request approvals when new commits are pushed).
• Immediate Corrective Action Protocol:
  1. Identify the specific commit hash causing the dismissal.
  2. Notify the original reviewers via a direct ping referencing the exact diff of the latest commit (git diff HEAD~1).
  3. Request an expedited re-review specifically focusing on the delta, referencing the isolation of the hotfix commit.
  4. Prohibit the use of force-push (git push --force) on active PR branches unless coordinating an emergency workspace recovery to prevent history divergence.