Secure Code Review

"If code has not been reviewed for security holes, the likelihood that the application has problems is virtually 100%." This is a shrewd message on the first pages of the OWASP Code Review Guide. An organization that does not put the code it uses and develops under review is irresponsible with its assets and those of its customers or users. Security problems in its products can be exploited by cybercriminals, leading to data breaches or disruption of operations and consequent fines and loss of clients and reputation. To help prevent all of this, it's prudent to match software development from the outset with a secure code review.

Secure code review (SCR) is the examination of an application's source code to identify security flaws or vulnerabilities. These appear in the software development lifecycle (SDLC) and must be closed or fixed to strengthen the security of the code. Secure code review can take place at any point in the SDLC, but within the DevSecOps culture, it is most valuable to use it from the early stages. This is a procedure that can be performed either manually or automatically.

The manual secure code review is conducted with great attention to detail. One or more security analysts scrutinize each line of code, understanding what they are evaluating, keeping in mind its use and context, the developer's intentions, and the business logic. On the other hand, the automated secure source code review is a process in which more code is examined in less time but in which the above factors are not considered. The tools work with a predefined set of rules, are restricted to certain types of vulnerabilities and suffer, some more than others, from the defect of reporting false positives (saying that something is a vulnerability when it is not). Among the most commonly used methods in secure code review are static application security testing (SAST) and software composition analysis (SCA). (Understand in this previous blog post how one differs from the other.)

The best option for achieving a robust secure code review is to take manual and automated reviews and merge them to leverage their particular capabilities. Automated secure code review tools, with their quick and "superficial" assessment of the attack surface, make it easier for security analysts to focus on identifying more complex and business-critical vulnerabilities. Experts, especially ethical hackers, who apply secure code review best practices, also considering the threat actors' perspective, can assess code to recognize the security issues that contribute most to the risk exposure of the target of evaluation. (For example, in our latest annual State of Attacks report, we shared that 67.4% of the total risk exposure in the assessed systems was reported by the manual method). This makes it possible for vulnerability remediation, an action that should always be connected to the code review, to follow a prioritization. Ultimately, the idea is to reduce the number of flaws that go into production as much as possible but continually repair the most dangerous first.

For the automated implementation of the previously mentioned methods commonly used in secure code review, i.e., SAST and SCA, there are corresponding tools available that quickly identify known security vulnerabilities.

Application security testing (AST) is a broader concept than secure code review. In fact, the latter is part of the former. AST, apart from SAST and SCA, involves assessment methods such as dynamic application security testing (DAST), manual penetration testing (MPT) and reverse engineering (RE). While SCR can be applied at any stage of software development, DAST and MPT, for instance, are generally employed when the application can run in order to evaluate its behavior through attack vectors.

A successful development team, committed to the security of its products, always has secure code review as a pillar. Any organization that develops software should have it among its constant practices, from the early stages of the SDLC, paying attention to the small changes that the members of its team gradually make to the code. Security in general and common weaknesses in software and their exploitation are not usually taught to developers in their academies and workplaces. And even the most experienced developers, due to factors such as burnout or carelessness, can make coding mistakes and end up generating vulnerabilities such as those listed in the OWASP Top 10 and CWE Top 25. For reasons such as these, source code should usually remain under review by security experts.

Why is secure code review important? SCR identifies the absence of safe coding practices, lack of appropriate security controls, and violation of compliance standards such as PCI DSS and HIPAA. Secure code review providers may find, for instance, missing or erroneous validation of inputs (verification that they comply with specific characteristics) coming from different sources that interact with the application (e.g., users, files, data feeds). They may discover that a developer made the mistake of leaving confidential information (e.g., tokens, credentials) inside the code, having forgotten to remove it after putting it there without reasonable justification. They may see that information that does need to be stored and transferred doesn't pass through proper encryption algorithms. Likewise, they may find that user authentication processes are pretty weak, requiring, for example, short passwords with little variety in their characters. And that authorization controls are poor and end up giving unnecessary access to any user without requesting permission.

An important issue often discovered within secure code review (with the help of, for example, the SCA method) is vulnerabilities within third-party and open-source software components. Application development today heavily depends on such components, which are imported from various sources and serve as support for what is intended to be built, which often turns out to have little originality. The dependency also exists between some components with others. So when using one of them, the developer may not be aware of the relation of this one with the others. Cybercriminals have among their desired targets these dependencies and components to look for vulnerabilities to exploit. This is such a frequent problem that, in fact, as we reported in State of Attacks 2022, the most common security issue among the evaluated systems was "Use of software with known vulnerabilities," and the requirement whose violation amounted to the highest total exposure was "Verify third-party components."

The experts and tools responsible for a secure code review will be in charge of verifying whether or not the developers of the software under evaluation have been employing secure coding practices. Though we have two blog posts that deal more extensively with secure coding practices (i.e., "Go Over and Practice Secure Coding" and "Secure Coding in Five Steps?"), which we invite you to read, here are some of those practices that should always be a point of reference for code development and review.

For more information on secure coding practices, you can also check OWASP recommendations for developers on their Code Review Guide.

At Fluid Attacks, we offer our secure code review solution as a comprehensive and accurate review of your software source code, combining manual (by our certified ethical hackers) and automatic procedures based on methods such as SAST and SCA. (In 2021, our automated SAST tool achieved a perfect score on the OWASP Benchmark v.1.2. and, in 2022, it was approved by the App Defense Alliance to validate tier 2 requirements of the Alliance's Cloud Application Security Assessment framework. It should also be noted that this is an open-source code review tool!) With us, you can apply secure code review from the earliest stages of your SDLC in a continuous manner. You can solve your security issues promptly (prioritizing those that represent the highest risk exposure) in favor of your development team's productivity and the security of your products.

Our SCR supports around 40 programming languages, including C, C#, C++, HTML, Java, JavaScript, PHP, Python, Ruby and Swift. We have among our review requirements those present in more than 60 international security standards, including CERT, CVE, CWE, HIPAA, NIST, OWASP and PCI DSS. And we adjust to specific requirements for your application and business logic, all constantly reviewed and updated. We integrate our CI agent into your CI/CD pipelines to break the build when there are policy violations and open vulnerabilities. And we report everything to you on our platform, where you can thoroughly understand and analyze your security issues, as well as receive recommendations and manage remediation processes. Additionally, your developers can have our IDE extension for VS Code at hand for faster recognition of affected lines of code. All this is part of our Continuous Hacking service, which also integrates security testing methods such as DAST, manual penetration testing and reverse engineering.

Do not hesitate to contact us if you want more information about our secure code review service and other solutions in our Continuous Hacking. Click here to try our Continuous Hacking Essential plan free for 21 days.