Obviously it is not 2005 anymore. 10 years ago most organizations were OK with perimeter security and a vulnerability scanner. This shift started to happen in the U.S from perimeter security to application security about 4-6 years ago depending on the industry, I know some industry verticals have not moved yet but most did. In Canada, this shift started to happen about 12-18 months ago. A lot of our clients come back to us asking how they can implement a security code review process internally so that we can catch the obvious vulnerabilities before going to production.

Here are the things that security code review does best:

• Systematic approach to uncover security flaws.
• Close to 100% code coverage.
• Better at finding design flaws.
• Find all instances of a certain vulnerability.
• The only way to find certain types of vulnerabilities.

The following are the main aspects of a simplified security code review process:

1 - Anchor:

You have to exercise regularly in order to take advantage of the full benefits of exercise. Similarly, code review must be anchored on a routine task and one of the best approaches to cement security code review into your SDLC is to anchor it on the nightly build, it could also be anchored on a different SDLC phase. The diagram below shows different security code review touch-points, which could be added to your SDLC. Each touch-point has pros and cons:

• At the development phase: you catch problems early on, the work is distributed evenly among the team members and improvements are fed into the lifecycle early on, which saves development cycles. The drawback is that it is a little bit tedious and requires a tremendous amount of commitment and discipline from the development team.
• At the testing phase: vulnerabilities can still be caught early on, and still could be distributed evenly among team members. However, it is not as cost saving as when it is done in the development phase. It could also be a little disturbing to the quality assurance efforts.
• At the deployment phase: now catching vulnerabilities becomes a little bit more costly to the development team since this is so close to deployment. The only good thing is that it could be a big push by the team; most teams bring in external help at this point.

2 - Automation:

Which basically means using a static code analysis testing (SAST) tool. The biggest disadvantage of using SAST products is false positives but unless you are looking to read every line, you will need to leverage them.

Now, choosing a SAST tool can be a little bit daunting. Here are a few resources to help you out:

• Static Analysis Technologies Evaluation Criteria
• NIST Source Code Security Analysis Analyzer Functional Specifications Version 1.1

3 - Manual Review:

Tools are not very good at understanding logic, and consequently finding logic problems. Tools are also not very good at finding problems with certain functionalities such as authorization bypass or parameter tampering. That's why you will need to get your hands dirty from time to time. The following are usually the areas that require manual review:

• Authentication & Authorization Modules
• File Upload/Download Modules
• Encryption Modules
• Security Controls and Input Filters
• Business Logic

4 - Reporting:

You need a way to circle the security bugs found into the software development stream of bugs. The key is to figure out a proper priority scheme, not all security bugs are "critical." The other key point is to include enough information in the bug to make it as easy as possible for the developer to fix it.

These are the simple steps to kick off your internal security code review. The key while starting out is to start simple, if you can just review your code for SQL Injection only, that's great! Once this is taken care of, move on to the next one and so on.

Security code review could be as simple or complex as you make it, keep in mind that complex does not necessarily mean better. So keep it simple. 🙂