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 Tool Issues
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
How Do Second-Gen SAST Tools Work?
Second-generation SAST tools tried to fix first-gen tool issues through a combination of flow analysis and pattern matching.
SAST Flow Analysis
“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.
SAST Pattern Matching
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.
How to Choose the Right SAST Tool
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:
- You have a large application security team: Large teams are more likely to be able to handle the huge amount of work required to get value from these tools.
- Security must be as close to perfect as possible: Well-resourced, top-secret government organizations, organizations that work to prevent terrorism, businesses that provide services or resources in extremely high demand, and/or those with extraordinarily valuable intellectual property would gain more value from the first-generation types of tools. They would likely be able to go over every result in detail and take all the time necessary to validate every possible finding. They would also have the time and resources available to fix 100% of the exploitable vulnerabilities found in all their applications.
Consider Second-gen SAST if:
- You are equipping a DevOps organization: Organizations that use second-gen tools require only an average level of security assurance and tend to prioritize moving fast at all costs. If you are willing to compromise a little on the level of security, you will move exponentially faster with second-gen tools.
- Less-than-perfect security is acceptable: Many organizations do not have perfect security programs. Most of them are aware of vulnerabilities in production that are medium, high and, sometimes, even critical in nature. These sorts of companies have already compromised their level of security assurance for other business reasons (e.g., lack of budget, resources or executive buy-in about the importance of security). They will tell you security is extraordinarily important but then admit the number of critical vulnerabilities in production is in the triple digits. They clearly do not require perfect security. They are OK with being quite good, with an acceptable level of security assurance, and will see more value from a second-generation tool.
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.