Code Review Checklist Owasp

Standard Operating Procedure: Code Review Checklist (OWASP Alignment)

1. Document Control & Revision History

2. Executive Summary & Scope

Purpose: To standardize the technical audit of source code against the OWASP Top 10 and secure coding principles. This procedure mitigates software supply chain risks and ensures compliance with SOC2, HIPAA, and GDPR data protection mandates.

Scope: This SOP applies to all production-bound application code, microservices, and Infrastructure-as-Code (IaC) repositories managed by the Engineering Organization. It covers static analysis, dependency evaluation, and business logic verification.

3. Prerequisites & Tool Requirements

• Access Requirements: Read/Write access to the primary CI/CD orchestration platform (e.g., GitHub Actions, GitLab CI).
• Tooling:
  • SAST Scanner (e.g., Snyk, SonarQube, or Semgrep).
  • SCA Tooling for dependency analysis (e.g., OWASP Dependency-Check).
  • IDE with integrated security linting.
• Certification: Reviewer must hold current Internal Secure Coding Certification.

4. Roles & Responsibilities (RACI Matrix)

5. Step-by-Step Operational Procedure

Phase I: Automated Pre-Flight

• Verify that SAST/SCA scanners have completed successfully without critical-level findings.
• Ensure all dependencies are scoped to stable, patched versions (no 'latest' tags).
• Confirm no hardcoded secrets exist in the commit history (verified via Gitleaks or equivalent).

Phase II: Input Validation & Authentication

• Confirm all user-supplied input is sanitized against an allow-list, not a block-list.
• Validate that parameterized queries or ORM abstractions are used to prevent SQL Injection.
• Ensure Multi-Factor Authentication (MFA) logic is applied to all sensitive endpoints.
• Verify session tokens are cryptographically strong and stored in secure, HttpOnly, SameSite-restricted cookies.

Phase III: Access Control & Data Security

• Audit Object-Level Authorization: Ensure users cannot access resources belonging to another UID.
• Confirm TLS 1.3 is enforced for all data-in-transit.
• Verify that encryption-at-rest is implemented using industry-standard primitives (AES-256).

Phase IV: Error Handling & Logging

• Ensure sensitive data (PII/Credentials) is masked in log outputs.
• Verify that application errors do not return stack traces or database schema information to the client.

6. Quality Assurance & Verification Criteria

• Zero-Tolerance Threshold: No code shall be merged with "Critical" or "High" security findings.
• Performance Benchmark: Total manual review time must not exceed 20% of the total ticket development time.
• Acceptance Criteria:
  • 100% pass rate on automated security linting.
  • Evidence of peer review signature in the PR audit trail.
  • Confirmation that no sensitive secrets are present in the repository history.

7. Practical Troubleshooting Scenarios

Scenario A: Build Failure due to Vulnerable Dependency

• Failure: SCA tool identifies a critical vulnerability in a production library.
• Protocol:
  1. Check for a patched version of the library.
  2. If unavailable, implement a temporary "shim" or input filter to block the attack vector.
  3. If mitigation is impossible, move to the Security Exception Process (requires CISO sign-off).

Scenario B: Sensitive Data Leak in Logs

• Failure: PII identified in application telemetry during audit.
• Protocol:
  1. Immediately redact the log stream (remove logs from persistent storage).
  2. Trigger the Data Incident Response Plan if the data has exited the secure boundary.
  3. Patch the logging configuration and perform a root-cause analysis (RCA) on the logging middleware.