Source code review is the process of identifying insecure patterns of code in an application or a software. It can be performed as a manual activity, through automated tools, or a combination of both.
First of all, you’re probably thinking, You REALLY want us to go over every single line of code?
With companies moving towards an agile SDLC process to build and deploy applications at rapid speeds, secure coding practices tend to get ignored or trivialised, mostly owing to a “functional first” approach. Penetration (pen) testing has continued to remain a popular approach in identifying security defects at run-time.
However, even if your pentesting gives you zero vulnerabilities, it does not mean that your application is free of flaws. In addition, dynamic testing does not pick certain types of flaws that secure code review can. This includes types of logic flaws, vulnerabilities such as configuration flaws, XXE vulnerabilities, command injection, buffer overflows, crypto flaws, logging flaws, raw SQL queries, dead/unused codes, race condition, improper error handling, and use of outdated / vulnerable libraries.
For example, developers tend to comment out aspects of code that could include encryption keys & tokens. In other cases, a developer might have logged parameters such as session token during his/her unit tests and then forgotten to remove it. A pen testing exercise obviously does not detect or identify such leaks. The only way to find this would be code is reviewed.
Another example is the buffer overflow flaw. A condition that exists when a program attempts to put more data in a buffer memory than it can hold. In this case, a buffer is a sequential section of memory allocated to contain anything from a character string to an array of integers. Writing outside the bounds of a block of allocated memory can corrupt data, crash the program, or cause the execution of malicious code.
The below code snippet shows that there is an excess amount of data to a smallBuffer parameter, which actual size is 10 bytes. An attacker could potentially exploit this by overloading the memory with large data, outside the bounds of smallBuffer parameter, and could crash the system. Dynamic testing will not easily pick this up, because the set parameters is considered as part of the source code design, unless explicitly defined otherwise.
void copyData(char *userId) {
char smallBuffer[10]; // size of 10
strcpy(smallBuffer, userId);
}
int main(int argc, char *argv[]) {
char *userId = "01234567890"; // Payload of 11
copyData (userId); // this shall cause a buffer overload
}
Code review is essential for your application security, when even the smallest flaw has potential for abuse.
Since we’ve now established the significance of code review, here is step-by-step guide on how to do it. Naa, just kidding! There are plenty of sources that will do a better job on the how-tos of code review. But…. what we’re going to do is shed light on how code review enhances your application security
1.Use code walkthrough to improve your security testing efficiencyCode walkthroughs for Rapid Code Review
The key factors of security testing in agile are Accuracy, Time, and Resource. Performing a full fledged code review is ideal. But hey.. ain’t nobody got time for that!. It is therefore imperative that teams adopt to open source / commercial SAST platforms. However not all SAST tools support varied (either new age, or age old) tech stacks. So, how does one perform a code review when you lack tools and time?
A solid option for you is what we like to call a Rapid Code Review (aka Table Top Code Review aka Code Walkthrough) which is essentially a sprint version of a full-fledged code review. In this approach, a developer walks the tester through the application source code, and narrows down the code to the key modules, functionalities, dependencies and core architecture visuals. For example, a shopping website may not need security testing done on pages that display product description, as much as it does for its login portal, items cart, or user management. Such an exercise gives context and enables the code reviewer to go through the key modules of the source code for testing. This can also be fed into SAST tools using custom scripts to give them context, thereby enhancing their scanning ability.
Rapid Code Review as an enhancement to Pen Testing
Normally, (external) pen testers do not have access to source code and are limited to the dynamic environment to conduct their security testing. However internal penetration testing teams have an added benefit. Unlike external consultants, internal security teams can perform a table top code review exercise along with the developers. With this additional context, security teams can supplement their DAST testing with better testing scenarios.
2.Integrate Code Review into your CI/CD pipeline
Code review is one of the fundamental and initial models of application security integration in a Continuous Integration/Continuous Delivery pipeline. Considering the need for speed in agile product engineering, teams can create triggers that run static code iterations on code prior to checking, thereby qualifying code that goes into a repository.Many SAST providers also provide plugins that can be plugged into IDEs enabling developers to perform cursory scans as and when they write new code. While this may not be as effective as running code across the entire code-base, it still gives an opportunity to catch bugs in the very early stages of development. In additions, DevOps teams can configure SAST platforms to either perform scans on nightly builds (using light weight time efficient policies) or detailed scans on weekly builds. Using automated code review in your CI/CD pipeline can dramatically detected vulnerabilities in your application, which is the core of DevSecOps’ “Shift Left Philosophy”.
3.Threat Modelling and Code ReviewA significant role of Code Review is finding the various threats that an application might face. Threat models used prior to building an application can be used to support this requirement.Threat model is essentially an exhaustive list of potential attacks ideated through various ways the functionalities can potentially be abused. This includes a full breakdown of processes, data stores, data flows, and trust boundaries.
Every functionality in an application has a business purpose to it and each of those functionalities can be abused one way or the other. A threat model presents the approach to look at the intended use of an application's functionality, and then theorize on all the different ways to abuse those functionalities. These ‘abuser stories’ are then used to create attack models.
These attack models provides a natural segue for a code reviewer to focus and prioritise critical workflows thereby increasing your efficiency of code review. A threat model is a critical piece of the DevSecOps puzzle and it is imperative that a code review process is both mapped and benefits iterative threat modelling.
