A pull request gets approved. The automated tests pass. The feature works as expected, and the code is merged into the main branch.
Does that mean the application is secure?
Not necessarily.
A feature can work perfectly and still contain a security vulnerability. An API may expose another user's information, a database query may allow SQL injection, or a configuration change may accidentally expose sensitive credentials.
This is why developers need to think beyond functional testing.
The October 2026 Binance security incident has brought application and infrastructure security into wider discussion. Binance's initial investigation suggested that a compromised DevOps engineer's laptop may have allowed an attacker to access a service container and submit unauthorized withdrawal transactions. The estimated incident impact was approximately $6.3 billion. The investigation was ongoing, and Binance said it had found no evidence of a wallet private-key leak.
The incident does not establish that insecure code reviews caused the breach. But it raises an important question for every engineering team: are we reviewing the security implications of our changes, or only checking whether the code works?
Here are seven practices developers should include in their code review process.
1. Review authentication and authorization
Authentication verifies who a user is. Authorization determines what that user is allowed to access.
These are different security responsibilities.
Imagine an application where users can view their invoices through an API:
GET /api/invoices/1024
The application should not simply check whether the user is logged in. It should also verify that the requested invoice belongs to that user or an organization they are authorized to access.
This type of mistake can lead to insecure direct object references and broken access control.
During code review, ask whether every sensitive operation checks the correct permissions.
2. Check for SQL injection and unsafe input handling
Applications receive input from browsers, APIs, uploaded files, and external services. Developers should never automatically trust that input.
For database operations, use parameterized queries instead of constructing SQL statements through string concatenation.
Also examine how the application handles HTML output, file paths, shell commands, and user-supplied parameters.
Look for risks such as:
- SQL injection
- Cross-site scripting (XSS)
- Command injection
- Path traversal
- Unsafe file uploads
Validation and safe APIs should be used at the appropriate boundaries.
3. Look for hardcoded secrets
API keys, database passwords, private tokens, and cloud credentials should not be committed to a repository.
Check source files, configuration files, test data, sample scripts, and environment-related changes.
If a real secret has been committed, removing it from the latest version is not sufficient. Revoke or rotate it and investigate whether it was exposed elsewhere.
4. Review dependency changes
Third-party libraries save development time, but they also introduce external code into your application.
Before approving a new dependency, check whether it is maintained, whether its version has known vulnerabilities, and whether it is actually necessary.
Pay attention to unexpected dependency changes and transitive packages.
A small update can introduce new code paths that deserve security review.
5. Examine error handling and logging
Error messages can accidentally expose database information, internal paths, tokens, or implementation details.
Review whether production errors reveal sensitive information to users. Check whether logs store passwords, session tokens, or confidential personal data.
Good logging should help developers investigate incidents without creating another security problem.
6. Review configuration and permission changes
Security problems do not always come from application logic.
A pull request may change:
- Cloud IAM permissions
- Docker configuration
- API access policies
- CORS settings
- Firewall rules
- Environment variables
- Authentication requirements
Review these changes carefully. A small configuration update can expose an internal service or grant excessive access.
7. Combine manual review with automated security scanning
Manual code review is valuable, but developers cannot always inspect every file and dependency in a large repository.
Automated security analysis can help identify potential issues that deserve attention.
OWASP's Secure Code Review guidance recommends considering both baseline reviews of the broader codebase and focused reviews of individual changes. This helps teams examine existing weaknesses as well as newly introduced risks.
Codzee can support this process by scanning an entire GitHub repository and generating a detailed PDF security analysis report. Developers can use the report to investigate potential code-level issues and support their security review process.
However, automated findings should always be evaluated in context. A scan cannot guarantee that an application has no vulnerabilities, and it does not replace threat modeling, manual review, or runtime testing.
Final thoughts
Code reviews should not end with the question, "Does this code work?"
Developers should also ask:
- Can an unauthorized user access this functionality?
- Can untrusted input change how the application behaves?
- Are credentials or sensitive data exposed?
- Have new dependencies introduced additional risk?
- Could this configuration change weaken existing protections?
Building secure software is a shared responsibility. When developers make security part of everyday pull requests, they can identify many problems before those changes reach production.
The best time to find a security weakness is while the code is still being reviewed—not after an attacker discovers it.
Sources
- Binance, Security Incident Update, October 30, 2026.
Top comments (0)