Dynamic Program Analysis and Static Code Analysis in Web Security

There are two primary approaches to analyzing the security of web applications: dynamic program analysis (dynamic application security testing – DAST), also known as black-box testing, and static code analysis (static application security testing – SAST), also known as white-box testing. Both approaches have their advantages and disadvantages and one cannot be seen as a replacement for the other. Therefore, we recommend that you employ both techniques to fortify your web applications. However, if you have limited resources and cannot afford both, dynamic program analysis is often perceived as a better solution.

Static Code Analysis

Static code analyzers scan the source code of the web application and they are used as part of the code review process. They do not take into account the operating environment, the web server, or the database content. On the other hand, static analysis tools have full access to the code, so they cover hidden/unlinked code fragments (for example, new code that is being developed but not yet used) and they can pinpoint the exact line of code. They also cover all possible execution paths at once.

For example, if you used a static code analysis solution to analyze code for SQL Injections, the tool would scan the source code for all functions that query the database. It would then analyze if these functions access the database safely. If not, it would provide the exact location of the error, for example, the place where the developer used user input directly in the query. On the other hand, if you wanted to test your web application for weak passwords, a static analyzer would be useless. It would also be unable to cover security issues caused, for example, by Apache misconfiguration or issues related to the data flow.

The other big disadvantage of static code analysis tools is their full dependency on the programming language. If you select a source code analysis tool for your business and then decide to write some of your applications in a different language, you may have to purchase an additional SAST tool. While there are several multi-language tools on the market, they primarily focus on PHP, Java, and JavaScript. Few of them cover several more exotic languages at the same time, for example, Python, Objective-C, Scala, Swift, ColdFusion, or legacy languages like COBOL.

Dynamic Program Analysis

In the case of dynamic analysis, the tool does not need access to the source code at all. A DAST tool simulates an end-user and has access to exactly the same resources as the end-user. It analyzes runtime web application security using HTTP requests, links, forms, etc. This means that a DAST tool is completely independent of the programming languages that your applications use and only needs to support client-side technologies. However, it can only analyze parts that are accessible to the user.

For example, when you scan a web application for SQL Injections using dynamic analysis, the tool behaves like an automated penetration tester. It enters data in web forms and creates malformed requests to try to exploit your application. When it succeeds, it shows you how it was done. The downside is that it cannot show you the exact line of code which caused the security vulnerability, so a developer may need more time to find the error. If a dynamic analysis tool is not built using efficient technologies, it may take quite some time to work because it needs to analyze multiple execution paths. It will also not help you in any way with coding standards and code quality in general.

The Nightmare of False Positives

Leading-edge dynamic analysis tools managed to find ways to greatly reduce their false positives. Unfortunately, static code analysis tools still have this problem. Some of the leading SAST tools state that their false positive rate is around 5 percent. That is a very high rate compared to the best DAST tools.

On the surface, false positives may not seem like a major headache. However, they introduce two big issues. First of all, the analysis of false positives requires much more development team time than the analysis of real errors. This is because the developer must find ways to prove that the code is secure and must take responsibility for deciding against the tool. Therefore, some developers even resort to changing their code just for the sake of avoiding false positives. After such changes, the code may become less efficient or less readable.

The second major issue is that a tool that reports a lot of false positives causes the user of the tool to lose trust in it. With time, users start ignoring vulnerability warnings or simply stop using the faulty scanner completely.

Analysis in the Software Development Lifecycle

In the past, static analyzers were praised for the fact that they are made to be used as part of the software development lifecycle (SDLC). As such, they would be able to find security flaws earlier than dynamic analysis tools. However, leading-edge dynamic analyzers can be used at exactly the same stage now because they can be easily integrated with CI/CD tools.

If you want thorough security analysis, your DevOps can design CI/CD flows so that applicable source code (in supported languages) is first scanned using a static analyzer, then compiled, then scanned using a dynamic analyzer (for all languages). Such an approach guarantees top software quality. The use of static analysis in SDLC also makes it possible to discover errors in pieces of code that are not yet linked to the main application.

Who Is the Tool for?

Another aspect to consider when making a choice whether to go for a SAST scanner or a DAST scanner is: who do you want to use the tool? Static analyzers are tools primarily for developers and QA/testers. Developers can check whether their code is safe and QA/testers can double-check it. Of course, in both cases, this can be automated by including it in the SDLC.

Manual dynamic analyzers are usually tools for dedicated penetration testers: they help them perform black-box attacks on applications. However, business-class DAST vulnerability scanners are no longer tools for developers or penetration testers. They are designed for automation and integration and therefore are not used manually. Such tools have a great advantage: they reduce the security team workload.

If You Can’t Have Both

If you don’t want to invest in SAST tools for all your languages and you decide to go for only a DAST tool instead, you have another option to consider. Business-class dynamic scanners employ additional mechanisms that are not exactly static code analysis but bring you closer to it. This technology is often called interactive application security testing (IAST) or grey-box testing. For example, Acunetix uses AcuSensor technology which intercepts calls to the source code or bytecode (depending on the language). This gives it access to hidden functions and provides more details about the location of the vulnerability in the source code.