Get best of the week

(S) SDLC, or How to make development safer. Part 1

image

Every year the development culture grows, new tools for ensuring the quality of code and new ideas on how to use these tools appear. We already wrote about the static analysis device , about what aspects of analyzers you need to pay attention to , and, finally, about how, from an organizational point of view, you can build a process based on static analysis .

Based on the issues that we often encounter, we described the entire process of introducing a code scanner into a secure development process. Today we will talk about how to choose the analyzer that suits you.

One way or another, all developers are confronted with static analysis (code analysis without execution). For example, when the compiler generates some errors or warnings based on the results of the assembly, these are the results of static analysis. We often use linters - this is also a static analysis, although often very simple. There are more interesting examples - spotbugs (formerly findbugs), which allows you to find quite interesting vulnerabilities in Java bytecode, or the well-known SonarQube - a platform for code quality control.

However, full-fledged SAST tools are still rarely encountered. First of all, we are talking about tools that can find complex vulnerabilities. As it turns out in practice, well-known open tools cannot cope with this task, at least because they focus on another area (bugs and simple vulnerabilities). A good SAST tool implements interprocedural data flow analysis. The analysis should not take place on the program text, but on the internal presentation - CFG, AST, etc. Read more about this in the previous article .

SAST


Here is an example - the well-known SQL injection. In this example, data from the user falls into the completed function from the query, passed to the injectableQuery function, and already there they fall into the SQL query, making the application vulnerable to SQL injection.



In order to find such a vulnerability, one must understand where the “bad” data can come from, how such data can be validated, where it cannot be used. And most importantly - you need to monitor the data transfer throughout the application, this is dataflow analysis. The example is very simple, in a real application, data can go through many functions and modules, assignments and synonyms.

It is clear that text search will not find such a vulnerability. Intraprocedural analysis also will not find, and in some open tools only it is implemented. To find such vulnerabilities (and this is usually the most critical vulnerabilities, that is, the main goal of the SAST tool), we need well-developed algorithms for inter-procedure analysis of data flow with large rule bases.

It is on the basis of algorithmic complexity that a number of technical issues arise that distinguish the implementation of the SAST tool from other static analyzers, for example, SonarQube. We will discuss these issues in a series of articles. Spoiler: resource consumption, analysis duration, false positives.

It should be noted that in addition to algorithms, a good tool wraps all the math in a convenient interface shell, allowing you to use SAST without serious preparation. Such tools are also embedded in the CI / CD using plugins and APIs, thereby automating the search for vulnerabilities and allowing you to build secure development processes.



In the first article, we tried to classify the main issues that arise during the study of SAST, as well as after the decision to implement the tool. We’ll talk about some issues here, some will go to the following articles.

Let's start


Why SAST if you already have free static analyzers?


We partially addressed this question in the previous part. Of course, we in no way diminish the merits of open tools. Everyone knows SonarQube is a great tool for automating code quality assessment, with a large number of supported languages, integrations and plugins. SonarQube is good for embedding in the development process, but is intended more for counting various code metrics and searching for fairly simple errors or vulnerabilities. It does not implement interprocedural analysis of the data stream; accordingly, it cannot be used to search for complex vulnerabilities. Usually we recommend using both SonarQube and a good SAST tool (it can be useful here if the SAST tool can integrate with SonarQube).

There are other good open static analyzers. You can call spotbugs (findbugs) for the JVM bytecode with the find-sec-bugs plugin, which implements in-process analysis of the data stream with a small set of rules. There is a well-known bandit analyzer for Python. One cannot but mention the static analyzer built into clang, which has a good analysis engine and a good rule base.



The problems of such tools are that they are usually rather narrowly specialized (for example, suitable for one language), they implement simple algorithms (that is, they do not allow finding complex vulnerabilities), and they have much smaller rule bases than commercial tools. In addition, they have a smaller set of functionality, both interface and integration. Well, we can mention the lack of support.

On the other hand, good commercial SAST tools (and there are also bad ones) implement complex specific algorithms and have extensive rule bases that can include thousands of records. Usually they support many programming languages, have rich interface and integration capabilities (plugins, APIs). Below I give an example of what kind of integrations we are talking about.



And even lower, look at an example of an integration scheme that can be built on the basis of a SAST tool. In general, the scheme does not differ from the introduction of other code quality control tools. Developers write code and can immediately run a SAST check. The code gets into the repository and from there on various triggers using CI / CD gets into SAST. Scan results can either be viewed in the SAST interface, or they can end up in tools that support the development process (bug tracker, mail, etc.).



