Do you know the difference between Secure Code Review e SAST as well as when to use them?
This topic was split into two parts, in the first article, we have spoken about automated tools, explaining what is the right moment and what is the best way to put them into practice.
Now, in this second article, the approach is on the tools related to the Secure Code Review from the Owasp Code Review Guide perspective.
What OWASP Code Review Guide says
This document can be a great ally on development teams wishing to better understand the importance of such a document.
The first statement is:
“Secure code review is probably the single-most effective technique for identifying security bugs early in the system development life cycle. When used together with automated and manual penetration testing, code review can significantly increase the cost-effectiveness of an application security verification effort.”
As we can see, there is no orientation on the sense of excluding all the other manual tests. The point is, automated tests must be part of a set of tests.
The second statement is:
“Manual secure code review provides insight into the “real risk” associated with insecure code… A human reviewer can understand the relevance of a bug or vulnerability in code. Context requires a human understanding of what is being assessed.”
Based on these two affirmations, we are going to talk about Secure Code Review next.
What is Secure Code Review?
When we talk about Secure Code Review, we need to keep in mind that this is a process for the purpose of validating an application code, that is, code review will look for flaws in that code.
A code validation, therefore, seeks to understand whether all security controls are properly embedded in the application, making it secure even when there are attacks.
Therefore, conducting a Secure Code Review is to ensure that the application is designed to be protected in a particular environment.
Also, when we conduct a code review, we also ensure that developers are following safe development best practices.
Overall, and in a perfect environment, after conducting a code review, a subsequent intrusion test should not find any vulnerabilities in this application.
As we have said, we do not mean to harass the use of tools: in fact, we believe that code review can achieve great results and gain scalability through the combination of human effort and automation.
That’s because the tools used to perform these tests will always need human intervention.
In addition, it will always be necessary for a code review to be performed by an expert, as he or she will be able to evaluate gaps where tools cannot reach considering the context.
When to use Secure Code Review?
As using SAST tools, manual code analysis also has its timing, cost, advantages and limitations.
Therefore, we can assert that a manual code review should also be planned and performed at an appropriate time in the process.
Manual code reviews, for example, are perfect for determining errors in business logic, as well as understanding the developer’s intentions when building software.
Automated tools, on the other hand, do not work that well. This is because this type of analysis, in isolation, ends up generating numerous false positives. Or even worse: it can generate many false negatives – as we have already commented.
Manually Coding Review
Evaluations of authentication, authorization, encryption processes and above all, data validation processes are best evaluated by manual code reviews.
Manually reviews are also indicated for examining rarely traveled code snippets.
Evaluation techniques, such as intrusion testing or “diffusion only” for example, examine snippets of code for which inputs are provided. However, less triggered, or intentionally hidden, sections may be lost.
That’s because automated static analysis tools can follow these snippets, but they can hardly understand the business logic associated with them.
A rigorous manual review can often unravel and examine these passages that would otherwise be lost or misunderstood by automated tools.
Therefore, if we realize that we need to use the best tools for the end result, we realize that both automated and manual reviews have their place.
This means that there is really no elimination of either option within the process: each of these techniques has security benefits for an application. What we need, then, is to put each one in their prominent place.
Allocating small amounts of time within the development process for manual review, while providing more security, will provide better process scalability as there will be less code to validate.
Similarly, positioning automatic code validation tools can help develop a process with lower human error incidence and reduce the time required for code validation.
Once again, there are no magic solutions when it comes to application security. After all, it goes beyond a process: application security implies a cultural change.
The limits of Code Validation
There are times when human interference can do more harm than good.
When we talk about failures like buffer overflow, there are parts of uninitiated codes (so-called dead codes) or even subtle errors that are difficult for humans to identify. And this is where the tool shows its value.
In addition, during manual reviews, many vulnerabilities may go unnoticed, such as integrating small isolated errors spread over large amounts of code, for example.
So once again you have to admit that in cases like these the tool is one of the best options.
Cost is another limitation of manual code review teams. Testing professionals need to be constantly trained and available for code reviews. This can generate a cost that not all companies are willing to cover.
As for time, in addition to development experience, it usually takes more than a year for a professional to gain the experience needed to perform code reviews securely.
It is clear that there are limitations to the use of manual reviews, as well as limitations on the exclusive use of tools. The combination of the two models seems to us to be the best solution.
Identifying the limitations in your process and the right team is a big step towards building a better solution.
Similarly, realizing that using tools alone is not the best solution when you want to ensure code security.
Before Secure Code Review
We often find code development and review teams that do not exchange information about the approach that was used to build the code.
Therefore, this is the first step in making a good code review.
1. Understand the developers’ approach
When planning for code review, talk to developers and understand which approach and mechanisms were used for, for example, data validation, authentication or even authorization.
This kind of understanding can help reduce the time spent on code review, making the review much more effective.
2. Use different techniques
Another good approach is not to limit yourself to using a single review technique.
Whenever possible, use manual and automated review techniques, understanding that each method has its advantages and can bring considerable gains to the review.
3. Stick to the facts
When we talk about analyzing vulnerabilities, it is better to sin for excess.
During the code review process, it is not appropriate to judge the acceptable risk arising from the identified vulnerability. Therefore, the review team should report what they found: leave this risk assessment to the customer.
4. Try to understand the general idea
It is normal for developers to seek understanding of every detail of the evaluated line: resist it and seek to understand the whole.
Instead of understanding the detail of each line, try to understand the code as a whole and what it is doing. Once you understand the whole look for important areas to review such as authentication, authorization, database connection.
5. Follow up the review points
Always keep in mind the exchange of information with other team members who perform the reviews. After all, this exchange of experience helps improve these reviews.
Communication can also help in understanding the vulnerabilities identified, how they relate, and how this can influence overall code security.
6. Keep focused on code review
Often, code review work may shift focus to other vulnerabilities that are not connected to code. But we need to focus: after all, code review is not an intrusion test.
Finally, it is important to make it clear that this list is not a finite list of practices to perform prior to reviews, but following these points will certainly help improve your process and results.
Seek to assemble and understand your code review process.
What was learned?
Here at Conviso we have already performed hundreds of code reviews on clients. It is impossible to estimate this in lines of code.
From this experience, we have learned to identify a few hundred vulnerabilities in over 10 years in the market.
For us, the benefits achieved when we can identify and help remediate these vulnerabilities are evident, thus minimizing the risk of application compromise.
We also understand that this is not always an easy move, after all, not even having a team of experienced and effective reviewers ensures 100% security for your code.
Therefore, it is important to understand that code review is a process, and as such is made up of resources, tasks, and people, each with their importance on a whole.
We have seen that a good code review program includes a variety of tools and methods.
Manual review, for example, may find flaws that no other technique can identify.
In the long run, when manual code review is combined with intrusion testing, automated analysis, and developer training, we can identify a significant improvement in an application’s review process.
We hope that these two articles have helped bring new insight into your code validation process, helping to keep your applications increasingly secure.
See you next time!
