White-Box Source Code Review

It is a security assessment that reads the application source directly to find vulnerabilities, insecure patterns, and logic flaws at the code level — combining automated static analysis (SAST) and software composition analysis (SCA) with manual expert review, measured against the OWASP Code Review Guide, the OWASP ASVS, and the CWE Top 25.

SAST uses automated tools to scan for known patterns quickly and broadly, but it produces false positives and cannot judge business logic or reachability. Manual review has an engineer read the code in context and follow the data, catching authorization flaws, logic errors, and injection paths a tool misses. We use both, and triage the tool output rather than reporting it raw.

Black-box testing sees only what the running application exposes; source review sees every path, including the ones no request reaches during a test — a disabled feature, an admin-only branch, a race condition, a secret in the repository. The two are complementary, but source access finds classes of flaw a black-box test cannot observe.

Read-only access to the repository, over a channel you choose, plus enough context to build and understand the code (a brief walkthrough, the framework, the security-critical areas). We work across common web and backend languages and their frameworks; we agree the exact stack in scope during scoping.

Yes — software composition analysis identifies vulnerable and outdated dependencies, including transitive ones your code pulls in indirectly, and reports the fixed versions. A large share of real breaches start in a dependency, so this is part of every review, not an add-on.

Business-logic flaws, broken access control and IDOR, authorization gaps that depend on context, and injection or deserialization paths that only a data-flow trace reveals. A scanner matches patterns; it cannot know that this user should not reach that record, or that this workflow can be replayed.

Each finding gets a CVSS score for a common baseline, adjusted by the real impact in your application — what it exposes, how reachable it is, and what an attacker gains. We also map findings to the CWE weakness class and the relevant OWASP ASVS requirement, so the report ties to a recognized standard.

The review is read-only and static: we read the source, we do not run it against your production systems, and we handle your code under confidentiality with access limited to the engineers on the engagement. Nothing about it changes or reaches your running environment.

Yes — after you remediate we re-review the reported findings to confirm each fix holds and did not open a new gap. Duration depends on codebase size and complexity; a comprehensive review of a medium application typically runs about two to four weeks, and we give a firm estimate after scoping.