This chapter covers security code review, a critical process for identifying vulnerabilities in software before deployment. For SY0-701, this maps directly to Objective 4.2 (Security Operations) and involves understanding manual and automated code review techniques, common vulnerabilities, and how to integrate reviews into the Software Development Lifecycle (SDLC). Security code review is a proactive defense that reduces the risk of exploitable flaws reaching production. Mastering this topic is essential for the exam and for real-world secure coding practices.
Jump to a section
Imagine you are the chief architect for a skyscraper. Before construction begins, you and a team of peer architects gather to review the blueprints. You don't just glance at the drawings—you trace every load-bearing wall, every electrical conduit, and every fire escape route. You ask: 'What happens if a column is removed here? Could a small design flaw cause a cascading collapse?' This is exactly what a security code review does for software. The blueprints are the source code; the architects are the reviewers. They examine the code line by line, looking for vulnerabilities like buffer overflows, SQL injection, or insecure cryptographic implementations. They simulate attack scenarios in their minds: 'What if an attacker sends a specially crafted input to this function? Could they bypass authentication?' The review is conducted before the code is built (compiled and deployed). Finding a flaw in the blueprint costs a few hours of redrawing; finding it after the steel frame is up costs millions. In security code review, catching a vulnerability before deployment saves incident response costs, data breach fines, and reputational damage. Just as a blueprint inspection ensures the building can withstand earthquakes and fires, a security code review ensures the software can withstand malicious inputs, privilege escalation attempts, and data exfiltration.
What is Security Code Review?
Security code review is the systematic examination of application source code to identify security flaws that could be exploited by attackers. Unlike functional testing, which checks if the code does what it should, security code review checks if the code does what it should NOT—like allowing unauthorized access, leaking sensitive data, or crashing under malformed input. It is a form of static analysis (analyzing code without executing it) that can be performed manually by security engineers or automatically by tools. The goal is to find vulnerabilities early in the SDLC, ideally during the coding phase, when remediation is cheapest and fastest.
How It Works Mechanically
Security code review follows a structured process: 1. Preparation: The reviewer understands the application architecture, threat model, and data flow. They obtain the source code, build instructions, and any existing security requirements. 2. Automated Scanning: Static Application Security Testing (SAST) tools like SonarQube, Checkmarx, or Fortify scan the codebase for known vulnerability patterns (e.g., SQL injection via unsanitized user input). These tools flag potential issues with severity ratings. 3. Manual Review: The reviewer manually inspects high-risk areas: authentication logic, authorization checks, input validation, cryptographic implementations, and error handling. They trace data from entry points (e.g., HTTP request parameters) to sinks (e.g., database queries, file writes). 4. Verification: For each finding, the reviewer confirms it is a true positive (not a false positive) by analyzing the code context. They may write a proof-of-concept exploit to demonstrate impact. 5. Reporting: Findings are documented with severity (Critical, High, Medium, Low), affected files, remediation recommendations, and references to OWASP Top 10 or CWE identifiers.
Key Components, Variants, and Standards
- Manual vs. Automated: Automated tools are fast but produce false positives; manual review is thorough but time-consuming. Best practice uses both. - Standards: OWASP Top 10 (2021) lists common vulnerabilities like Broken Access Control (A01), Cryptographic Failures (A02), Injection (A03). CWE (Common Weakness Enumeration) provides IDs like CWE-89 (SQL Injection), CWE-79 (XSS). - Variants: - Peer Review: Developer reviews another developer's code for security issues. - Formal Review: Scheduled meeting with security team, architects, and developers. - Over-the-Shoulder: Informal, ad-hoc review. - Tool Integration: SAST tools integrate into CI/CD pipelines (e.g., Jenkins, GitLab CI) to automatically scan every commit. Tools like GitHub CodeQL use query-based analysis.
How Attackers Exploit Vulnerabilities Found in Code Review
Attackers do not exploit the code review itself; they exploit the vulnerabilities that code review aims to find. For example:
- SQL Injection: If code concatenates user input directly into SQL queries, an attacker can input ' OR '1'='1 to bypass authentication or dump the database.
- Cross-Site Scripting (XSS): If output is not escaped, an attacker injects <script>alert('xss')</script> to steal cookies.
- Insecure Deserialization: If code deserializes untrusted data, an attacker can craft a malicious serialized object to execute arbitrary code (e.g., CVE-2015-4852 in Apache Commons Collections).
Real Command/Tool Examples
Using OWASP ZAP for dynamic analysis (complementary to code review):
zap.sh -cmd -quickurl http://example.com -quickout report.htmlUsing SonarQube for static analysis:
sonar-scanner \
-Dsonar.projectKey=my_project \
-Dsonar.sources=. \
-Dsonar.host.url=http://localhost:9000 \
-Dsonar.login=myauthtokenUsing CVE search:
cve-search -p apache 2>&1 | grep -i "remote code execution"Standards and Frameworks
NIST SP 800-115: Technical Guide to Information Security Testing and Assessment, includes code review.
OWASP Code Review Guide: Detailed methodology and checklists.
BSIMM (Building Security In Maturity Model): Measures maturity of security practices including code review.
Key Metrics
False Positive Rate: Percentage of flagged issues that are not real vulnerabilities.
Time to Remediate: Average time from finding to fix.
Vulnerability Density: Number of vulnerabilities per thousand lines of code (KLOC).
Identify High-Risk Areas
Begin by reviewing the threat model and architecture to identify components that handle sensitive data, authentication, or external input. Focus on code that processes user input, controls access, or performs cryptographic operations. Tools like threat modeling diagrams help map data flows. In logs, you might see comments like 'TODO: fix this later' near risky code. This step ensures effort is concentrated where vulnerabilities are most likely.
Automated SAST Scanning
Run a Static Application Security Testing tool (e.g., SonarQube, Checkmarx, Fortify) against the entire codebase. The tool parses the code into an abstract syntax tree and applies rules for common vulnerabilities. For example, it flags unsanitized user input concatenated into SQL queries as potential SQL injection. Output is a list of findings with severity, file location, and line numbers. The tool may also provide CWE IDs. Reviewers must triage these findings, eliminating false positives (e.g., sanitization done in a different function the tool didn't see).
Manual Review of Critical Paths
Manually inspect the code paths identified in step 1. Trace data from input (e.g., `request.getParameter()`) to sinks (e.g., `executeQuery()`). Look for missing input validation, improper output encoding, hard-coded credentials, or weak cryptography. Use a browser to view the code in an IDE with security plugins (e.g., Visual Studio Code with SonarLint). Take notes on each finding, including the exact code snippet. This step catches logic flaws that automated tools miss, such as business logic bypasses.
Verify Each Finding
For each potential vulnerability, confirm it is exploitable. For example, if a SQL injection is suspected, craft a proof-of-concept input in a test environment. If the application is not running, analyze the code to see if input escapes are missing. Check if compensating controls exist (e.g., WAF rules). Document the impact: e.g., 'An attacker can extract all user passwords via blind SQL injection.' This step separates true vulnerabilities from false positives and provides evidence for developers.
Report and Remediate
Compile a report with all confirmed vulnerabilities, prioritized by severity (Critical, High, Medium, Low). Include CWE ID, OWASP category, affected files, and remediation steps (e.g., 'Use parameterized queries instead of string concatenation'). Assign findings to developers with a deadline. Track remediation in a bug tracker (e.g., Jira). After fixes, re-scan with SAST and re-review manually to ensure no new issues were introduced. The final sign-off confirms all critical and high findings are resolved.
Scenario 1: E-Commerce Application – SQL Injection
A financial services company conducts a security code review of their new payment portal. The SAST tool flags a critical SQL injection in the order lookup function. The code concatenates user-supplied order ID directly into a query: String query = "SELECT * FROM orders WHERE id = '" + orderId + "'";. The manual reviewer confirms it by crafting an input like ' OR '1'='1 in a test environment, which returns all orders. The correct response is to rewrite the query using parameterized statements (PreparedStatement in Java). The developer initially argues that input is sanitized elsewhere, but the reviewer shows the sanitization is applied only to the name field, not the orderId. Common mistake: relying on client-side validation alone.
Scenario 2: Healthcare App – Hardcoded Credentials During a review of a mobile health app, the reviewer finds hardcoded API keys and database passwords in the source code. The keys are used to authenticate to a third-party lab results service. The automated tool flags these as 'Hardcoded Credentials' (CWE-798). The manual review confirms they are production keys. The correct response is to remove the keys from code, store them in a secure vault (e.g., HashiCorp Vault), and rotate them immediately. The developer had committed the keys to a public GitHub repo by accident; the reviewer checks git history and finds the keys were exposed for 2 weeks. The common mistake is thinking that obfuscation (e.g., Base64 encoding) is sufficient; it is not.
Scenario 3: Government Portal – Insecure Direct Object Reference (IDOR)
A manual reviewer examines a document download feature. The URL pattern is /download?id=123. The code does not verify that the logged-in user owns document 123. The reviewer writes a script to iterate IDs and successfully downloads documents belonging to other users. The correct response is to implement access control checks: verify the user's role and ownership before serving the file. The developer initially claims the ID is random, but the reviewer demonstrates that sequential IDs are predictable. Common mistake: assuming obscurity provides security.
What SY0-701 Tests
Objective 4.2 (Security Operations) covers security code review as part of secure software development. Key sub-objectives:
Differentiate between manual and automated code review.
Understand the role of code review in the SDLC (e.g., shift-left security).
Recognize common vulnerabilities found in code review: SQL injection, XSS, buffer overflow, insecure deserialization, hardcoded credentials.
Know that SAST (Static Application Security Testing) analyzes source code without execution, while DAST (Dynamic Application Security Testing) tests running applications.
Understand that code review should be performed before deployment and can be integrated into CI/CD.
Common Wrong Answers and Why
"Code review is only for finding logic errors, not security issues." – Wrong; security code review specifically targets vulnerabilities.
"Automated tools can replace manual review." – Wrong; tools miss business logic flaws and have false positives.
"Code review is performed after deployment." – Wrong; it is a pre-deployment activity.
"DAST is a type of code review." – Wrong; DAST tests running applications, not source code.
Specific Terms and Acronyms
SAST – Static Application Security Testing
DAST – Dynamic Application Security Testing
OWASP Top 10 – List of most critical web application security risks
CWE – Common Weakness Enumeration (e.g., CWE-89 for SQL injection)
SDL – Security Development Lifecycle (Microsoft)
BSIMM – Building Security In Maturity Model
Trick Questions
Question that says "Which tool would you use to find vulnerabilities in source code?" – Answer: SAST (not DAST, not vulnerability scanner).
Question that says "During which phase of SDLC should code review occur?" – Answer: Implementation (coding) phase, before testing.
Question that says "What is the primary advantage of manual code review over automated?" – Answer: Can detect business logic flaws.
Decision Rule
If the scenario describes analyzing source code (not running application), the answer involves SAST or manual code review. If it describes testing a running application with simulated attacks, it is DAST or penetration testing. If the question asks about finding vulnerabilities early, choose 'code review' or 'shift-left testing'.
Security code review is a proactive measure to find vulnerabilities before deployment.
SAST tools analyze source code without execution; DAST tests running applications.
Manual review is necessary for business logic flaws and to validate automated findings.
Common vulnerabilities found include SQL injection (CWE-89), XSS (CWE-79), and hardcoded credentials (CWE-798).
Code review should be integrated into the SDLC during the implementation phase (shift-left).
OWASP Top 10 provides a baseline for common web application vulnerabilities.
Automated SAST tools like SonarQube, Checkmarx, and Fortify are commonly used.
False positives from SAST must be triaged manually to avoid wasted effort.
Code review findings should be prioritized by severity and tracked to remediation.
Security code review is a key component of secure coding standards and regulatory compliance (e.g., PCI DSS).
These come up on the exam all the time. Here's how to tell them apart.
Manual Code Review
Human-led, uses expertise and intuition
Can detect business logic flaws and complex attack chains
Time-consuming and expensive
Low false positive rate (if reviewer is skilled)
Scalability limited by available reviewers
Automated SAST
Tool-led, uses pattern matching and heuristics
Cannot detect business logic flaws
Fast and cost-effective for large codebases
High false positive rate
Easily integrated into CI/CD pipelines
Mistake
Automated SAST tools find all security vulnerabilities.
Correct
SAST tools have high false positive rates and miss business logic flaws, race conditions, and multi-step attacks. Manual review is essential for comprehensive coverage.
Mistake
Code review is only for critical applications.
Correct
All applications that handle sensitive data or are internet-facing should undergo code review. Even internal tools can be entry points for attackers.
Mistake
Code review can be performed after deployment with no risk.
Correct
Finding vulnerabilities after deployment is costly and may require emergency patches. Code review should be done before deployment to minimize risk and cost.
Mistake
If code passes automated SAST, it is secure.
Correct
A clean SAST report does not guarantee security. The tool may not have rules for all vulnerability types, and attackers often exploit logic flaws that tools cannot detect.
Mistake
Security code review is the same as debugging.
Correct
Debugging focuses on functional correctness (e.g., crashes, incorrect output). Security code review focuses on vulnerabilities that could be exploited maliciously, even if the code functions correctly.
SAST (Static Application Security Testing) analyzes source code, bytecode, or binaries without executing the application. It finds vulnerabilities early in the SDLC. DAST (Dynamic Application Security Testing) tests a running application by simulating attacks, finding vulnerabilities that appear only at runtime. For the exam, remember: SAST = code review, DAST = penetration testing of live app.
According to OWASP Top 10 (2021), common vulnerabilities include Broken Access Control, Cryptographic Failures, Injection (SQL, OS, LDAP), Insecure Design, Security Misconfiguration, and Vulnerable Components. In code review, specific examples are SQL injection (CWE-89), XSS (CWE-79), and hardcoded secrets (CWE-798).
Ideally, every code change should be reviewed for security, especially for high-risk applications. At a minimum, conduct reviews for major releases, after significant refactoring, and when integrating third-party components. Continuous integration pipelines can automate SAST scans on every commit.
No. Automated SAST tools are effective at catching known vulnerability patterns but produce false positives and miss logic flaws. Manual review is essential for complex vulnerabilities, business logic issues, and to verify automated findings. A combination of both is best practice.
Threat modeling identifies assets, attackers, and attack vectors, guiding the code review to focus on high-risk areas. It helps reviewers understand data flows and trust boundaries, making the review more efficient. For example, if threat modeling identifies authentication as a critical component, the reviewer will scrutinize authentication code thoroughly.
Deliverables include a report listing each vulnerability with severity, CWE ID, affected file/line number, description, proof of concept (if applicable), and remediation recommendation. A summary of overall risk, false positives identified, and metrics (e.g., number of findings per KLOC) may also be included.
Code review is part of the 'implementation' phase, after coding and before testing. It is a key activity in secure SDLC frameworks like Microsoft SDL and OWASP SAMM. Integrating code review into the CI/CD pipeline enables 'shift-left' security, catching vulnerabilities early.
You've just covered Security Code Review — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?