If you are going to engage independent code reviewers to analyze your code, here’re a few tips to get the best results from the exercise:
Explain the functions and features of the applications upfront - that helps the code reviewer prepare a meaningful threat profile. A good threat profile provides a solid foundation for a code review.
Give the code reviewer a walk through of the code on day-1: which are the major classes? Where are the critical operations performed? Where’re the calls to the database? etc
Provide a sample test setup of your application that the code reviewer can see. In theory, a code reviewer need only see the code and not the application. In practice, the quality of a code review improves dramatically when the code reviewer can see the application.
Ensure that the code you give the reviewer builds correctly. If your code base is very large, the reviewer might rely on code scanning tools. All the tools require that the code be build-ready. Your reviewer (and you) will lose a lot of time if the code base provided has unmet dependencies.
If you use exotic technologies in your application, it’s good to tell the reviewer upfront. She can research and be better prepared for the review. Remember that it’s unlikely that your reviewer would be familiar with every new technology or framework out there. Good reviewers have developed a system by which they can learn new areas fast, and find holes in them.
Let the code reviewer get at least an hour each day with your developers - that will help her understand the code better, and your developers feel greater ownership in the exercise.
If you have an audit to pass, inform your code reviewer: she will be able to give you daily updates that you can feed back to the dev team. The fixes can roll out faster that way. In some of our best code reviews, the developers fixed 80% of the holes by the last day of the review. We could mention that too in the report.