May 7, 15 1:42 am

Was this post helpful?

Simplified Application Security Code Review

May 7, 2015
| by:
Sherif Koussa

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:

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. 🙂

Was this post helpful?

About the Author

Sherif Koussa
Sherif Koussa is OWASP Ottawa Chapter Co-Leader, Software Developer, Hacker, and founder and CEO of Software Secured and Reshift. In addition to contributing to OWASP Ottawa for over 14 years, Sherif contributed to WebGoat, and OWASP Cheat Sheets. Sherif also helped the SANS and GIAC organizations launch their GSSP-Java and GSSP-NET exams and contributed to a few of their courses. After switching from the software development field to the security field, Sherif took on the mission of supporting developers shifting security left, and ship more secure code organically.
Share This Post

Leave a Reply

Your email address will not be published.

Related Post

Jan 23, 2023 by Shimon Brathwaite

The Security Liabilities of 3rd Party Libraries

Read more

Was this post helpful?

Jan 16, 2023 by Omkar Hiremath

Why WAFs Are Not Enough

Read more

Was this post helpful?

tech image with title of article
Aug 2, 2022 by Omkar Hiremath

How to Secure Serverless Applications

Read more

Was this post helpful?


301 Moodie Dr. Unit 108
Ottawa ON K2H 9C4

Designed by WP Expert
© 2023
Software Secured