Secure Code Review Best Practices [cheat sheet included]

Code review is an important part of the development process that can help to identify issues with the quality of the software.?Secure?code reviews are a specific type of code review that is specifically evaluating the security of the software’s source code. Activities that don’t include the source code (like DAST tools and pentests) are not considered “secure code review.”

> Download the cheat sheet

Some of the steps in a secure code review can be assisted by automated tools, but many need a human for critical thinking and understanding of real-world processes. In this post, we will explore the different things you should do during a secure code review, point out which of those things can be automated, then summarize everything into a cheat sheet for you to reference when performing your own secure code reviews!

Automated secure code review

First, we’ll look at the parts of a secure code review that can be automated. Modern code security tools allow you to quickly find the low-hanging fruit and focus on higher-level security issues. By utilizing automated tools, you can be sure that part of your process is consistent and quick.

SAST tools

Static Application Security Testing (SAST) tools analyze source code through various automated methodologies to find some classes of vulnerabilities. SAST tools are good at discovering whether your code is vulnerable to things like injection attacks, buffer overflows, and misconfigurations. Another advantage of SAST tools is that they can often run right in your IDE, giving you instant feedback as you write the code. Some SAST tools can also scan configuration files for your infrastructure-as-code, which is a big topic by itself.

Some examples of popular SAST tools include:

• SonarQube
• Veracode
• Snyk Code
• Synopsys

Secret scanning

We are passionate about detecting secrets in code, which is another part of secure code review that can be automated. GitGuardian’s platform provides real-time detection of secrets when they are exposed in your code, and because of that, we are the number one security app on the GitHub marketplace!

Like other SAST tools, secret scanning software can also be integrated into earlier parts of the development process to catch secrets before they even enter the git history. GitGuardian provides an open-source tool called ggshield that you can configure to run as a pre-commit hook. More details on how to set that up can be found here.

SCA

A really tricky part of secure code review that automated tools make easy is Software Composition Analysis (SCA). SCA tools look at the third-party components you are using in your code and let you know if any of them have a known vulnerability. If you had to track every version of every dependency in your code, it would take a lot of time. Not to mention having to review everything periodically as new vulnerabilities come out all the time. SCA tools make this type of secure code review a snap and let you focus on other things.

Some popular SCA tools include:

• GitHub Dependabot
• Snyk Open Source
• Synopsys Black Duck

Manual secure code review

Now that we’ve gone through some tools that can quickly enhance your secure code review, we will cover security issues that are harder to look for programmatically. In order to review for these security issues, you’ll need the eyes of a developer who understands the intricacies of each issue.

Maintainability and complexity

This is one of the parts of secure code review that overlaps with regular code review. When code is overly complex and difficult to maintain long-term, it can create all sorts of problems. When your code is hard to understand, you are more likely to let bugs and potential vulnerabilities slip through into production. To make matters worse, when bugs or vulnerabilities do slip through, it can take longer to remediate them. As a code reviewer, you should be looking out for complex code and make suggestions to simplify when you identify some.

New dependencies

We already covered how to watch for vulnerabilities in your existing dependencies, but it’s also a good idea to do some critical thinking when adding a new dependency to your code. If you are going to be depending on a package long-term, there are a few key areas you should consider:

• Popularity: the more popular a package is, the more likely it will be to have people investing in its upkeep.
• Security: if the package has a history of vulnerabilities and poor coding practices, it might indicate that it isn’t safe to use in your software.
• Maintenance: you should make sure that the package is actively maintained and has a good track record of fixing bugs.

Business logic flaws

While SAST tools are good at detecting some types of vulnerabilities, like injection attacks, they aren’t very good at detecting business logic flaws. These kinds of vulnerabilities have less to do with the type of input and more to do with the meaning of the input. These types of vulnerabilities may appear to be functioning as intended but can be exploited by attackers to create unexpected behavior. Business logic flaws vary widely depending on the purpose of your software, which is why you need a human who understands the data and processes involved. You can read more about business logic flaws and look at examples here.

Proper use of encryption

Encryption is a vital part of applications, and it takes the knowledge of a human reviewer to evaluate the usage of encryption (or lack thereof). As a reviewer, you should give particular scrutiny to parts of your code that are saving data to a database or file or sending and receiving data over the network. Data flow diagrams can also be helpful when evaluating the usage of encryption.

Error handling

Error handling may not be the first thing that comes to mind when you think about application security, but it can be an issue at times. When software fails, it usually generates some sort of message for the user, but this message varies in detail from obscure to revealing. When an error message is too revealing, it may disclose detailed information about how your software works which can assist a malicious hacker in finding ways to exploit it. It’s generally best to keep user-facing error messages simple, and to keep more detailed information behind the scenes for developers’ eyes only. As a reviewer, you should make sure that your error messages aren’t too revealing, and that your applications handle errors in all the places that they should be.

Conclusion

We covered a lot of different things to look for when performing a secure code review. Reducing vulnerabilities in your software starts with the code, which means secure code reviews are a critical part of the software development process. While some of your time and effort can be reduced by using automated tools, you should still keep your cheat sheet handy and evaluate all of these areas when reviewing code.