A code security review is the systematic examination of source code to identify vulnerabilities, misconfigurations, and security weaknesses before code reaches production. It goes beyond functional code review (does it work?) to ask: can this code be exploited?
This guide provides a working checklist your team can apply to every pull request — covering the categories where vulnerabilities most commonly hide.
When to Conduct a Security Review
Not every code change needs a full security review. Prioritise based on risk:
Always review (high risk):
- Authentication and authorization changes
- Payment or financial transaction logic
- Cryptographic implementations
- Infrastructure as Code changes to production
- API endpoint changes that handle user input
- Changes to access control or permission models
- Dependencies added or upgraded
Review on significant changes (medium risk):
- Database queries and data access patterns
- File upload or download functionality
- External API integrations
- Configuration changes
- Error handling and logging modifications
Automated scanning sufficient (lower risk):
- UI-only changes with no data handling
- Documentation updates
- Test-only changes
- Styling and layout modifications
The Checklist
1. Authentication & Session Management
- Passwords are hashed with bcrypt, argon2, or scrypt — never MD5 or SHA-1
- Session tokens are cryptographically random with sufficient entropy (128+ bits)
- Session tokens expire after a reasonable inactivity period
- Failed login attempts are rate-limited (account lockout or progressive delays)
- Multi-factor authentication is enforced for sensitive operations
- Password reset tokens are single-use and time-limited
- Authentication logic does not leak information (same response for valid/invalid usernames)
- OAuth/OIDC flows validate state parameters and nonce values
- JWT tokens are validated for signature, expiration, and issuer
2. Authorization & Access Control
- Every API endpoint enforces authorization (not just authentication)
- Server-side authorization checks cannot be bypassed by client-side manipulation
- Role-based access follows principle of least privilege
- Direct object references are validated against the authenticated user’s permissions
- Admin functionality is separated and requires elevated authentication
- Horizontal privilege escalation is prevented (user A cannot access user B’s resources)
- API rate limiting is applied per-user and per-endpoint
3. Input Validation & Injection Prevention
- All user input is validated on the server side (client-side validation is supplementary only)
- SQL queries use parameterised statements or prepared statements — never string concatenation
- HTML output is encoded to prevent cross-site scripting (XSS)
- File paths are validated to prevent path traversal (
../attacks) - XML parsing disables external entity processing (XXE prevention)
- Command injection is prevented by avoiding shell execution with user input
- Regular expressions are checked for ReDoS (catastrophic backtracking) potential
- Content-Type headers are validated on file uploads
- Input length limits are enforced to prevent buffer-overflow-style attacks
4. Cryptography
- No deprecated algorithms in use (MD5, SHA-1, DES, RC4, ECB mode)
- AES uses GCM mode (authenticated encryption), not ECB or CBC without HMAC
- RSA keys are 2048 bits minimum (4096 preferred)
- Random number generation uses cryptographically secure sources (
secretsmodule in Python,crypto.randomBytesin Node) - IVs and nonces are never reused
- Secrets are not derived from predictable sources
- TLS 1.2+ is enforced for all external communication
- Certificate validation is not disabled (no
verify=FalseorrejectUnauthorized: false)
5. Secrets & Credentials
- No hardcoded credentials, API keys, or tokens in source code
- No secrets in configuration files committed to version control
- Environment variables or secrets management (Vault, AWS Secrets Manager) used for all credentials
- Secrets are not logged in application output or error messages
- API keys are scoped to minimum required permissions
- Credentials are rotated on a defined schedule
- Test/development credentials are clearly separated from production
6. Dependency & Supply Chain Security
- Dependencies are pinned to specific versions (no open ranges like
^or*) - New dependencies are from well-maintained, reputable packages
- Known vulnerabilities in dependencies are checked (SCA scan passes)
- Lock files (
package-lock.json,yarn.lock,Pipfile.lock) are committed and up to date - No unnecessary dependencies added (minimise attack surface)
- License compatibility is verified for new dependencies
- Package names are verified (not typosquatted variants)
7. Error Handling & Logging
- Errors do not expose stack traces, internal paths, or system information to users
- Sensitive data (passwords, tokens, PII) is never written to logs
- Security-relevant events are logged (login attempts, permission failures, data access)
- Logs include sufficient context for incident investigation (timestamp, user, action, resource)
- Exception handling does not swallow errors silently
- Error responses do not differ based on the existence of resources (prevents enumeration)
8. Infrastructure as Code
- IAM policies follow least privilege (no
"Action": "*"or"Resource": "*") - Security groups do not allow unrestricted ingress (
0.0.0.0/0) on management ports - Storage resources (S3, EBS, RDS) have encryption enabled
- Logging is enabled (CloudTrail, VPC flow logs, access logs)
- Public access is explicitly denied unless required and documented
- Container images do not run as root
- Kubernetes pods have resource limits and network policies defined
9. AI-Generated Code (Additional Checks)
In 2026, AI-generated code requires additional scrutiny due to consistent vulnerability patterns:
- No placeholder credentials (e.g.,
password = "admin123" # TODO: change) - Input validation is present (AI frequently omits it)
- Cryptographic implementations use modern algorithms (AI defaults to deprecated ones)
- IaC configurations are not overly permissive (AI defaults to
*permissions) - Package names are verified (AI hallucinate package names that attackers register)
- Authentication logic includes all edge cases (AI handles happy path only)
- SQL queries use parameterised statements (AI still produces string concatenation)
Automating the Review
Manual code security review is valuable but doesn’t scale. The most effective approach combines automation with human judgement:
Automated (every PR, no exceptions)
- SAST scanning for known vulnerability patterns
- Secret detection across 2,000+ patterns
- SCA for dependency vulnerabilities
- IaC scanning for misconfigurations
- PR-level quality gates that block merge on critical findings
Human review (risk-based, for qualifying changes)
- Authentication and authorization logic
- Cryptographic implementations
- Complex business logic with security implications
- Infrastructure changes to production
- AI-generated code in sensitive areas
AI-assisted (augments both)
- GenAI-powered remediation suggestions for automated findings
- AI-generated fix patches that maintain code style and context
- Automated triage that prioritises findings by exploitability
How Cloudanix Supports Code Security Review
Cloudanix Code Security automates the scanning portion of code security review:
- PR-level scanning — every pull request is automatically scanned for vulnerabilities, secrets, and misconfigurations before merge
- SAST + SCA + Secrets + IaC — covers all categories in the checklist above with a single integration
- AI-powered remediation — findings come with GenAI fix suggestions that reduce resolution time from days to minutes
- Code-to-runtime correlation — findings from code review are contextualised with cloud posture, helping teams prioritise what matters in production
- GitHub and Bitbucket integration — one-click connect, findings as PR comments, JIRA ticket creation
For AI-generated code specifically, combining code scanning with Coding Agent Guardrail addresses both the output (vulnerabilities in generated code) and the actor (the agent’s access to secrets and credentials during generation).