# Topic 14: Code Review A **code review** is a quality assurance process in which one or more developers examine another developer's source code before it is merged into the master repository. In security, code reviews serve as a critical checkpoint, combining human analysis with automated testing tools to find bugs, logical errors, and security vulnerabilities. --- ## How Code Review Protects Software & Data A structured code review process acts as a filter to catch security flaws before they reach production: ### 1. Human Inspection (Logical Flaws) * **The Mechanism**: Peer reviewers manually read the code changes to understand the program flow and developer intent. * **The Protection**: Catching complex business logic flaws (e.g., bypassing payment systems or missing authorization checks) that automated scanners often miss. ### 2. Preventing Malicious Injection * **The Mechanism**: Forcing all code modifications to be approved by at least one other team member. * **The Protection**: Prevents a malicious insider from pushing backdoors, logic bombs, or data exfiltration scripts directly to the application. ### 3. Standardised Security Checklists * **The Mechanism**: Reviewers check code against a list of known secure programming guidelines (e.g., OWASP Top 10). * **The Protection**: Guarantees that inputs are sanitized, SQL queries are parameterized, and secrets are not committed to code. --- ## Automated Code Review Tools To scale security checks, modern development teams combine manual code reviews with automated scanning tools in their CI/CD pipelines: ### 1. Static Application Security Testing (SAST) * **Method**: **White-box testing**. The tool scans the application's source code, byte code, or binaries *without running the program*. * **Benefit**: Identifies security vulnerabilities (like hardcoded keys, SQL injections, or buffer overflows) early in the development lifecycle, highlighting the exact file and line number. ### 2. Dynamic Application Security Testing (DAST) * **Method**: **Black-box testing**. The tool scans a *running application* by simulating attacks (like sending malicious payloads to input fields). * **Benefit**: Identifies runtime and environment-related vulnerabilities (like bad server configurations, session management flaws, or broken authentication endpoints). --- ## Classification of Code Review Controls | Control Type | Examples in Code Review | | :-------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Software Controls (Technical)** | * Integrating SAST scanners (e.g., SonarQube, CodeQL) into the pull request pipeline.<br>* Repository branch rules requiring peer approval before merging.<br>* Automatic dependency scanners checking for vulnerable packages during reviews. | | **Administrative Controls** | * A formal Code Review Policy (mandating peer reviews for *all* production-bound code).<br>* Secure Coding Checklists (specifying security-focused review questions).<br>* Regular developer training on secure coding practices (like OWASP). | --- ## VCE Exam Practice ### Scenario Developers at *WebPay* are working on an update to their checkout system. Eager to launch before a holiday sale, they skip their standard peer review process and merge the code directly. After launch, an attacker exploits an unsanitized input field in the checkout page to execute a SQL injection attack, stealing the payment details of 10,000 customers. ### Questions 1. **Define** the purpose of a code review. *(1 mark)* 2. **Distinguish** between Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST). *(2 marks)* 3. **Propose and justify** one software control and one administrative control WebPay should implement to ensure code reviews protect their application data. *(4 marks)* --- > [!NOTE] > **Suggested Answers:** > 1. *The purpose of a code review is to have peers systematically inspect source code to detect logical errors, enforce quality standards, and identify security vulnerabilities before code is merged into production.* > 2. *SAST is a white-box testing method that analyzes source code for vulnerabilities without running the application, whereas DAST is a black-box testing method that tests a running application by simulating attacks against it.* > 3. * *Software Control: Mandate Branch Protection Rules*. Configure the repository (e.g. GitHub) to prevent merging pull requests unless they receive a minimum of one peer approval and pass all automated SAST scans. This ensures no developer can skip the security check. > * *Administrative Control: Secure Coding Checklist*. Create an administrative policy and checklist requiring reviewers to verify that all database query inputs are parameterized and user fields are sanitized before granting approval.*