Secure Code Review Checklist Owasp

Standard Operating Procedure: Secure Code Review Checklist (OWASP)

1. Document Control & Revision History

---

2. Executive Summary & Scope

Purpose: This SOP mandates the operational framework for performing rigorous security-focused code reviews. It is designed to mitigate vulnerabilities at the pre-commit and pre-merge stages, ensuring alignment with OWASP Top 10 and SANS/CWE risk mitigation strategies.

Scope: This procedure applies to all production-bound source code, internal APIs, and configuration-as-code (IaC) repositories managed by the engineering organization. It covers all languages, frameworks, and deployment environments (on-premise, cloud, and hybrid).

---

3. Prerequisites & Tool Requirements

• Software/Tooling:
  • SAST/DAST integration (e.g., Snyk, SonarQube, Checkmarx).
  • Secrets detection engine (e.g., Gitleaks, TruffleHog).
  • IDE-integrated linters (e.g., ESLint, Pylint with security plugins).
• Access: Read-only access to repository branches, access to Jira/issue tracking, and elevated permissions in the Security Information and Event Management (SIEM) dashboard.
• Certifications: Reviewers must hold current internal "Security Champion" designation or equivalent.

---

4. Roles & Responsibilities (RACI Matrix)

---

5. Step-by-Step Operational Procedure

Phase 1: Automated Pre-Scan Verification

• Ensure all automated SAST scans have completed without "Critical" or "High" severity findings.
• Verify that no hardcoded credentials or secrets were flagged by the secret detection engine.
• Confirm compliance with defined linting rules (e.g., strict type checking).

Phase 2: OWASP Top 10 Manual Audit

• Injection Prevention: Review code for parameterized queries and input validation/sanitization (SQLi, NoSQLi, XSS, Command Injection).
• Cryptographic Failure: Verify that TLS/SSL is enforced and sensitive data at rest is encrypted using approved algorithms (e.g., AES-256).
• Insecure Design: Evaluate business logic to ensure "fail-safe" states; confirm authorization bypass risks are addressed (IDOR checks).
• Security Misconfiguration: Validate that default configurations, debug modes, and verbosity in error messages are suppressed.
• Vulnerable Components: Cross-reference dependencies (SBOM) against CVE databases; ensure no deprecated or EOL libraries are introduced.

Phase 3: Final Approval

• Confirm reviewer signature provided in the Pull Request (PR) history.
• Validate "Four-Eyes" principle: code merged only after peer review by a second authorized developer.

---

6. Quality Assurance & Verification Criteria

• Tolerance Thresholds: Zero (0) "Critical" or "High" security findings permitted for production merge.
• Audit Trail: Every PR must contain a documented thread of security-related findings and resolution confirmations.
• Acceptance Benchmark: 100% pass rate on the OWASP automated scanner baseline; 100% resolution of mandatory manual review comments.

---

7. Practical Troubleshooting Scenarios

Scenario A: Automated Pipeline False Positives

• Trigger: SAST tool flags code as "SQL Injection" when using a secure ORM.
• Corrective Action: Developer must document the finding, provide an evidence-based explanation of why the finding is a false positive, and obtain sign-off from the Security Lead. The exemption must be logged in the centralized risk register.

Scenario B: Critical Dependency Vulnerability

• Trigger: A new library dependency introduced in the PR has a critical CVE with no available patch.
• Corrective Action: The PR must be blocked immediately. The developer is required to identify an alternative, non-vulnerable library or implement a WAF-level mitigation strategy if immediate patching is impossible, subject to a formal Exception Request (ER).

Scenario C: Secrets Found in Git History

• Trigger: Secrets detection tool flags a committed API key.
• Corrective Action: Revoke the credential in the source system immediately. Perform a git filter-repo or equivalent to purge the secret from history. Rotate the secret. Conduct a retrospective to identify why local hooks failed to prevent the commit.