As far as I know, penetration testing can be divided into black-box, gray-box, and white-box testing. But then what about secure code review? Is it part of white-box testing or is it separate?
Security code review is the process of auditing the source code for an application to verify that the proper security controls are present, that they work as intended, and that they have been invoked in all the right places. OWASP
With this in mind consider Grey-box testing:
A black-box tester is unaware of the internal structure of the application to be tested, while a white-box tester has access to the internal structure of the application. A grey-box tester partially knows the internal structure, which includes access to the documentation of internal data structures as well as the algorithms used. Wikipedia
Pentesters will identify vulnerabilities by reverse engineering software into assembly code and working from there to identify attack vectors, such as a buffer overflow. But, by the definition above secure code review must be white-box testing.
To answer your question, secure code review is performed by white-box testing, exclusively. There may be some instances where individuals could skew this definition to fit the example above, but as reverse engineering assembly code is not source code, I will not acknowledge this.
The difference between white box testing and source code review is that you do not channelize knowledge of availability of a vulnerability after reviewing the code in source code review, but in a white box testing you use this knowledge to create a working POC (Proof of Concept). In source code review you just point out the code snippet affected by the vulnerability, in white box testing we walk through the entire execution flow end to end to determine the vulnerability and create a POC.
The main difference is in the actual action performed. White box testing and secure code review share similar goals.
White box testing involves touching the product. At any level of testing, something is done with the product being tested - a function is called and its response is validated, for example, or someone pretending to be a user goes through a core flow. In any case, the software is physically tested; it must exist in some way, and it must be usable in some way. And then it must be used.
In secure code review, the product is not touched. It can be touched as a supplemental activity, perhaps, but the core function rather is reading. You read the source code, analyze it as you go, and ultimately try to identify and synthesize issues with it to correct. Secure code review is a subset of normal code review, which can involve analyzing for design, implementation, performance, aesthetics, etc.
One way to think of it is as the following:
- In white box testing, you use the product.
- In secure code review, you read the product.
Edit: the above is looking only at white box (to respond to the particular scope of OP's question), but the same principles apply in black and gray box testing. In any testing methodology, you must use the product as an inherent byproduct of the task nature of testing. This is (as explained above) not the same as with code review.