Sherif Koussa (@Skoussa) who is a Principal Application Security Consultant at Software Secured presented this talk about source code reviews and proposed a methodology for going about it. Companies tend to take the “happens to someone else, never to us” attitude. There can also be “accidental security” in the form of inputs that happen to be filtered against, for example, SQL injection by being converted into integer. Security has to be more proactive and deliberate than that. The methodology goes like this: enumerate the inputs, autoscan for Low Hanging Fruit, manual review, weed out false positives, communicate to developers. Note the combination of automatic and manual assessment for maximum coverage.
The notion of a “trust boundary” was also discussed. This is something I have contemplated extensively in architecting software, not just security related but also in handling bad input that can crash the software. One implicitly or explicitly draws a trust boundary, that is, a boundary behind which you do not bother checking inputs and trust the code outside the boundary to do so. Because it is simply not feasible to wrap every line of code in a validating if statement… if for no other reason, you have to wrap the ifs in ifs, and those ifs in ifs, etc. until you stackfault the universe.
Koussa wrapped up by calling for the need to report the findings to the developers with articulate reasons why it is vulnerable, business impact, and how to remediate. It is difficult to argue with this of course but I also know why it is necessary to say it, though it may seem obvious. Alot of reports are information glut that, if it presents the information this speaker was calling for at all, makes it a needle in the haystack of the glut.