What’s the difference between static and dynamic code analysis, and how do you know which to use?

Let’s start with a sporting analogy to help illustrate the difference between these two methodologies. Static code analysis is analogous to practicing your baseball swing with a practice net and a pitching machine. There are minimal surprises. After a few swings, you know exactly where the ball is going to be every time. This helps to work on fundamentals and to make sure that you have good form. While this helps with improving your game, it can only get you so far.

Dynamic code analysis is more like practicing your swing against a live pitcher with variation in the types and locations of each pitch. It tests not only your fundamentals, but your ability to react to different, unexpected situations. When done in production, it’s like perfecting your swing at the bottom of the 9th with the bases loaded. Did I mention that the score is tied with 2 outs? The stakes are high.

Now, let’s compare and contrast the two different styles from a technical perspective.

Static Code Analysis

Static code analysis is a method of debugging done by examining an application’s source code before a program is run. This is usually done by analyzing the code against a given set of rules or coding standards.

What does this address?

These often address code vulnerabilities, code smells and adherence to commonly accepted coding standards. These include common developer errors which are often found by “Code Peer Reviews”. 

In which stage of the SDLC (Software Development Lifecycle) can we use Static code analysis?

These are usually incorporated at any stage after the “Code Development” phase and before “Unit/Component/Integration” testing phases. In some cases, CI/CD pipelines incorporate Static analysis reports as a quality gate for code promotion.

Benefits

Among other benefits, the ability to identify weaknesses in the code and to adhere to strict development standards help reduce potential production issues. These also provide “Test Coverage” reports that describe the degree to which the code has been exercised.

Limitations

In real life, what works for “Joe” doesn’t work for “Jane”. Static code analysis treats both the same since it cannot see the data.

Consider the following pseudo code: 

In the above example, static code analysis provides no understanding of developer intent. A user expecting “Jane’s” full name as “Jane Doe” gets “Dave”. Any other name returns “Joey”. Any downstream application expecting a valid user would now face runtime errors or exceptions.

Issues like these could easily pass “Static Code analysis rules”, JUnits, even “Code coverage” reports. Production is the “Wild Wild West” and often contains a plethora of business flavors. “Production scenarios” don’t adhere to any given set of rules.

Finally, automated static code coverage tools often provide a false sense of security that everything is being validated. The truth is that the reports are only as good as the underlying rules that govern them.

Dynamic Code Analysis

Dynamic code analysis is the method of debugging by examining an application during or after a program is run. Since the source code could be run with a variety of different inputs, there isn’t a given set of rules that can cover this style.

What does this address?

These address runtime vulnerabilities that occur due to variations in business context. For example, the code snippet from above would be flagged by dynamic code analysis. Tools such as OverOps take this a few steps further. 

  1. For every runtime event, OverOps answers what happened, when it happened and why it happened.
  2. OverOps enables the detection, classification and prioritization of all runtime anomalies on multiple facets.

In which stage of the SDLC (Software Development Lifecycle) can we use Dynamic code analysis?

These can be used in multiple places. 

  1. For production, dynamic code analysis provides information to help troubleshoot production incidents quickly. 
  2. For pre-production, dynamic code analysis prevents bad code from going into production. These can be used in conjunction with CI/CD tools as a quality gate for code promotion.

Benefits

In production, dynamic code analysis helps provide visibility to application issues, reducing MTTI for production incidents. Overops goes even deeper – determining the exact offending line of source code with variable values.

overops root cause analysis screen

Limitations

If the code doesn’t run, it doesn’t get analysed. In addition, dynamic code analysis cannot perform the function of static code analysis tools, it’s best used in conjunction with them.

Conclusion

Just like practicing your swing against both a machine and a live pitcher, these approaches go hand-in-hand. Static code analysis often finds issues in unexercised code that dynamic code analysis can’t. At the same time, dynamic code analysis covers production scenarios that static analysis doesn’t.

OverOps provides a very unique approach to dynamic code analysis – it analyzes application code at runtime and can detect every issue with complete context into True Root Cause. With the OverOps Platform, DevOps teams are able to observe and monitor application reliability in real time based on real code situations.

Karthik Lalithraj is a Principal Solutions Architect at OverOps with focus on Code Quality and Application Reliability for the IT Services industry. With over 2 decades of software experience in a variety of roles and responsibilities, Karthik takes a holistic view of software architecture with special emphasis on helping enterprise IT organizations improve their service availability, application performance and scale. Karthik has successfully helped recruit and build enterprise teams, architected, designed and implemented business and technical solutions with numerous customers in various business verticals.