Save time with unbiased, independent feedback on vendor solutions.
Watch weekly bite-sized webinars hosted by IANS Faculty.
First-generation SAST tools require large investments in time and resources, but when they’re placed in the right hands, they tend to catch most issues. Second-gen SAST is cheaper, quicker, and easier to use, but it can miss some vulnerabilities. This piece explains the main differences between first- and second-gen SAST tools and helps you determine which will work best for your environment.
First-gen SAST tools perform “symbolic execution,” which means they run through every single possible outcome of your code and report every possible instance of weakness—a process that results in an extremely high percentage of false positives. Unfortunately, the task of validating the results usually falls to the application security team, which is generally already overburdened with their regular work.
As a result, SAST tools are a big commitment for any organization. Not only are they expensive to purchase, but they require hiring a security expert to verify the results.
This leads some security organizations to try to push this work onto the development teams, a tactic that seldom works. Software developers have their own workload, and most don't have the security expertise required to validate SAST results quickly and accurately. In many cases, software developers have been known to mark findings as unexploitable or false positives just to get out of having to do the complicated and thankless work of validation.
Consequently, first-gen SAST is not adopted as often as it could or should be. If you have an expert wielding a first-gen SAST tool, it can be very powerful, but there just aren't enough application security experts to go around.
Another issue with first-gen SAST tools is they are quite time-consuming to run. They often run for hours, rather than minutes, and few developers are willing to wait around to receive the results—especially when they need to move fast and the results are generally inaccurate.
READ: Secure Coding Basics for Developers
Second-generation SAST tools tried to fix first-gen tool issues through a combination of flow analysis and pattern matching.
“Flow analysis” means tracking the input to the application and then checking where that same input is used by your program. Any data we receive from a user, an API, a database or anywhere else is potentially malicious. Flow analysis ensures all inputs have been properly validated before they are used in a decision-making process, saved, output to the screen, or used in any other potentially damaging way.
These points are also sometimes called “sinks” and “sources.” A source is where we get the input from the user, and a sink is where we use that input. The SAST tool looks for any source that is not validated properly and checks to ensure it is not malicious before it is “sunk,” i.e., used by the application.
If we can ensure every single input to an application has been properly validated before it is used in any way, we can avoid numerous vulnerabilities, such as cross-site scripting, SQL injection, and more. This process is less prone to false positives than a first-gen SAST tool, but it can still miss potential vulnerabilities from time to time.
Second-generation SAST tools also search for patterns known to be vulnerable, aka “anti-patterns.” Their ability to search for patterns is very much like the “grep” command in Unix and Linux. Grep is an extremely powerful searching tool that lets you use regular expressions (regex) to find whatever you are looking for. It is significantly more powerful than any sort of Windows or Mac operating system search function. Second-gen SAST tools use regex to find specific patterns, and they do it very quickly. An example of an anti-pattern would be if an application takes input from the user, concatenates it to some SQL statements, and sends it directly to the database to be executed, as is. Because it does not use a stored procedure or perform input validation, we know it is very likely to result in a SQL injection vulnerability. Second-gen tools use several types of anti-patterns like that to find numerous types of vulnerabilities.
Pattern matching is exciting because it is very fast, and the results tend to be mostly true positives, i.e., real vulnerabilities in your application. Plus, pattern matching tools run in minutes, not hours. However, they also tend to miss some vulnerabilities. And, unfortunately, second-gen SAST tools that use both pattern matching and flow analysis together can also miss some vulnerabilities.
Not every organization derives the same value from a first- or second-gen SAST tool. Use the guidelines below to ensure you choose the SAST tool that best fits your business.
Consider First-gen SAST if:
Consider Second-gen SAST if:
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.
February 21, 2024
By IANS Research
Learn why cloud IR is critical to security and not just another box to check. Find guidance to get started building a strong cloud IR program.
February 15, 2024
By Alex Sharpe, IANS Faculty
IANS Faculty member Alex Sharpe discusses the risks around AI adoption and provides governance guidance to make your AI launch safe and mitigate risk.
February 13, 2024
By IANS Faculty
Learn how to how to use NIST to modify secure baseline configurations to account for risk and improve security posture.