Static Analysis and Dynamic Analysis

Finding and fixing bugs early in development pays off in many ways. It can reduce development time, cut costs, and prevent data breaches or other security vulnerabilities. In particular with DevOps, incorporating testing into the SDLC early and continuously can be extremely helpful.

This is where both dynamic and static analysis testing come in. They each serve different purposes within the SDLC while also delivering unique and almost immediate ROIs for any development team.

Static vs. Dynamic Analysis: Understanding the Differences

Static code analysis is a broad term used to describe several different types of analyses. However, all of these feature a common trait: they do not require code execution to operate.

In contrast, dynamic analysis does require code execution. Though there are other differences, this characteristic is what drastically separates the two types of testing approaches.

This also means that each approach offers different benefits at different stages of the development process. In order to understand these differences, let’s review the following.

• What each strategy requires.
• Testing types under the umbrella terms.
• Tools that assist the process.

What Is Static Analysis?

Static code analysis testing includes various types with the main two being pattern-based and flow-based.

Pattern-based static analysis looks for code patterns that violate defined coding rules. In addition to ensuring that code meets uniform expectations for regulatory compliance or internal initiatives, it helps teams prevent defects such as resource leaks, performance and security issues, logical errors, and API misuse.

Flow-based static analysis involves finding and analyzing the various paths that can be taken through the code. This can happen by control (the order in which lines can be executed) and by data (the sequences in which a variable or similar entity can be created, changed, used, and destroyed). These processes can expose problems that lead to critical defects such as:

• Memory corruptions (buffer overwrites)
• Memory access violations
• Null pointer dereferences
• Race conditions
• Deadlocks

It can also detect security issues by pointing out paths that bypass security-critical code such as code for authentication or encryption.

Additionally, metrics analysis involves measuring and visualizing various aspects of the code. It can help detect existing defects, but more often, it warns of potential difficulty in preventing and detecting future defects when code is maintained. This is done by finding complexity and unwieldiness such as:

• Overly large components
• Excessive nesting of loops
• Too-lengthy series of decisions
• Convoluted intercomponent dependencies

What Is Dynamic Analysis?

Sometimes referred to as runtime error detection, dynamic analysis is where distinctions among testing types start to blur. For embedded systems, dynamic analysis examines the internal workings and structure of an application rather than external behavior. Therefore, code execution is performed by way of white box testing.

Dynamic analysis testing detects and reports internal failures the instant they occur. This makes it easier for the tester to precisely correlate these failures with test actions for incident reporting.

Expanding into the external behavior of the application with emphasis on security, dynamic application security testing (DAST) is analytical testing with the intent to examine the test item rather than exercise it. Yet the code under test must be executed.

DAST also extends the capability of empirical testing at all levels—from unit to acceptance. It does this by making it possible to detect internal failures that point to otherwise unobservable external failures that occur or will occur after testing has stopped.

Pros & Cons of Static Analysis

As with all avenues toward DevSecOps perfection, there are pros and cons with static analysis testing.

PROS

• Evaluates source code without executing it.
• Analyzes the code in its entirety for vulnerabilities and bugs.
• Follows customized, defined rules.
• Enhances developer accountability.
• Capable of automation.
• Highlights bugs early and reduces the time it takes to fix them.
• Reduces project costs.

CONS

• Can return false positives and false negatives that might distract developers.
• Can take a long time to operate manually.
• Can’t locate bugs or vulnerabilities that come about in runtime environments.
• Deciding which industry coding standards to apply can be confusing.
• May be challenging to determine if deviating from a rule violation is appropriate.

While the list of cons might look intimidating, the holes of static analysis can be patched with two things.

1. Automating static analysis.
2. Using dynamic techniques.

Why Static Code Analysis Is So Valuable

All these types of static analysis have one thing in common: they involve scanning or having a program examine source code.

This is a fast and easy way to expose critical defects. It achieves 100% coverage with 100% objective results.

Doing it continually just makes sense as it delivers these actionable results, reduces costs and development time, increases code coverage, and more.

Beyond the Scope of Static Analysis

Static scanning provides information to help predict what may happen when code is integrated and executed. It detects defects based on what the tool considers a defect. Typically, this can be customized to suit your preferences and priorities.

However, it cannot tell you when the system under test or in production delivers unexpected, inappropriate, or inaccurate results.

The challenge here is to observe unexpected behavior. For example, a transaction may appear to proceed correctly to a user, tester, or test execution tool when, in fact, a component has thrown an unhandled exception and failed to process it correctly. A control system may respond quickly and correctly under test for three days but could be leaking memory and heading for a crash on day four in production.

Fixing all defects detected by using a static code analysis tool gives no assurance against other defects that will cause failures like these. That’s why it’s important to apply the definition of failure to internal as well as external behavior—even after integration. The internal failure must be detected before it manifests itself externally.

Best Practices for Combining Static & Dynamic Analysis

Combining static and dynamic analysis is the best option to get actionable results, reduce bug occurrences, increase bug detection, and create more secure code overall. One is not better or worse than the other. They work in tandem like all the gears of a perfectly crafted Swiss watch.

To use static and dynamic analysis together, follow these best practices.

• Use them both with manual and automated solutions that fit your needs.
• Make the code readable and reusable for other developers.
• Use the right approach at the right point in your SDLC—static early on and dynamic in runtime environments.
• Make use of both approaches for a more holistic overview of your project.
• Avoid the pitfall of relying on only one testing method, a small oversight that can lead to big problems.

Combining static and dynamic analysis empowers teams to locate a wider range and number of exploitable threat vectors.