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

Now they are talking a lot about methods of statistical analysis of code for vulnerabilities. There are a lot of opinions about this phenomenon: from a zealous denial of the effectiveness of the method to the exaltation of effectiveness to the skies. The truth, as usual, somewhere in the middle. Therefore, let's try to find it, and at the same time create a common vision of how an ideal static analyzer should look.

Scope of application

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

And in theory, this is actually the case. However, in practice, everything is somewhat more complicated. First of all, because the stopping problem is about the Turing Machine — an abstract computer that has an unlimited supply and, accordingly, an infinite number of states in which it can be. 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 theory should be applied to finite automata, or, more simply, ordinary computers that do not have an infinite number of states. And applications executed in such an environment are quite amenable to analysis by another program.
')
In addition, in principle, static testing of security is not necessary 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 the Turing Machine, it will still be possible to light 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 the appearance of vulnerabilities. Obviously, because of this, this method cannot be used as the main one - the likelihood of both false alarms and missed threats is too high. The method is mainly used to detect suspicious code areas that need additional analysis.
  
  
• Examination of code execution models. Much more advanced way. Based on the search for such a combination of data processed by the application that could lead to the occurrence of 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.
  
  
• Research flow calculations. It is based on the use of symbolic computations — the transformation of a concrete code into its abstract interpretation, which can work effectively not only with clearly defined, but also with unknown variables. In the future, based on this technique, a model of vulnerability to a specific type of attack is written, written in a symbolic language, which greatly simplifies and refines the search for problem areas in the code.

SAST Alternatives

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

In this case, the already running application is examined. It is launched 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 the program and run a lot of tests on it. In addition, the analysis results may be distorted by previous research launches.

Another type of testing is funny, or interactive, IAST. It uses both dynamic and static analysis. SAST models potential inbound data sets that could lead to vulnerabilities, and DAST, based on this information, conducts real-world application tests.

Ideal analyzer

So, we looked at the capabilities, methods and alternatives of code analyzers for vulnerabilities. What characteristics should they have in order to do their job as effectively 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 use of both methods inherits their disadvantages. Therefore, the analyzer program must be able to work flexibly with a specific code and maintain a balance between the utilized capacity and operating time.
  
  
• Upon completion of the analysis, the system should clearly indicate how the attack can be carried out, so that you can then verify for yourself that this is not a false positive.
  
  
• Testing should be provided with the ability to manually check the code, especially those parts of it, where neither confirmation nor denial of the presence of vulnerabilities was received. Of course, these requirements are largely theoretical, and it is unlikely that we can now find or create such an ideal analyzer. However, this is what their overall development vector should be.

What do you think?