I believe this question is best addressed in chapter 4 of The Art of Software Security Assessment, a book by Mark Dowd, Justin Schuh, and John McDonald.
Without it as a reference, I can safely tell you that the best method is using runtime data along with source-code while determining "hits" (or traces, aka coverage) using black-box testing -- but only after a threat-model and general architecture of the system is well-known.
The authors also appear to like secure static code analysis when combined with candidate-point strategies, although it's my opinion that these can vary wildly in value assuming the following are not true:
- The language, and its base class libraries, must be supported by the secure static analysis tool
- The entire system must usually be available. I.e. it must include buildable source code including all third-party/contrib components and external libraries -- possibly even to include the system compiler, VM, or other artifacts of the original system
- All external components/libraries that are not a part of the base class libraries must have sources and sinks defined in the secure static analysis tool's source-sink-passthru database. The intricacies of some passthrus (i.e. filters) can vary by implementation or implementer, and thus almost always require custom configuration
- Additional use of certain patterns or architectural code elements could cause other variations, which could require customization that isn't possible with most modern secure static analysis tools
For the reasons above, as well as the reasons put forth in the NIST SATE studies (done by NIST SAMATE), I find it difficult to recommend many secure static analysis tools for use in white box analysis. It is almost always simply better to use code comprehension strategies that most likely involve reading the source code from top to bottom, which is really very important if you are looking for managed code rootkits and the like.
Instead of testing and auditing/assessing applications, I would take a different approach that is largely very technology-agnostic. My suggestion would be to implement an application security risk management portal that includes an app inventory along with each app's currently implemented application security controls. After an initial baseline, the application security controls should be evaluated against industry standards such as MITRE CWE, SAFEcode, and OWASP ASVS. A gap analysis (note that this is a standard risk management term and works best when implemented in an information security management program based on ISO 27001 or similar) can then be used to determine the optimal application security controls, as well as a path to get from the currently implemented controls to the required ones.
You should implement this risk management portal before performing risk assessment activity such as white-box or black-box testing in order to get better results, and to measure the success of your program.