Jul 11, 2018
When it comes to conducting code reviews, no doubt your dev team are great at reviewing for functionality and performance. However, with new application security risks emerging all the time, it is vital that your dev team starts to make application security as much of a priority as functionality. Today I’m looking at five steps they can follow to conduct a code review that identifies security bugs and vulnerabilities.
1) Identify Code Review Objectives
Setting clear objectives will help to keep you focused during your code review, which will make it more effective at identifying bugs and vulnerabilities. Before starting your code review, it’s important that you understand the types of bugs that are possible in the code you’re reviewing, based on its architecture and threats you identified during threat modelling. If you already have an idea of what a bug will look like – for example, if there are patterns to help you identify bad code that can cause vulnerabilities in your application – then you have a better chance of finding it compared with if you just go in blind. It’s important that when you’re conducting a secure code review, you only look for security issues, and save checking for functionality and other problems for another review. The more things you are looking for during a code review, the less likely to are to spot any of them – you’re trying to think about too much at once!
2) Conduct a Static Analysis Scan
Using the right tools is vital to the success of your code review. A static analysis tool can be used to automatically check your code for compliance with a set of rules and best practices that you’ve predefined. So a static analysis scan is a fast and efficient way to find code defects and inconsistencies which can threaten the security of your application. For the first pass-over of your code during your review, you should run a scan with a static analysis tool to pick up on those simple mistakes. After this initial, automated step, you will move on to manually reviewing your code for more complex bugs and vulnerabilities.
3) Look for Common Bugs
For the next pass-over of your code, you should turn your attention to the most common security risks. The OWASP Top 10 is a list of the ten most critical, and most common, web application security risks, which also contains guidance on how to prevent or fix these common vulnerabilities. Referring to the OWASP Top 10 gives your developers a great starting point when looking for common bugs and vulnerabilities in your code. By adopting the guidance from the OWASP Top 10, your organisation can develop a simple, prioritised application security framework and ensure that the most common security bugs don’t make it into deployment.
4) Look for Bugs Specific to This Application
Your decisions about how to develop your application can introduce vulnerabilities that are language-, architecture- or platform-specific. As well as having an understanding of common vulnerabilities, it is also worth making sure that your developers are aware of language- or architecture-specific vulnerabilities, so that they check for these during their code review. Hopefully these potential threats would have been identified during threat modelling, and your dev team have already mitigated these risks during the development process, but it’s always worth a final check!
5) Post-Review Activities: Prioritise/Fix/Learn
Once you’ve completed your code review, the next step is to prioritise the vulnerabilities in order of severity, to ensure that the most serious vulnerabilities get fixed before less serious ones. You can then fix the bugs you’ve identified, and your dev team can learn from those mistakes. How were these bugs found, and how were they fixed? This knowledge will help to improve the code they write in the future.