Secure Code Review Checklist Github

SOP-SEC-GHR-004: Secure Code Review Protocol

1. Document Control Block

• Document ID: SOP-SEC-GHR-004
• Effective Date: 2023-10-27
• Version: 2.1.0
• Review Cadence: Quarterly (Q1, Q2, Q3, Q4)
• Target Audience: Software Engineering Team, DevSecOps, Information Security Analysts

2. Executive Summary & Scope

This procedure mandates the operational framework for conducting secure code reviews within GitHub environments. Its objective is to mitigate injection vulnerabilities, broken authentication, and exposure of sensitive data prior to production deployment. This SOP applies to all pull requests (PRs) involving high-impact repositories as defined by the Template Registry Asset Classification Policy.

3. Prerequisites & Tool Requirements

• Access Requirements: GitHub Enterprise "Write" or "Maintainer" permissions; MFA-enforced SSO credentials.
• Toolchain:
  • GitHub Advanced Security (GHAS) enabled for repository.
  • SAST/DAST integration (e.g., Snyk, CodeQL).
  • IDE-integrated linters (e.g., ESLint, SonarLint).
• Certifications: Reviewers must hold a minimum status of "Senior Engineer" or have completed the internal Secure Code Review certification.

4. Roles & Responsibilities (RACI Matrix)

5. Step-by-Step Operational Procedure

Phase I: Pre-Review Validation

• Ensure all automated CI/CD checks (linting, build, unit tests) report a "Passed" status.
• Verify that no secrets (API keys, tokens, hardcoded credentials) are present in the diff (run gitleaks or similar).
• Confirm the PR scope does not exceed the associated Jira/Linear ticket specification.

Phase II: Manual Security Assessment

• Input Sanitization: Validate that all external data inputs (HTTP parameters, file uploads, headers) are sanitized and validated against an allow-list.
• Authentication/Authorization: Inspect logic to ensure users are authenticated and authorized to perform the requested function (avoid Insecure Direct Object References).
• Sensitive Data Handling: Ensure encryption-at-rest/transit for PII/PHI; verify log masking for sensitive strings.
• Dependency Audit: Check for introduced external dependencies; verify they align with the approved library whitelist.

Phase III: Reviewer Approval & Merge

• Address all "Blocking" comments; ensure thread resolution via "Resolve conversation" action.
• Obtain at least one secondary "Approve" label from a peer with write access.
• Verify merge strategy conforms to repository standards (e.g., Squash and Merge for clean audit logs).

6. Quality Assurance & Verification Criteria

• Tolerance Threshold: Zero (0) critical or high-severity vulnerabilities per the CVSS v3.1 scoring standard.
• Audit Benchmark: 100% of merged PRs must have an associated security comment thread or a verified automated scan result.
• Review Velocity: Average review turnaround time should not exceed 24 business hours for standard updates.

7. Practical Troubleshooting Scenarios

Scenario A: Secret Detection Triggered

• Failure: Pre-commit or CI hooks identify a hardcoded AWS key.
• Corrective Action: Immediate "Request Changes" on the PR. Developer must revoke the compromised key via IAM, rotate credentials, and scrub the git history using BFG Repo-Cleaner before the PR can be re-submitted.

Scenario B: High-Complexity Architectural Drift

• Failure: Reviewer identifies that the code logic deviates from the Secure System Architecture, introducing a potential SSRF risk.
• Corrective Action: Transition PR status to "On Hold." Escalate to the Security Architect for an expedited Design Review Session. Do not proceed until a remediation plan is signed off by the Architect.

Scenario C: Unresolved Dependency Vulnerability

• Failure: GHAS alerts a "High" severity vulnerability in a new NPM package added in the PR.
• Corrective Action: Rejection of PR. Developer must identify a patched version or a secure alternative. If no alternative exists, the dependency must be sandboxed or denied, requiring a Security Exception Request form.

Signed,

Julian Vance Chief Operations Architect Template Registry