Source Code Review Checklist Github

SOP-ENG-SEC-004: Source Code Review Checklist (GitHub)

1. Document Control & Revision History

2. Executive Summary & Scope

This procedure mandates the clinical standard for Pull Request (PR) validation within the GitHub ecosystem. It applies to all engineering divisions, including contractors. The objective is to mitigate security vulnerabilities, maintain architectural integrity, and ensure compliance with SOC2 Type II and ISO/IEC 27001 requirements. Failure to adhere to these verification protocols constitutes a breach of engineering governance.

3. Prerequisites & Tool Requirements

• Access Level: GitHub Enterprise/Business tier with 'Write' or 'Maintain' permissions.
• Tooling: Enabled GitHub Advanced Security (CodeQL, Secret Scanning, Dependency Graph).
• Environment: Verified local development environment (containerized/Dockerized).
• Certification: Personnel must have completed the 'Secure Coding & Threat Modeling' internal certification.

4. Roles & Responsibilities (RACI Matrix)

5. Step-by-Step Operational Procedure

Phase I: Pre-Review Automated Validation

• Ensure all CI pipeline checks (Build, Unit Tests) have passed successfully.
• Confirm CodeQL analysis has identified zero 'Critical' or 'High' alerts.
• Verify that Secret Scanning has flagged no leaked credentials or API keys.

Phase II: Architectural & Logic Audit

• Complexity Analysis: Ensure the code does not violate O(n) complexity constraints or introduce unnecessary technical debt.
• Abstraction Integrity: Verify adherence to SOLID design principles.
• Data Sanitization: Confirm that all user inputs are passed through approved sanitization functions to prevent XSS, SQLi, and Command Injection.

Phase III: Security & Compliance Verification

• Dependency Audit: Check package-lock.json or go.sum for deprecated or vulnerable packages using dependabot.
• Sensitive Data: Manually inspect for hardcoded secrets, PII, or internal service endpoints.
• Least Privilege: Confirm the logic does not require excessive read/write permissions for service identities or scoped tokens.

Phase IV: Final Approval

• Ensure all 'Required Reviewers' have provided explicit approval.
• Confirm documentation/README updates are included in the PR scope.
• Execute a final 'squash and merge' if the commit history is non-linear.

6. Quality Assurance & Verification Criteria

Acceptance Benchmark: Any PR failing to meet 100% of security thresholds is automatically rejected. No overrides are permitted without a signed Exception Request form from the SecOps department.

7. Practical Troubleshooting Scenarios

Scenario A: Build Failure due to Dependency Conflict

• Symptom: CI pipeline fails on 'npm install' or 'go mod download' due to version mismatch.
• Corrective Action: Do not force-merge. The engineer must update the lockfile via CLI, resolve the dependency tree, and re-push the lockfile. Commits must be signed and validated.

Scenario B: Sensitive Data Leak Detected (Post-Commit)

• Symptom: GitHub Secret Scanning alerts for an exposed AWS Access Key.
• Corrective Action:
  1. Immediate revocation of the credential in AWS IAM.
  2. Rotation of the key.
  3. The engineer must perform a git filter-repo or BFG Repo-Cleaner operation to excise the secret from commit history, followed by a forced push.
  4. Issue a formal Incident Report (IR) to the Security Team.

Scenario C: Unresolved Review Comments

• Symptom: Author merges a PR before Tech Lead addresses secondary suggestions.
• Corrective Action: Revert the merge immediately. Open a "Reversion PR" to return the branch to the pre-merge state. Review the incident with the author for violation of workflow governance.