Static analysis of source code

Roman Dushkov, Security Vision

Modern development strives to simplify code, increase its predictability and efficiency. Let's consider how to turn a continuous DevOps process into a secure DevSecOps process that cares about users and their security.

One way is Runtime application self-protection (RASP). It analyses the behaviour of applications and determines on the one hand their capabilities and on the other hand the zones of their operation, as applications can go beyond the boundaries of expected behaviour, access unnecessary information and simply be unsafe for end users.

Another way is that, unlike analysing an already running application, the code written by developers is sometimes examined. In this article we will study the tools of application source code analysis (Application Security Testing (AST)) by the example of Static AST ( SAST). SAST-analysers are used to examine the code for vulnerable commands, illogical interrelations and information that should not be present in good code.

Fig. 1 - Static code analysis mechanisms

The process of SAST-systems' work can be compared to a conveyor which receives text written by developers and outputs a report with a list of errors. Such a pipeline will work differently for texts written in different languages, but vendors usually offer analysis tools for all popular programming languages.

For the pipeline to work effectively, it must not only be created, but also periodically adjusted, improved and accelerated. For this purpose vendors constantly enrich their knowledge base, adding to the report with errors the ways of their elimination. Such knowledge bases include references such as OWASP, GitHub and CVSS.

So, two important factors for effective SAST are understanding the language in which the application is written and knowing how bugs can be fixed. Now let's break down step by step how the system processes text. Let's imagine that instead of an application we write an article - after the main text is written, it is passed to editors who 1) correct errors 2) make the text more readable 3) find keywords for quick search and display the article in search engines. The application source code is also analysed in different ways.

First, syntactic analysis is resorted to. Syntax differs not only in Russian, English, German and other human languages, but also for Python, GO and C++ and other programming languages. However, to a certain extent all languages are similar: just as in human languages we can identify the subject, predicate and other parts of speech, so in programming languages we can identify operators, commands and comments. Syntactic analysis allows you to detect individual fragments and regions, as in the 1000-character theorem. The work of a syntactic analyser is similar to the work of Asset Management systems, when all IT-assets of a company are laid out in order to build a network map and quickly find, for example, servers under repair. Or, if we return to the text of this article - syntax checking in Microsoft Word, as a result of which the necessary punctuation marks are inserted, the text itself is divided into paragraphs and phrases that are comfortable for reading, and a structure appears that is more convenient for SAST algorithms to perceive.

After that, the semantic analyser is switched on, which looks for a correlation between the form of the message and its semantic content. For example, zero in programming can be represented as an integer (0), a floating-point number (0,000000001) or a Boolean variable (False). You can interact with each variable in different ways: for example, you can add another number to an integer. And the True/False variable can be handled according to the rules of mathematical logic. When analysing the source code at this stage, the system determines the possibilities of commands and operators that can be optimized. From the analyser's point of view, you may not know the exact values of variables but see that the data came from an external source. Such data may be compromised, so you should inform the developer how to avoid, for example, SQL injections and buffer overflows.

Another way to analyse vulnerabilities in code is to study the transports used to transfer information. In life, each of you has probably encountered courier services (delivery of flowers, food from supermarkets and restaurants, storage of keys in safes when using Airbnb, etc.). Each delivery method has its own advantages: speed, mobility of the courier, size of the truck for transporting furniture, reliability and security. When creating applications, different transport protocols are also used, some of which are aimed at file processing, data retrieval in DBMS, API applications and others.

It is important to determine the possible risks of using different protocols - part of this work is taken care of by the SAST class system, or secrets in code repository. The latter storage is similar to mini safes for hotel keys or password storage in a browser: instead of using logins and passwords, you can apply variables to the systems, which will be securely stored separately and called while the application is running. This way, an attacker who gets the source code will not be able to find authorisation data in a system that is important to you, and therefore will not be able to attack it so easily.

Since we do not only orchestrate various means of information protection, but also automate routine and complex processes, we would like to conclude the description of SAST systems by highlighting the criticality of the procedures themselves. On the one hand, it is important to spot a vulnerability in time, but it is even more important to cover it quickly and efficiently. If the vulnerable software is already in use, but the vulnerability itself has not yet been addressed, you can either accept the risks or ensure the availability of data by introducing new security policies. There are various developer communities that help describe problems and test their work. Within companies that use off-the-shelf software, there is often no way to see and fix the source code, so vulnerabilities are inevitable. When organising processes, it is important to work efficiently on both sides: development should be secure, and fixing existing problems should be a simple and straightforward process.

Using the technologies described above, it is possible to analyse code before it is compiled, i.e. before a new version of the product is released, so developers can add SAST for security to their processes at the development stage, together with common CI/CD methods. The product itself will not fix weak and vulnerable code sections, but it will highlight possible risks. In the future, security can be further enhanced with special secret repositories, vulnerability scanners or code analysers that work dynamically.