Source Code Review

Motivation
Manual source code reviews can be decadent and luxurious. They’ll produce thick reports of sage advice, secure development recommendations, and the organization gets to stretch out their SDLC roadmap as far as they like. The code review process is a bit like the old joke of asking a fat guy what they want to eat at a buffet. Everything.

If web application scanning can be considered a key *part* of a well balanced breakfast, then manual source code reviews are like having a big piece of chocolate cake after a good dinner. Everybody loves them, but it’s vital to understand the drawbacks. Testing methodologies, pen-testing, static analysis, and architecture review all have a time and place, but when and in what moderation is the key.

The challenge for manual source code reviews are their high time/dollar requirements, lack of repeatability, and that the results are unlikely to surpass that of web application scanning. Meaning, it’s doubtful they’ll identify serious vulnerabilities a quality black box analysis won’t and that an attacker will likely exploit. This is not to say that code reviews are useless, instead they compliment other faster and more efficient ways of reducing risk in an overall web security program.

Some organizations prioritize activities based upon annual source code reviews when application code is updated monthly. Often this leads to focusing on areas of limited immediate benefit and false expectations of security improvement.

A reasonable strategy is to employ manual source code reviews after the basic blocking and tackling assessment work has eliminated the most commonly exploited vulnerabilities. A web security program that takes its lead from code reviews risks allocating resources towards activities resulting in poor website security improvement and questionable business ROI.