Secure Code Review: Finding Your Application`s Vulnerabilities Before Someone Else Does

For those that aren’t entrenched in the world of application development it can be hard to understand why on one hand a code review is an integral part of any software development life cycle, but on the other - a secure code review isn’t always. People who aren’t on the front lines of coding and development just can’t understand that even though many vulnerabilities can be detected and fixed with a secure code review, and even though a security vulnerability being exploited by an attacker might cost an organization millions of dollars…wait.

Why isn’t a secure code review a part of every single software development life cycle? It’s mandatory in some industries, like healthcare, which is a good start, but when is it going to become standard practice across all industries? In the era of the terrible, horrible, no good very bad data breach, it definitely needs to be. Application security provider Checkmarx has a guide to the five best practices of a secure code review, and they’re summarized below.

1) Create a checklist

You can’t be expected to remember every step in your review process for every code review, especially if you need to complete a review as often as weekly or monthly. To ensure that you cover all of your bases every time, make a checklist of your process to help you review for all possible vulnerabilities. OWASP’s guidelines is a good place to start with your checklist.

2) Don’t play the blame game

A secure code review zeroes in on errors made in the development process, but it’s counterproductive to blame developers or call them out on mistakes. Developers are not naturally security experts and you can’t expect them to be. If an organization prioritizes security it creates an environment where software developers begin to learn the ins and outs of security, accumulating valuable knowledge with every secure code review.

3) Review, review again

You don’t need to do a security review for small additions, but every major addition should include a security review even if you think it isn’t quite necessary. It’s just best practice. Don’t forget regression testing too. You need to review new code that will be introduced into the environment, and you need to perform regression penetration to ensure the new code doesn’t introduce any security flaws in the application. One major flaw in security reviews is forgetting regression testing, because designers and security experts think that they only need to test current, new code.

4) Don’t fully rely on your robot overlords

Automated tools make it quicker and easier for developers and security experts to find issues. And that’s great. But you still need a basic human review to find tricky logic flaws that an automation tool will probably fail to find. The best way to perform a security audit on your software is to mix automation tools with human reviewers. It’s the best of both worlds. 

5) Stay vigilant

No matter how carefully you review, you can’t just throw your application code on a production server without monitoring it. You need to monitor your application to catch any malicious activity because it’s common during an attack for the attacker to throw errors on the application. You can monitor and track errors and any suspicious behavior through your own monitoring system or through a third-party tool, hopefully catching any issues before they turn into full-fledged problems.

For the (much) greater good

Code reviews should be more than just checking code. To protect your customers, your users and your brand you should be fully reviewing for security and logic flaws. After all, if you don’t find your application’s vulnerabilities, rest assured that someone else will.