Secure code review: find weaknesses in implementation and trust
A security code review examines how an application enforces its security rules. It follows sensitive data and actions through the code, checks assumptions at trust boundaries and investigates weaknesses that automated tools or external testing may miss.
It differs from an ordinary peer review focused on readability, maintainability and general correctness, although the activities can support one another. Agree the security objectives, code version and coverage before work begins.
Reviewed: 26 October 2026.
Understand the methods and their limits
| Method | What it examines | Important limit |
|---|---|---|
| Manual security review | Design assumptions, data flows, access decisions and business logic in source. | Coverage depends on scope, time and reviewer access; it is not automatically every line. |
| SAST | Static analysis of source or compiled representations. | Findings need context and validation; custom logic and framework behaviour may be missed. |
| SCA | Third-party dependencies, versions and known advisories. | A vulnerable package listing is not proof that the affected function is reachable. |
| DAST | Behaviour of a running application from test inputs. | Only reachable and exercised paths are observed; source may remain unseen. |
| IAST | Instrumented observations while a running application is exercised. | Coverage depends on the tests and supported runtime. |
| RASP | Runtime protection or detection within the application environment. | It is a defensive control, not a source-code review or proof the code is corrected. |
Prepare the source and business context
- Identify the repository, commit or release, languages, frameworks and deployment model.
- Provide architecture and data flows, user roles, tenant boundaries and sensitive business operations.
- Include relevant configuration, dependency manifests, build/deployment definitions and generated-code boundaries.
- Explain third-party components, excluded modules and known findings.
- Agree secure access, intellectual-property handling, secrets management and evidence retention.
Prioritise authentication and recovery, authorisation, payment or approval logic, file handling, sensitive data processing and privileged integrations. A focused review of these paths can be more useful than a superficial scan of a very large repository.
Follow trust boundaries and consequential actions
| Area | Question to answer |
|---|---|
| Authorisation | Is every sensitive action checked on the server for the correct user, tenant and object? |
| Input and output | Does untrusted input reach queries, commands, templates, file paths or unsafe rendering without appropriate protection? |
| Identity and sessions | Are enrolment, login, recovery, tokens and logout handled safely? |
| Secrets and cryptography | Are credentials kept out of code and logs, and are proven libraries and appropriate key lifecycles used? |
| Business logic | Can a user bypass approval, alter a price, repeat an operation or exploit unexpected state transitions? |
| Dependencies and delivery | Are packages, build permissions and deployment secrets controlled and maintained? |
| AI and connected tools | If applicable, can untrusted model inputs or outputs trigger unauthorised data access or tool actions? |
Treat AI-generated code like other code: review the assumptions and behaviour. Sending proprietary source or secrets to an unapproved external tool creates an additional data-handling concern.
Run a review that developers can act on
Baseline review and change review serve different purposes
A baseline review explores the architecture, high-risk paths and inherited assumptions of an agreed codebase. A change review examines a proposed modification and its effect on existing controls. Reviewing a small diff is efficient, but may require reading callers, shared components and deployment configuration to understand the security effect.
For an assessment, agree the commit/release, available source and dependencies, excluded components and evidence needed. For normal development, use manageable changes with a description of intent, risk and tests. Add specialist review when an authentication flow, privilege boundary, parser or consequential transaction changes.
Trace a consequential path through the application
- Identify an entry point and the caller’s trust level. Include API, message queue, scheduled job and administrative paths where relevant.
- Follow the data and identity through validation, transformation, storage, downstream calls and output. Ask which component makes each security decision.
- Check where the action’s permissions and business conditions are enforced. A check in the browser is not enough if the server accepts the same operation directly.
- Examine failure and repeat/concurrent execution: a payment, password reset or approval should not become unsafe when requests fail, race or are retried.
- Validate the concern safely and describe the conditions that make it exploitable. Propose a correction and a regression test covering both allowed and disallowed behaviour.
Keep feedback specific and verify the correction
Reference the affected version, file/function and relevant control or invariant. Explain the impact and assumptions, distinguish a confirmed flaw from a question, and separate security blockers from style preferences. Let the author provide context while keeping the decision traceable.
After correction, review the patch and related paths, then run meaningful tests. Check that error handling or a different endpoint cannot bypass the fix. Record residual risk and any unreviewed components rather than treating the absence of tool alerts as approval.
The OWASP secure code review guidance explains baseline and incremental review. Use it to tailor the review method to the application rather than assuming every change needs the same depth.
Combine discovery, validation and correction
Automated alerts are leads, not final conclusions. Check whether the vulnerable path is reachable, which permissions are required, what controls intervene and what the effect would be. Use a safe test environment where runtime validation is needed.
For dependency findings, identify the package and version, relevant advisory, application use, available fix and compatibility implications. Do not suppress a finding solely because it was not exploited during a short test.
Worked example: a missing ownership check
An API handler accepts an invoice identifier, loads the invoice and returns it to any signed-in user. Authentication is present, but the handler does not verify that the invoice belongs to the user’s organisation.
The reviewer traces the identifier into the data-access layer, checks shared authorisation helpers and validates the behaviour with two authorised test tenants. The finding explains affected routes and the business consequence without exposing real customer records.
The fix should enforce the ownership or tenant rule centrally where appropriate and add negative tests. Retesting checks the original route and agreed equivalent operations; changing the user interface alone would not fix the server-side weakness.
Use the findings in development
| Report element | What developers need |
|---|---|
| Location and context | Relevant file/function and code version, with the path that makes the issue significant. |
| Evidence and prerequisites | A reproducible explanation and any required role, state or configuration. |
| Impact and priority | Potential effect on the service, with uncertainty and constraints stated. |
| Correction | A practical design or implementation change, plus related paths to investigate. |
| Verification | Tests demonstrating the intended restriction and checking for regressions. |
Assign findings to development owners and track them through review and release. Where an immediate fix is not possible, document temporary controls, residual risk and a deadline. A tool’s “fixed” status should be verified against the deployed version.
Integrate tools and people into the development lifecycle
| Stage | Practical activity | Decision to record |
|---|---|---|
| Design | Identify sensitive data, trust boundaries and misuse cases before implementing a consequential feature. | Which security properties must remain true? |
| Development / pull request | Combine peer review with applicable source, dependency and secret checks. | Which results block merge, and who resolves a justified exception? |
| Integration / test | Exercise relevant running paths and business rules, with suitable dynamic or instrumented checks where useful. | What behaviour was actually exercised, and what remains uncovered? |
| Release | Confirm approved changes, resolved findings, deployment permissions and secure configuration. | Is the assessed code the version being deployed? |
| Operation / change | Track dependency issues, incidents and changed assumptions; feed lessons back into review. | Does the change require a focused review or a broader reassessment? |
SAST may highlight patterns or data flows, SCA highlights dependency concerns, and DAST or IAST can add evidence from exercised runtime paths. Human review contributes business context and reasoning about trust. Tool coverage depends on language support, configuration, access and exercised behaviour. Keep limitations visible.
Protect the repository, review comments and collected evidence. Do not upload confidential code or secrets to an external service without authorisation and an appropriate handling agreement. Review generated code to the same security expectations as other code; automated suggestions do not transfer accountability away from the team.
Common questions
Will every line be reviewed?
Only if that is explicitly agreed and feasible. Most security reviews prioritise high-risk paths and use sampling and tools. Require a clear coverage statement.
Can scanning replace manual review?
No single method covers all security questions. Automated checks are useful for repeatable patterns; manual review adds business context, trust analysis and validation.
Do we still need penetration testing?
Often yes. Runtime configuration, deployed integrations and behaviour can differ from the reviewed source. Choose complementary testing based on risk.
Further guidance
OWASP Code Review Guide · OWASP Web Security Testing Guide · Planning penetration testing
Need Help?
If you have any questions about cyber security or would like a free consultation, don't hesitate to give us a call!
For More Information Please Contact Us
ACCREDITATIONS
