What is code review?
A secure code review is a specialized task involving manual and/or automated review of an application’s source code in an attempt to identify security-related weaknesses (flaws) in the code. A secure code review does not attempt to identify every issue in the code, but instead looks to provide insight into what types of problems exist and to help the developers of the application understand what classes of issues are present. The goal is to arm the developers with information to help them make the application’s source code more sound and secure.
Code Review Elements
- Broken Authentication / Broken Access Control
- Database communication security
- Data encryption
- Data protection
- Error handling
- File management
- Hardcoded credentials
- Input validation
- Language-specific issues (e.g., type juggling in PHP)
- Memory management
- Output sanitization
- Security through obscurity
- Transport Layer Security
That’s quite a list. Of course, you won’t be able to tackle all of these without spending weeks or more. So we need to narrow down the list and focus only on the most important vulnerabilities and the ones that are best to be caught using secure code reviews. Keep in mind that this stage is not meant to necessarily find every security flaw in an application, but to offer developers insights into what classes of vulnerabilities exist. Fortunately, some of the security best practices from above are more important and effective than others. So, we can shrink that list to five items based on the severity and the number of flaws that each best practice prevents:
- Broken Authentication / Broken Access Control
- Database communication security
- Data encryption
- Input validation
- Output sanitization
What’s the history of secure code review?
In its first iterations, code review involved lengthy, time-consuming formal reviews. As development speeds increased, this longer review evolved into a more dynamic and lightweight process that keeps pace with agile and modern development methodologies.
Today, there are review tools available that easily integrate into SCM/IDEs. Tools like static application security testing (SAST) provide inputs in addition to manual reviews, helping developers find and fix vulnerabilities. These tools are compatible with numerous development environments like GitHub and GitLab, or IDEs like Eclipse and IntelliJ, so developers can work in their preferred environment.
How does the code review process work?
Code review—manual, automated, or a mixture of the two—can be initiated via an automated notification or by a human. Current best practices for performing robust and secure code review involve using manual and automated reviews together. This tandem approach catches the most potential issues.
Secure code review can occur at any time during the software development life cycle (SDLC), but it’s most impactful when performed earlier, because that’s when it’s easiest and fastest to make fixes to the code. In particular, using automated code review when developers are actually writing code allows for immediate changes as needed. Manual code review is very helpful when performed during the commit phase, or when a merge request is submitted to the repository. It also is a way to review code while taking into account business logic and developer intentions.
Automated review
Automated review enables large codebases to be quickly and efficiently analyzed. Developers perform this review using either open source or commercial tools while they are coding, to help find vulnerabilities in real time. The most advanced development teams also include SAST tools, which can provide additional inputs, help find vulnerabilities, and enable developers to fix them before the code is checked in. The most successful development processes also involve developers performing their own self-reviews as they code.
Manual review
Manual review involves a thorough review of the entire codebase by a senior or more experienced developer. This process can be extremely tedious and time-consuming, but it identifies flaws, such as business logic problems, that automated tools may miss. Layering in QA tests can help as well, but there are still scenarios that manual testing can miss. The best practice is a combination of automated and manual review.
Combining manual review with feedback from tools like SAST improves the overall security of the code being committed, and helps reduce the number of flaws that slip into production.
Manual vs. Automated Secure Code Reviews
When it comes time to choosing the tools and processes you’ll use to conduct a secure code review, you may stumble upon the question of which tools to use and whether you should use automated tools or human inspection. Which is better? As with other areas of your SDLC, the best approach is a mixed approach, combining both manual review as well as inspection using strong static code analysis tools. Here are the pros and cons of the two methods of review:
Automated Code Review Pros:
- Detects low-hanging fruits and hundreds of other vulnerabilities, including SQL injection and Cross-Site Scripting
- Ability to test quickly and in large chunks of code is crucial in agile and continuous integration environments
- Ability to be scheduled and run on-demand
- Ability to add non-security checks including business logic
- Ability to scale automated testing as per organizational need
- Depending on tool choice, an automated source code review tool can be customized per organizational needs, especially certain compliance standards and for high-value applications
- Can help raise developer security awareness and offer a way to better educate developers who use the tool
Automated Code Review Cons:
- Tools that don’t allow fine-tuning and customization can produce false positives and negatives
- Coverage and breadth are really dependent on the type of tool you choose and the languages, frameworks and standards it covers
- Comes with a learning curve for those not familiar with static code checkers
- Not viable for all budgets, though there are strong open source tools for common languages
Manual Code Review Pros:
- Ability to deep dive into the code paths to check for logical errors and flaws in the design and architecture most automated tools couldn’t find
- Security issues like authorization, authentication and data validation can be better detected manually compared to some automated tools
- There’s always room for an extra set of (expertly trained) eyes on high-value applications
- Reviewing other people’s code can be a great way to share secure coding and AppSec knowledge
Manual Code Review Cons:
- Requires an expert of both the language and frameworks used in the app as well as needing a deep understanding of security
- Different reviewers will produce different reports, resulting in inconsistent findings between reviewers – though peer reviews can be a fix
- Testing and writing up reports is timely, and often requires developers to participate in sometimes lengthy interview sessions to offer context to the reviewer, costing developer time and resources
- Manual review of applications with more than 10-15k LoC is limited to targeting high risk functions only
Applications have thousands to hundreds of thousands of lines of code, and the cycles we’re running to release new apps and versions are getting shorter all the time. Still, we can’t review code any faster than we did ten to fifteen years ago. On the other hand, no tool or human is perfect.
And, as Wikipedia’s entry on Application Security says so well, “The human brain is suited more for filtering, interrupting and reporting the outputs of automated source code analysis tools available commercially versus trying to trace every possible path through a compiled code base to find the root cause level vulnerabilities.” In many ways, manual and automated source code reviews complement each other well, each covering the areas where the other is typically weak.
As your application security program matures, you’ll find that both manual and automated code reviews should have a place in it. Thus, if your budget allows for both the cost of a tool and the cost to house either an in-house reviewer or outsource it, it’s best to have a mix of both automated and manual reviews in your normal security activities.
When to Perform a Secure Code Review?
Security should be a focus throughout the entire development life cycle. Creating threat models during the design phase, educating developers on secure coding practices, and performing frequent peer reviews of code with security personnel involved will all help increase the overall quality of the code and reduce the number of issues reported (and hence that need to be fixed) by the secure code review.
However, a secure code review is best used toward the end of the source code development, when most or all functionality has been implemented. The reason for waiting until late in the development phase is that a secure code review is expensive and time consuming. Performing it once toward the end of the development process helps mitigate cost.
The Basic Secure Coding Practices
One of the goals of regular code review is to spot missing best practices. Security code review is about identifying the missing secure coding practices. These practices are also known as software defences or in Threat Modeling terms countermeasures. There are many types of software defences but some are more important and effective than others.
Defences and Prevention
The short list below is based on the number of security flaws that each defence prevents as well as the severity of the flaws based on OWASP Top 10 and MITRE Top 25 industry classifications.
- Input Validation, prevents a wide range of attacks such as Injection, Cross-Site Scripting and Path Manipulation.
- Parameterized Statements, prevent Injection attacks when Input Validation cannot be employed. Injection is #1 in the OWASP Top 10.
- Memory Safe Functions and Safe Memory Management practices prevent memory flaws such as Buffer Overflow which is at #3 in the Mitre Top 25 immediately after SQL Injection and OS Command Injection.
- Data Encryption in transit and at rest prevents data breaches which are covered at #3 in the OWASP Top 10 category Sensitive Data Exposure.
- Neutralizing Output prevents Cross-Site Scripting flaws which plague web applications and should be the primary concern for front-end developers.
- Indirect Object References prevent dangerous flaws associated with file management such as Path Traversal a vulnerability in the Broken Access Control OWASP Top 10 category.
There are many threat categories and best practices that will not be discussed in this series. It is important to realize security code review is not a replacement for other application security controls such as static analysis or penetration testing.
Threat Categories
In addition many threat categories are handled in the application framework as opposed to every day code changes. For example, #2 in OWASP Top 10 is Broken Authentication. It is not likely that you will deal with this category often during code review because authentication is usually handled by the framework.
The articles will contain examples from Java, C/C++ and JavaScript programming languages. However the concepts can be easily transferred to other languages. Input Validation in Java is similar to input validation in Python and PHP.
In next article in this series we will review in detail the concept of Input Validation.
Tips to a Code Review:
1.Code Review Checklists
Produce code review checklists to ensure consistency between reviews and by different developers
When conducting manual code reviews, make sure all reviewers are working by the same comprehensive checklist. Just as the developers writing the code are human and can neglect secure coding practices, reviewers can forget to certain checks, if not working with a well-designed checklist.
In addition, enforce time constraints as well as mandatory breaks for manual code reviewers. Remember, just like as we all fade after writing emails or even reading for hours on end, reviewers will fatigue. It’s important to ensure the reviewers are at their sharpest, especially when looking at high value applications. At the same time, dedicating a specific amount of time to source code reviews will also keep reviewers motivated to finish in an appropriate amount of time.
2. A Positive Security Culture
Ensure a positive security culture by not singling out developers
It can be easy, especially with reporting by some tools being able to compare results over time, to point the finger at developers who routinely make the same mistakes. It’s important when building a security culture to refrain from playing the blame game with developers; this only serves to deepen the gap between security and development. Use your findings to help guide your security education and awareness program, using those common mistakes as a jumping off point and relevant examples developers should be looking out for.
Again, developers aren’t going to improve in security if they feel someone’s watching over their shoulder, ready to jump at every mistake made. Facilitate their security awareness in more positive ways and your relationship with the development team, but more importantly the organization in general, will reap the benefits.
3. Review code Timing
Review code each time a meaningful change in the code has been introduced
If you have a secure SDLC in place, you understand the value of testing code on a regular basis. Secure code reviews don’t have to wait until just before release. For major applications, we suggest performing manual code reviews when new changes are introduced, saving time and human brainpower by having the app reviewed in chunks.
A mix of human review and tool use
A mix of human review and tool use is best to detect all flaws
Tools aren’t (yet) armed with the mind of a human, and therefore can’t detect issues in the logic of code and are hard-pressed to correctly estimate the risk to the organization if such a flaw is left unfixed in a piece of code. Thus, as we discussed above, a mix of static analysis testing and manual review is the best combination to avoid missing blind spots in the code. Use your teams’ expertise to review more complicated code and valuable areas of the application and rely on automated tools to cover the rest.
5. Continuously monitor and track
Continuously monitor and track patterns of insecure code
By tracking repetitive issues you see between reports and applications, you can help inform future reviews by modifying your secure code review checklist, as well as your AppSec awareness training. Monitoring your code offers great insight into the patterns that could be the cause of certain flaws, and will help you when you’re updating your review guide.
Find Us immediately for the Security Assessment in Hong Kong, United Kingdom, Europe, Estonia, Singapore...
Facebook:
https://www.facebook.com/ITSec-Security-Consulting-237738580247975
Google:
https://itsecsecurityconsulting.business.site/?m=true
Case Reference: