Code reviews are hard to do well. Particularly when you’re not entirely sure about the errors you should be looking for! The DevSecOps approach pushes security testing left so that vulnerabilities can be found and fixed earlier, in the design, development, or CI/CD stages of the workflow. It’s always a good idea to check for security issues in code that you review. In case you don’t know what to look for, check out this series to give you pointers for your next code reviews!
A static code analysis tool or linter is a very powerful tool for developers. By statically looking at the code you and your team wrote, you can point out a number of things like programming errors, bugs, stylistic errors, and suspicious constructs. With this bug and error detection, a linter can, in many cases, also indicate if a security-related bug slipped into your source code. Depending on the static tool you use and the ecosystem you are operating in, a static code analyzer can point out issues like SQL injections and code vulnerabilities.
Linters can be very useful but will produce a lot of false positives. Since all linters are rule-based and not looking at the full context of your code, there will be a bunch of cases where a linter will flag your code as a bug or a security issue while this is not the case. Nevertheless, if you fine-tune the ruleset, a linter can prevent nasty mistakes. Although these tools can be used in a lot of different forms — for, example, manually with a command-line instruction or as part of an IDE — the best way is to automate these processes as much as possible. For instance, as part of your build process, or maybe when a new pull request is submitted to your repository.
Either way, automation is key. Well-known static code analyzers you can use are SonarSource (with a free and open source tier) and Veracode. However, depending on your context, you might need a more specific one. Check this list of static code analyses tools for both language-specific and multi-language solutions that may fit your needs. If you don’t have automatic static code analyzer in place, you can either use it during your manual code review or, even better, automate it in your process so people can catch obvious problems even sooner.
Check the complete Secure code review cheat sheet