Secure Code Review at Scale

Last updated: April 29, 2026

A Bengaluru SaaS team’s quarterly external pen-test kept finding the same vulnerability classes — IDOR (insecure direct object reference) and SSRF — quarter after quarter. The team was patching individual instances; the root cause was that nobody had ever looked at the codebase systematically. After they started doing structured secure code reviews on every PR plus quarterly deep dives, IDOR findings dropped 80% within two release cycles. This module covers secure code review as both a code-author skill and a structured programme.

Three modes of secure code review

Vulnerability classes to hunt

OWASP Top 10 (2021, refreshed 2025-watch list)

• A01 Broken Access Control — IDOR, missing authorisation, privilege escalation
• A02 Cryptographic Failures — weak algorithms, hardcoded secrets, weak randomness
• A03 Injection — SQL, OS command, LDAP, XPath, NoSQL, template injection
• A04 Insecure Design — design flaws no code review will catch alone
• A05 Security Misconfiguration — defaults, debug endpoints, verbose errors
• A06 Vulnerable Components — outdated dependencies
• A07 Authentication Failures — weak password rules, session fixation, JWT errors
• A08 Software and Data Integrity Failures — unsigned updates, deserialisation
• A09 Logging Failures — missing audit logs, sensitive data in logs
• A10 SSRF — server-side request forgery

The structured review checklist

Authentication and session

• Are passwords hashed with bcrypt/argon2 (not SHA-256, not MD5)?
• Is session token unpredictable, server-side, with appropriate expiry and HttpOnly/Secure flags?
• Is JWT validation checking alg, iss, aud, exp, signature?
• Is MFA enforced for sensitive endpoints?

Authorisation

• Every endpoint that returns data — where is the authorisation check?
• Are object IDs validated against the current user’s permission?
• Are admin endpoints protected by both role check AND audit logging?
• Vertical (privilege escalation) and horizontal (cross-user) checks both present?

Input handling

• SQL: parameterised queries, not string concatenation. Is the ORM used safely?
• Command execution: is shell invocation needed? If yes, is input strictly validated?
• Server-side rendering: is template engine auto-escaping output?
• File upload: is type validated by content (not extension)? Is path normalised?
• URL: SSRF protection — is outbound HTTP restricted to allow-list?

Output handling

• HTML output context-escaped per location (HTML body vs attribute vs JS)?
• Errors don’t leak stack traces, paths, internal IPs?
• API responses don’t include extra sensitive fields (over-disclosure)?
• CSV / spreadsheet output protects against formula injection?

Crypto and secrets

• No hardcoded secrets (use scanner: gitleaks, trufflehog)
• Random number generation uses CSPRNG (secrets in Python, crypto.randomBytes in Node)
• TLS for all sensitive transport; certificate validation enabled
• At-rest encryption for PII/financial data

The Bengaluru SaaS rebuild

Their structured programme:

1. Pre-commit hooks block common patterns (eval(, hardcoded secrets matching gitleaks rules, SELECT * FROM ${)
2. CI runs Semgrep with custom rules from past pen-test findings — same finding never lands twice
3. Per-PR security reviewer required for files in /api/, /auth/, /payment/ paths
4. Quarterly deep-dive: 2-day code review on one subsystem, rotating scope
5. Findings fed back into Semgrep rules — mistakes become detection
6. Public security CHANGELOG of internally-found and fixed issues — drives engineering ownership

Two-cycle outcomes:

• External pen-test findings: 23 → 4
• Critical / high findings: 6 → 0
• Time-to-fix for findings: 14 days → 3 days
• Engineer security awareness scores measurably higher

Tools that augment code review

• SAST — Semgrep, SonarQube, Checkmarx, Veracode. Best for catching known patterns at scale
• Secrets scanning — gitleaks, trufflehog, GitHub native
• SCA (dependency scanning) — Snyk, Dependabot, OWASP Dependency-Check, npm audit, pip-audit
• DAST — Burp, OWASP ZAP, Acunetix. Different layer: tests running app
• IAST / runtime instrumentation — Contrast, Seeker
• Codeql / custom queries — for complex multi-file flows; SAST catches the basics

What humans find that tools miss

• Authorisation logic correctness — tools see the check exists; humans see it’s checking the wrong thing
• Business logic flaws — coupon-stacking, race conditions in counter increments, state-machine bypasses
• Cryptographic mis-use — using HMAC with a public key, JWT with HS256 + asymmetric key, IV reuse
• Design-level issues — ad-hoc auth instead of using the framework’s auth
• Insecure-by-default config — debug enabled, error pages verbose, CORS wildcard

Indian compliance mapping

• RBI Cyber Framework — secure development lifecycle (SDLC) with code review explicitly required
• SEBI CSCRF — secure coding and code review for Q-RE / MII applications
• DPDP §10 (Significant Data Fiduciary) — DPIA includes code review for high-risk processing
• UIDAI — code review for AUA / KUA implementations
• ISO 27001:2022 A.8.28 — secure coding
• PCI DSS 6.3 — code-review requirement for payment-handling code

Common mistakes

• Treating code review as just a quality gate, not security gate
• Reviewing only the lines in the PR — context is in the called functions, the data flow upstream
• Tooling-only programme — Semgrep finds 30%; humans find the rest
• One security reviewer for the whole org — bottleneck and burnout
• Findings tracked but not closed — backlog grows; debt accumulates
• No knowledge transfer — same junior makes the same mistake on the next project

Try this in your environment

1. Pick the most recent external pen-test report. For each finding, can you write a Semgrep rule that would have caught it? That’s your enforcement layer.
2. Pick the riskiest 50 lines of code in your codebase (auth, payment, data-export). Has anyone reviewed them in the last 12 months?
3. Run gitleaks detect against your repo history. Anything found = rotate-and-investigate.
4. Add Semgrep with the OWASP Top 10 ruleset to CI, in audit-mode first. Read the findings; tune.
5. Schedule a 2-day deep-dive code review on one subsystem in the next quarter. Document the methodology.

Secure code review is the discipline that closes the loop between “we found this in pen-test” and “we don’t write code that fails like this.” Tools amplify; humans decide. Build both.