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 month 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:
The following are the main aspects of a simplified security code review process:
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:
Which basically means using a static code analysis tool. The biggest disadvantage of using static code analysis tool is false positives but unless you are looking to read every line, you will need to leverage static code analysis tools.
Now choosing a static code analysis tool could be a little bit daunting. Here are a few resources to help you out:
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:
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. 🙂