Opinion: SAST tools have one advantage – they point the developer to the root cause of the problem. However, this is also a major disadvantage. They don’t teach the developer about the consequences. They don’t teach the developer how to avoid making mistakes. As a result, many developers create quick fixes and learn how to fool SAST instead of eliminating vulnerabilities.
It’s Not Enough Just to Find Root Causes
Recently, I came across a security report from one of the global DevSecOps platforms. This platform clearly prefers the use of SAST, which is understandable – they manage code, not the actual applications. What struck me immediately was the fact that there was no mention of vulnerabilities. The report focused on what’s wrong with the code, not on what can happen because there is something wrong with the code.
For example, the number one security issue, according to this report, is the lack of input validation. That’s no surprise at all to me. I know very well that most security vulnerabilities are caused by a lack of input validation. However, for me, the real problem is what can happen because of the lack of input validation or, more importantly, because of improper input validation.
You Need a Good Fix, Not Just an Easy Fix
At the same time that I read the report mentioned above, I was also proofreading an article written by another author. This article contained intentionally vulnerable code in PHP along with a fix. The vulnerable code in PHP was written using MySQLi and the SQL expressions were created using simple concatenation. It was a perfect, textbook example of an SQL injection.
However, the author of the article wanted a simple fix and just added filtering to MySQLi. I immediately felt that this is not the right approach and consulted with Acunetix security researchers. Turns out, I was right. Adding a filter makes it more difficult for an attacker to exploit this vulnerability but does not make exploitation impossible. The correct fix must be based on PDO and prepared statements.
Then, it struck me: what would happen if I tested this fix using a SAST? Based on what the report said, adding input validation should fix the problem. And I expect that most SAST tools would find the filter suitable, no longer report a problem, and thus teach the developer that this is an acceptable approach instead of the correct approach.
Not Knowing Consequences Leads to Bad Habits
The fundamental problem with SAST is that it does not teach at all about consequences. It takes the code, finds a potential root cause of a potential problem, does not even verify whether this is a real problem, points the developer to the line of code, and says “here, make this better”. The developer may be taught how to make it better but they don’t know what would happen if they did not make it better.
That’s why I’m a very strong advocate of DAST. Take Acunetix, for example, or even better, Acunetix with AcuSensor for PHP (an active IAST). If this code was scanned using Acunetix, the developer would not just be pointed to the line of code but, what’s more important, the developer would see how Acunetix exploited this code and, for example, acquired access to the entire database. And they would actually see data from that database in the Acunetix report!
Now, that is some powerful teaching. With a good DAST, the developer can see what their mistakes can lead to and how bad the consequences may be. That influences how they perceive the error. Just imagine the difference between someone saying “your car can be broken into” and the same person actually showing you a picture of themselves sitting behind the wheel of your car – what would make you more certain that you have a problem?
Also, note that a DAST does not care whether the developer added input validation or not. They could just as well just put a magic wand inside the code. All that the DAST cares about is whether it can exploit a vulnerability or not. Therefore, if the original report from the DevSecOps platform was developed using modern DAST tools, it would not just say that the lack of input validation is the problem. Instead, it would say that the vulnerabilities caused by bad input validation (or lack thereof) are the real problem.
That’s why I don’t believe in SAST as the primary method for securing applications in the SDLC. I believe it is a great tool to use along with a DAST. But I strongly believe that DAST should be the primary source of information for developers. No tool is a silver bullet, however, and that’s why I believe that a combination of DAST, SAST, and manual penetration testing is the only way to get your apps truly secure.
DOWNLOAD FEATURED E-BOOK
Including Web Application Security in an Agile SDLC
Download this e-book to learn how a medium-sized business managed to successfully include web security testing in their SDLC processes using a DAST solution.
DOWNLOAD FEATURED E-BOOK
Including Web Application Security in an Agile SDLC
THE AUTHOR
Principal Cybersecurity Writer
