SAST Isn't Code Review

Static Application Security Test (SAST) is useful for checking your source code to find potential security vulnerabilities, it's also known as Code Review and no, it isn't Code Review in any way. But why?

Let's start with the Gartner IT Glossary definition of SAST:

Static application security testing (SAST) is a set of technologies designed to analyze application source code, byte code and binaries for coding and design conditions that are indicative of security vulnerabilities. SAST solutions analyze an application from the "inside out" in a nonrunning state.

I would like to emphasize the "is a set of technologies" sentence, because many people exclusively refer to the Secure Code Review with the term SAST. But Secure Code Review (or simply Code Review, because when we talk about it in the security field is obviously "Secure") is a process.

The Origins

In the 1976, Michael E. Fagan published his Design and code inspections to reduce errors in program development paper, where describes how to do an inspection, creating the first code review process in the history.

The Fagan inspection is a formal process which involves a careful and detailed execution with multiple participants and multiple phases. Also it defines entry and exit criteria (or requirements) to start and finish a process.

Fagan Inspection Simple Flow

Looking at these steps, we can think to the Systems Development Life Cycle (SDLC) originated in the 1960's, which probably influenced Fagan in the creation of his process. But... Who knows?

Moreover, in 1992, E. P. Doolan, in his article Experience with Fagan's inspection method, proposed the usage of software that keeps a database of detected errors and automatically scans program code for these common errors. The thought of using SAST tools was already lurking.

Anyway, by using inspections the number of errors in the final product can significantly decrease, creating a higher quality product. Exactly like the Code Review!

Code Review

As we have seen previously, the Fagan Inspection process is the base of the Code Review.

According to SmartBear:

Code Review is an integral process of software development that helps identify bugs and defects before the testing phase. Code review is often overlooked as an ongoing practice during the development phase, but countless studies show it's the most effective quality assurance strategy. Meetings end up taking more time than intentionally planned. Not having a set process in place means you don't actually know if your code reviews are effective or are even happening.

You can read a lot of code review tips and best practices by SmartBear here.

As Wikipedia says:

Code review (sometimes referred to as peer review) is a software quality assurance activity in which one or several humans check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation.

A Software Quality Assurance (SQA) consists of a means of monitoring the software engineering processes and methods used to ensure quality. Software quality assurance, according to ISO/IEC 15504 v.2.5 (SPICE), is a supporting process that has to provide the independent assurance in which all the work products, activities and processes comply with the predefined plans and ISO 15504.

We're always talking about processes. In these processes, there're different methods, approaches or tools that we can use.

For example, formal code reviews are the traditional method of review, in which software developers attend a series of meetings and review code line by line, usually using printed copies of the material. Formal inspections are extremely thorough and have been proven effective at finding defects in the code under review.

But things change with time, and code reviews have evolved. In addition to the Formal Inspection, today we can use several approaches to do a code review. Common approaches are:

• Regular Change-Based Code Review, a lightweight type of code review, where the scope of each review is based on the changes to the codebase performed in a ticket, user story, commit, or some other unit of work.
• The Email Thread, or Email Pass-Around, where the source code to review is sent to the appropriate colleagues via email and a thread of suggestions and differing opinions starts. Hell could be unleash.
• Pair Programming, a technique of the Extreme Programming methodology, in which two programmers work together at one workstation. One writes the code and the other one review the line just typed. The two programmers switch roles frequently. Both developers must have a good character, trust me.
• Over-the-Shoulder, an old lightweight method. Ask a qualified colleague to review your code together. Remember to trace and document everything especially if you don't have good memory.
• Walkthrough, in which a developer or a designer conducts a meeting with his developer team and other interested people who can ask questions and make comments about possible errors, violation of development standards, and other problems. You must not be susceptible to doing it.
• Tool-Assisted, the most common method by now. With tools you can do analysis faster. But you need to know how to use them, and in some cases they're expensive. Furthermore, let us not forget false positives and false negatives.

In practice, code reviews can take on numerous forms including lightweight code discussions or more involved processes such as pair programming, over the shoulder programming, and tool assisted practices. More advanced methodologies involve threat modeling, automated static code analysis, manual inspection, and formalized communication methodologies.

Says SoftwareSecure.

Anyway, whatever approach you want to use, we're talking about methodologies in a more complex process called Code Review.

The Secure Version

In the last decade, security paranoia has evolved, due to the increased attacks and their damage. Companies started to think about security in their development process, implementing it in all (or at least most) phases.

The code review was also influenced.

OWASP defines Secure Code Review as:

Manual security code review provides insight into the “real risk” associated with insecure code. This is the single most important value from a manual approach. A human reviewer can understand the context for certain coding practices, and make a serious risk estimate that accounts for both the likelihood of attack and the business impact of a breach.
[...]
Security code review is the process of auditing the source code for an application to verify that the proper security controls are present, that they work as intended, and that they have been invoked in all the right places.

And what about tools?

Tools can be used to perform this task but they always need human verification. Tools do not understand context, which is the keystone of security code review. Tools are good at assessing large amounts of code and pointing out possible issues, but a person needs to verify every single result to determine if it is a real issue, if it is actually exploitable, and calculate the risk to the enterprise.

According to OWASP, "the keystone of security code review" is the context, something that tools don't understand. In the code review process, the context is fundamental to study and decide the action to be taken, for example to evaluate pros and cons of the impact of a correction in the source code rather then a different configuration server side.

About tools, SoftwareSecure says:

Automated static code analysis tools are another essential component of the review process, offering near 100% code coverage and the ability to expose vulnerabilities invisible to others methodologies.

We're still talking about SAST as methodology and code review as process. Isn't it?

Conclusion

I don't want to question the use of SAST tools. I use different of them in my daily work and they are really useful. I simply wanted to make people in the industry understand the substantial difference between the two terms used, which are not interchangeable.

Code Review isn't simply about reviewing code. It's evaluating different situations, studying the outline and all the variables involved. It's integrating several methodologies to make all the code safe as a whole.

SAST is a methodology, Code Review is a process.

Ok, I'm picky.