Static Application Security Test is useful for checking source code to find potential security vulnerabilities, but it isn’t Code Review.
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 1976, Michael E. Fagan published his Design and code inspections to reduce errors in program development paper, which describes how to do an inspection, creating the first code review process in 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.
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 identifies 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.
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 more people examine the source code of a computer program, either after implementation or during the development process.
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 are 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 unleashed.
- Pair Programming, a technique of Extreme Programming methodology, in which two programmers work together at one workstation. One writes the code and the other one reviews the line just typed. The two programmers switch roles frequently. Both developers must have 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, violations of development standards, and other problems. You must not be susceptible to doing it.
- Tool-Assisted, the most common method now. With tools, you can do analysis faster. But you need to know how to use them, and they’re sometimes 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.
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 Code Review Guide 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. They 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 result to determine if it is a real issue, if it is actually exploitable, and calculate the risk to the enterprise. Human reviewers are also necessary to fill in for the significant blind spots, which automated tools, simply cannot check.
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 studying and deciding the action to be taken, for example, to evaluate the pros and cons of the impact of a correction in the source code rather than a different configuration on the 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 a methodology and code review as a 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.
SAST is a methodology, while Code Review is a process.
Ok, I’m picky.