Source first, not scanner output
A penetration test of a running application answers what an attacker can do today. A code review answers what is waiting in the repository — including the bug that is not reachable yet, the helper that every new endpoint will call wrong, and the secret that should never have been committed.
We read the code. Tools help with the boring half. They do not replace a tester who understands how your application is supposed to work.
This is not a web application penetration test with the source folder open. That engagement still starts from HTTP. This one starts from the tree.
What we look for
Injection and unsafe handling of untrusted input, including the cases a black-box test never reaches because the route is unfinished or gated.
Authorization that will not hold as the application grows — missing checks on a new handler, a helper that trusts the client, an IDOR waiting on the next feature.
Secrets, crypto, and session handling used in ways that look fine until someone actually reads them.
Dependencies and build-time trust, where the interesting finding is often in how the project is assembled rather than in a line of business logic.
How it runs
You give us a repository (or a snapshot), the branch that matters, and the context a new engineer would need: how auth works, where the trust boundaries are, which parts are in scope. We review that surface, confirm what we can, and write findings against the code rather than against a URL.
Where a finding is clearer with a running instance, we use one. Where it is clear from the source, we do not waste a day proving what the code already says.
What you receive
Line-level findings with the path through the code, the impact if it ships, and a specific change — not a generic “sanitize input” recommendation. Developers should be able to open the report and the file at the same time.