Which SAST tool to choose?


I will dwell a little at the stage of choosing a tool. There are a lot of SAST tools, usually several pieces are presented on the market (3-4). The question arises, how to choose the right tool, what to look for? Here I will not surprise, I will focus on three points: functional comparison, quality comparison and licensing. It is important to take the testing tool (pilot) in your local circuit and check on your code in your infrastructure.

It would be nice to try all the features of the interface, to understand how they are applicable to your case and how convenient they are to use. I refer to one of the previous articles . Here are some useful features:

  • the most automated launch of scanning (ideally, without unnecessary settings in two buttons, you can run a scan);
  • — , , ;
  • ;
  • ;
  • ;
  • (, );
  • ;
  • , “”;
  • “ , ”;
  • ;
  • .

The integration capabilities are very important - with CI / CD, bugtrackers, repositories, Active Directory. It would be nice to try to automate a simple action using the API, if any.

To check the quality you need to scan your code. It’s good to choose several different examples in different languages ​​so that the sample is representative. From the point of view of quality, you need to look at false positives (where there is clearly no vulnerability, but the tool shows) and omissions (ideally you need to know where the vulnerabilities are, well, or compare the vulnerabilities found in different tools). I would pay a little less attention to false positives, since it is usually enough to go through the scan results once, mark false ones, and then they will not bother you.

I will focus on two important points. First of all, it is very important to look at all this in application to your situation. Check exactly your code (SAST may work differently on different types of applications). Search for those features that you need to embed the tool in the development process. Check integration with the systems that you have.

Secondly, it is very important during the pilot to communicate with the vendor. SAST is not the easiest thing, and often it’s enough to get the usual advice from the vendor in order to fully appreciate the power of the tool.

At what point do you start scanning?


The sooner a vulnerability is found, the cheaper it is. There are hackneyed schedules wandering from presentation to presentation, I won’t even add them here. But the statement is quite obvious. It is one thing to fix the vulnerability the day after it is made, another thing is to make a change to the combat server when it has already been hacked. Accordingly, it is necessary to transfer the use of SAST to the early stages of development. Here it can be argued that the introduction of SAST in development is in itself an expensive event and it may not pay off. Here I will argue: usually finding several critical vulnerabilities covers the entire implementation (you can even conduct an assessment within the pilot).

With this approach, we also get a bonus: developers, when they see the SAST results “every day”, advance in knowledge of safe programming, thus, in general, the culture of safe development is enhanced and the code gets better.

Of course, when implementing SAST in the development process, it is necessary to implement in CI / CD, building DevSecOps. The trend of transferring SAST from control checks before release to the development process has been visible for a long time, and in the last 2-3 years it has caught up with our market. Now no pilot passes without testing the integration capabilities.

At the same time, I would leave control checks before the release, ideally, for binary assemblies (this is also possible). So you can make sure that no new vulnerabilities were added during the assembly and transfer of the application to the product.

Technical issues


And then I’ll give you 4 questions right away.

  1. Connect SAST as SonarQube, what is the difficulty?
  2. SAST works for a long time, how to configure DevSecOps?
  3. SAST gives false positives, how to configure Quality Gate?
  4. And without false positives in the report, several thousand vulnerabilities, what to do with them?

These are the main technical issues that arise when implementing SAST. They arise for the following reasons.

  1. Due to the exponential nature of the algorithms, SAST can run for a long time and consume a lot of resources - much more than a linter or SonarQube.
  2. For the same reason, SAST can give a lot of false positives - it is unlikely that developers will want to parse a bunch of falls every day after the next scan.
  3. Usually, SAST is launched on the code base for the first time, and the first run can show a lot of operations, especially if there is a lot of code and the database is not very new.

All issues are solvable. In the next article in the series, we will examine, using a concrete example from our experience, how to implement SAST in such a way as to level all its technical features and to make everyone happy.

Organizational matters


I would not forget about organizational issues. In large companies, a lot of them arise, from the implementation process itself, the allocation of resources to the creation of regulations and the replication of processes.

Organizational issues are generated by the same technical features that we discussed in the previous paragraph. Well, besides this, the historically established division and confrontation between development and security have not yet gone away. I also refer to our previous article.

To be continued


Implement SAST - it is necessary, it is usually justified. But, starting to implement, it would be nice to get acquainted with all the pitfalls that arise on your way. In this article, we began to disassemble them, we will continue with technical aspects in the following.

More articles:


All Articles