SDLC, or How to Make Development More Secure?

With the development culture continuing to evolve rapidly, new code quality assurance tools are appearing on the market and being used in dramatically new and innovative ways. We’ve already written about static analysis, what to pay attention to when choosing an analyzer, and, finally, how to establish a static analysis-based process for your organization.

After reviewing frequently asked questions, we described the entire process of integrating a code scanner into a secure development process. Today, we’ll talk about how to choose the analyzer that suits you best.

One way or another, all developers face static analysis (also known as static application security testing or SAST, which means code analysis without execution), like when a compiler returns build errors or warnings. We often use linters, another SAST tool, albeit a rather simple one. Other interesting engines include spotbugs (former findbugs) to help find unusual vulnerabilities in Java bytecode and the well-known SonarQube, a code quality monitoring platform.

However, we still rarely use full-fledged SAST solutions. First of all, we are talking about tools capable of detecting advanced vulnerabilities. As we have seen from experience, well-known open-source tools cannot cope with this task just because they focus on another area (bugs and simple vulnerabilities). A good SAST tool provides interprocedural dataflow analysis. Rather than program text, this should address its internal representation, such as CFG, AST, etc. To learn more, please read our previous post.

SAST

Let’s take a common SQL injection as an example. Here, 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 must not be used. On top of that, we also need to monitor data movement throughout the application or, in other words, perform dataflow 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 intraprocedural analysis, which is the only option available in some open-source tools. To find such vulnerabilities (which are usually the most critical and the key target of a SAST tool), we need well-developed algorithms for interprocedural dataflow analysis with large rule bases.

Since algorithmic complexity raises some technical issues, SAST implementation differs from that of other static analyzers, such as SonarQube. We will discuss these issues in our posts. Spoiler alert: it’s all about resource consumption, analysis duration, and false positives.

In addition to algorithms, a good tool wraps up all the underlying math into an easy-to-use and intuitive shell, thus allowing SAST to be used without serious training. Such tools can also be embedded in CI/CD through plugins and APIs to automate the search for vulnerabilities and build secure development processes.

In the first post, we tried to classify the main questions arising when studying and opting for SAST. 

Let’s start! 
We already have free static analyzers, so why use SAST? 

In the previous part, we already addressed this question to some extent. Of course, we in no way want to diminish the merits of open-source tools. Everyone knows that 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 errors or vulnerabilities. The solution also lacks interprocedural dataflow analysis and thus cannot find advanced vulnerabilities. Usually, we recommend using both SonarQube and a good SAST tool (one capable of integrating with SonarQube is the best choice).

There are other good open-source static analyzers. One of them is spotbugs (findbugs) for JVM bytecode, which has a find-sec-bugs plugin featuring intraprocedural dataflow analysis with a small rule set. For Python, there is a rather popular bandit analyzer. A static analyzer built into clang should also be mentioned for its good analysis engine and rule base.

Just remember that such tools have a narrow focus of specialization (e.g. support one language only) and use simple algorithms (i.e. cannot find advanced vulnerabilities). Compared to commercially available products, open source tools have much smaller rule bases, poorer interfaces and integration functionality, and, of course, no support at all.

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.

Also, here you can see an example of a SAST-based integration chart. In general, the chart is like those of other code quality controls. 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? 

Now, let’s talk about choosing a tool. There are many SAST solutions, with 3-4 typically being available on the market at any one time. But how to choose the right tool and what to pay attention to? No surprise here. I would rather focus on three obvious criteria: functionality, quality, and licensing. Ideally, you should pilot a tool in your local environment and test it on your code and infrastructure.

It would be nice to try all interface features to understand to what extent they apply to your situation and how user-friendly they are. For more details, read one of our previous posts. Here are some useful features:

·         Automated — ideally, two-click-away — scanning launch (without excessive setting effort)

·         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 (qualitative, i.e. tracking of vulnerabilities from scan to scan of same project)

·         Scan result editing, with the editing results being tracked from scan to scan of same project

·         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, bugtracker, 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 and — for better understanding — take several samples written in different languages. As for quality, look at both false positives (i.e. the tool incorrectly indicates a vulnerability) and false negatives (ideally, you need to know where the vulnerabilities are or compare those found by different tools). Personally, I would pay less attention to false positives since it is usually enough to go through scan results once, mark false positives, and they will no longer bother you.

Let’s focus on two critical points. First, it is your situation that matters. So check your code, not someone's else (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.

Second, communicate with the vendor during the pilot. SAST is not that simple and consultation with the vendor may help you realize the full benefits of the tool.

When to launch scans? 

The sooner a vulnerability is found, the less expensive it is. You can find all kinds of charts and tables on this subject on the web, so I won’t bother to add them here. However, remember this golden rule: it’s one thing to fix a vulnerability a day after it was introduced, and quite another to patch an already-hacked production server. That is why SAST use should be moved to early development stages. Some may claim that introducing SAST during the development process is rather expensive and may not pay off. From my experience, finding several critical vulnerabilities usually justifies the entire implementation cost (you can even make such calculations as part of the pilot).

Moreover, this approach provides us with another “bonus”: when developers see SAST results every day, they improve their secure programming knowledge, which contributes to a more secure development culture and, ultimately, better code.

Of course, implementing SAST in the development process requires integration with CI/CD and DevSecOps establishment. The trend of moving SAST from pre-release checks to the development process has been visible for a long time worldwide. Today, every pilot includes integration capability testing.

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.

Technical questions 

And now, let’s address four questions at once:

1.    Why not connect SAST as SonarQube? Why is it difficult?

2.    SAST is slow. How to configure DevSecOps?

3.    SAST returns false positives. How to configure Quality Gate?

4.    Even without false positives, a report contains thousands of vulnerabilities. How to handle them?

These are key technical questions that arise during SAST implementation, and here are reasons behind.

1.    Due to the exponential nature of algorithms, SAST may run for a long time and consume many resources – much more than a linter or SonarQube.

2.    For the same reason, SAST may return many false positives – it is unlikely that developers will be eager to handle a pile of false positives after every daily scan.

3.    Usually, SAST is launched on a code base initially and the first run may return many positives, especially if there is a lot of code and the database is not very new.

All the questions have answers. In the next post of the series, we will share a specific case from our experience and show you how to implement SAST in order to address all its technical peculiarities and ensure everyone is happy. 

Organizational issues 

Lastly, large companies face numerous organizational issues, from implementation procedures and resource allocation to regulation development and process replication.

Organizational issues are triggered by the same technical questions we discussed in the previous paragraph. Besides this, do not forget that developers and security officers are still not best friends and never have been.