Static code testing for vulnerabilities: what should be the ideal analyzer?

Now a lot of talk about methods of statistical analysis of code on vulnerabilities. There are a lot of opinions about this phenomenon: from the zealous denial of the effectiveness of the method to the extolling of effectiveness to heaven. Truth, as usual, is somewhere in between. Therefore, let's try to find it, and at the same time draw up a general vision of how an ideal static analyzer should look.

Scope of application


Static Application Security Testing (or SAST for short) is the analysis of the code or its part for vulnerabilities without actually launching the application under investigation. Usually specialized software is used for this. People familiar with Turing's work are probably grinning maliciously, because the famous computer scientist has successfully proved that no program can analyze another and determine whether its execution will be stopped with any data set.

And in theory, this is actually so. However, in practice, everything is somewhat more complicated. First of all, because the stopping problem is a Turing Machine - an abstract computer that has an unlimited supply and, accordingly, an infinite number of states in which it can be located. Hence the impossibility of analysis.

It is obvious that now such computing systems do not exist and will not exist for a long time. Therefore, in order to consider the practical application of SAST technologies, Turing's theory must be applied to finite state machines, or, more simply, ordinary computers that do not have an infinite number of states. And applications running in such an environment can be easily analyzed by another program.

In addition, in principle, static security testing does not need to investigate all possible variants of code execution, because for security analysis it is necessary to investigate only its part, which may contain vulnerabilities. Therefore, even if we are talking about a Turing Machine, it will still be possible to shine the number of its states to a finite number for SAST.

Static Analysis Methods


To analyze application code for vulnerabilities, three approaches are usually used, both together and separately.

  • Signature search. The easiest method. It is based on a search in the main code of occurrences of a given syntactic model, which leads to vulnerabilities. Obviously, because of this, this method cannot be used as the main one - the probability of both false positives and missed threats is too high. Basically, the method is used to identify suspicious sections of code that need additional analysis.

  • Study of code execution patterns. A much more advanced way. It is based on the search for such a combination of data processed by the application that could lead to a vulnerability. The method does not take into account many factors of the code and often gives false positive results. For example, such an analysis can detect the vulnerability of a function to XSS injection, while in fact the data stream is successfully filtered and such an attack is impossible.

  • Study flow computing. It is based on the use of symbolic calculations - transforming a specific code into its abstract interpretation, capable of working effectively not only with clearly defined, but also with unknown variables. In the future, on the basis of this technique, a model of vulnerability to a certain type of attack, written in a symbolic language, is developed, which greatly simplifies and refines the search for problem areas in the code.

Alternatives to SAST


Already only on the basis of the name of the analysis - static - we can assume that it has another variety. Indeed, for programmatically checking code for vulnerabilities, you can also use dynamic testing (Dynamic Application Security Testing, or DAST for short).

In this case, an already running application is examined. It starts with certain parameters and variables, after which it is checked for potential threats. The disadvantages of the method are obvious: it is not always possible to deploy a program and run many tests on it. In addition, analysis results may be distorted by previous research launches.

Another kind of testing is funny, or interactive, IAST. It uses both dynamic and static analysis. SAST models potential sets of input data that could lead to vulnerabilities, and DAST, on the basis of this information, conducts real tests of the application.

The ideal analyzer


So, we examined the capabilities, methods and alternatives of code analyzers for vulnerabilities. What characteristics should they have in order to do their job as efficiently as possible?

  • Combining SAST and DAST methods. As discussed above, the simultaneous use of dynamic and static testing significantly increases the efficiency of the analysis. However, it is important to remember that the application of both methods inherits their disadvantages. Therefore, the analyzer program must be able to flexibly work with specific code and maintain a balance between the used capacities and the operating time.

  • The system should, upon completion of the analysis, clearly indicate how the attack can be carried out, so that later it can be independently verified that this is not a false positive.

  • Testing must provide the ability to manually check the code, especially those parts of it where neither confirmation nor denial of vulnerabilities was received. Of course, in many respects these requirements are theoretical, and it is unlikely that we will be able to find or create such an ideal analyzer now. However, this should be their common vector of development.

What do you think?

Also popular now: