I recently gave a workshop at OWASP Bay Area and presented a fresh slide deck. My main goal was to explain why people don’t like code review.
Here’s one of the slides:
It highlights how people typically perform code review (the tool-first approach):
This way of working can be very discouraging because you spend most of your time as a reviewer just triaging potential vulnerabilities. It’s also a sure way to avoid getting better at code review. You don’t really learn anything, you barely read the code, and you’ll never find any “unknown unknowns,” since you’re only looking for known patterns. Using this method also does little to increase your understanding of the codebase over multiple reviews—you basically start from scratch every single time. This is single-handedly the main reason why people hate code reviews.
On the other hand, the approach I advocate in my Security Code Review Training is closer to this (the reviewer-first approach):
It’s a slightly different approach: automation is there to help you be more efficient and to scale your efforts. You are in charge as the reviewer. You read the code, you learn, you understand the structure of the code, and you become a better reviewer. Afterward, you can scale up with automation and end up finding deeper, more significant vulnerabilities.
Of course, a quick SAST/grep and triage will always have a place in code review for catching low-hanging fruit or when you have very little time. But if possible, try to use an approach where you, the reviewer, direct the process.
Next time you start a security code review, before you jump on your favorite tool, try to spend a bit of time reading the actual code.