Context
Architecture, critical flows, roles and security-sensitive code.
Code review focus
Indicative view, not a measurement: 3 primary focus, 2 usual component, 1 context or scope-dependent, 0 outside normal scope.
| Area | Level |
|---|---|
| Design and trust boundaries | part of the test |
| Authentication and authorisation | primary focus |
| Inputs and data processing | primary focus |
| Business logic | primary focus |
| Secrets and cryptography | primary focus |
| Dependencies and builds | limited focus |
Code review reveals how applications actually decide
Code shows how applications handle access, data and errors. Review finds weaknesses difficult to discover through running applications, such as missing checks in rarely used functions, unsafe deserialisation or cryptographic misuse.
We review an agreed code revision, tying results precisely to the version you release or deliver.
- Authentication, session management and server-side authorisation.
- Input handling, database queries, templates and system calls.
- Secrets, cryptography and sensitive data handling.
- Business logic and error handling.
- Framework security and build configuration.
Manual review and SAST complement each other
Static analysis quickly scans code for suspicious patterns but cannot reliably judge business logic, context or exploitability. We use it to support manual review, as recommended by the OWASP Secure Code Review Cheat Sheet.
We classify findings using CWE so teams can research and track them. Control requirements can be agreed against OWASP ASVS. This is a methodological framework, not code certification.
SAST
Automated analysis of the agreed revision to guide manual work.
Manual review
Critical code review, tool finding verification and false positive removal.
Confirmation
Where possible and agreed, we also verify findings against the running application.
Typical finding categories
Missing authorisation
Operations lacking permission or record ownership checks, often outside main user flows.
Injection
Queries, commands or templates assembled from untrusted input.
Secrets in code
Passwords, keys or tokens stored in repositories or configuration.
Cryptography
Outdated algorithms, predictable values or custom implementations instead of established libraries.
Error handling
Internal information leaked in errors or unsafe behaviour on unexpected input.
Deliverables for developers and management
Handover format, such as issue tracker export, and retesting are agreed in the proposal.
- Management summary of risks and priorities.
- Findings with file, line and revision references, scenarios and impact.
- CWE classification and contextually justified severity.
- Recommended fixes and, where useful, safer implementation examples.
- A clear record of manually reviewed and automatically analysed areas.
What we need and review limitations
We need access to a specific code revision, architecture information and build instructions. Developer contacts help answer design and business logic questions.
For large codebases, manual review focuses on agreed critical areas. The report clearly identifies unreviewed areas. Review cannot prove the absence of other defects.
