How to choose a SAST tool to secure your development?


A good SAST tool provides inter-procedural data-flow analysis.

When it comes to secure development, how do you integrate a code scanner into the process, what are the traps and pitfalls?

Аll developers face static analysis (static application security testing or SAST, which means code analysis without execution). However, we still rarely see full-fledged SAST solutions in use capable of detecting advanced vulnerabilities. Well-known open-source tools often cannot cope with this task just because they focus on another area (bugs and simple vulnerabilities). A good SAST tool provides inter-procedural data-flow analysis.

Using a common SQL injection as an example, the user-supplied data goes to completed function from a query, then moves to injectableQuery function, and finally reaches an SQL query, thus making an application vulnerable to SQL injection.

To find such a vulnerability, we need to understand where “bad” data can come from, how to validate it, and where it mustn’t be used. We also need to monitor data movement throughout the application or, in other words, perform data-flow analysis. While this example is very simple, in a real application, data can travel through many functions, modules, assignments, and synonyms.

Obviously, a text search won’t find such a vulnerability. Neither will inter-procedural analysis, which is the only option available in some open-source tools. To find the most critical vulnerabilities, we need well-developed algorithms for inter-procedural data-flow analysis with large rule bases.

Since algorithmic complexity raises some technical issues, SAST implementation differs from that of other static analysers, such as SonarQube. In addition to algorithms, a good tool wraps up all the underlying maths into an easy-to-use and intuitive shell. Such tools can also be embedded in CI/CD through plugins and APIs to automate the search for vulnerabilities and build secure development processes.

Below are the main questions arising when studying and opting for SAST.

We already have free static analysers, so why use SAST?

We in no way want to diminish the merits of open-source tools. SonarQube is a great solution to automate code quality assessment, with a lot of supported languages, integrations and plugins. Although easy to embed in the development process, SonarQube mainly counts various code metrics and searches for rather simple vulnerabilities. The solution also lacks inter-procedural data-flow analysis and thus cannot find advanced vulnerabilities. Usually, we recommend using both SonarQube and a good SAST tool capable of integrating with SonarQube.

There are other good open-source static analysers. One of them is spotbugs (findbugs) for JVM bytecode, which has a find-sec-bugs plugin featuring inter-procedural data-flow analysis with a small rule set. For Python, there is a popular bandit analyser. A static analyser built into clang has good analysis engine and rule base.

Just remember that such tools have a narrow focus (eg support one language only) and use simple algorithms (ie cannot find advanced vulnerabilities). Compared to commercial products, open source tools have much smaller rule bases, poorer interfaces and integration functionality, and no support.

Instead, quality commercial SAST tools (remember, not all of them are good) use complex specific algorithms, have extensive rule bases including up to thousands of records, support many programming languages, and feature rich interface and integration capabilities (plugins, APIs). Integration examples are provided below.

Further is an example of a SAST-based integration chart. Developers write a code and can run SAST right away. The code goes to a repository and then, using CI/CD and various triggers, to SAST. Scan results can either be viewed in a SAST interface or transmitted to development supporting tools (bug tracker, email, etc.).

What SAST tool to opt for?

Focus on three criteria: functionality, quality, and licensing. You should pilot a tool in your local environment and test it on your code and infrastructure. Try all interface features to understand to what extent they apply to your situation and how user-friendly they are:

  • Automated — ideally, two-clicks-away — scanning launch
  • Analysis of different app types: source code, binary code, and several languages in one file
  • Directory exclusion from analysis
  • Incremental analysis
  • Addition of custom vulnerability search rules
  • Scan comparison (vulnerabilities tracking from scan to scan)
  • Scan result editing being tracked from scan to scan
  • Clear vulnerability descriptions, preferably with a dataflow analysis trace for injection type vulnerabilities
  • Metric reflecting “tool’s confidence that a detection is not a false positive”
  • Flexible administration
  • Rich and easy-to-use analytic functions

CI/CD, bug tracker, repository, and Active Directory integration capabilities are very important. Automating a simple action through an API (if available) is also a good idea.

To check SAST tool performance, scan your code taking several samples written in different languages. As for quality, look at both false positives (ie the tool incorrectly indicates a vulnerability) and false negatives (you need to know where the vulnerabilities are or compare those found by different tools).

It’s also Important to remember to check your code, not someone else’s; SAST may work differently on different application types. Look for the features you need to embed in your development process and check integration with the systems already in place. Communicate with the vendor during the pilot programme. SAST is not that simple and vendor consultation may help you see all the benefits.

When to launch scans?

It’s one thing to fix a vulnerability a day after it was introduced, and quite another to patch up an already-hacked production server. That is why SAST use should be moved to early development stages. When developers see SAST results regularly, they improve their secure programming knowledge, which contributes to a more secured development.

However, I would use pre-release checks anyway, ideally after each binary build (this is also possible). This way, you can make sure that no new vulnerabilities were added during app build and transfer to production.

To sum up, SAST is a must-have that usually pays off. However, before proceeding with implementation, I strongly recommend reviewing all potential pitfalls.

Contributed by Dan Chernov MSIS, CISSP, CISA, CTO, Solar appScreener