The Battle Between Linters, Scanners, and Data Flow Analysis
Tags: softwareengineering, sast, securityengineering, appsec
Published: 2021-07-23 18:04:17

---
title: The Battle Between Linters, Scanners, and Data Flow Analysis
published: true
date: 2021-07-22 15:56:14 UTC
tags: softwareengineering,sast,securityengineering,appsec
canonical_url: https://blog.shiftleft.io/the-battle-between-linters-scanners-and-data-flow-analysis-7478f16e400c
---

#### How to balance accuracy and scan times when it comes to application security tools

![](https://cdn-images-1.medium.com/max/1024/1*ViVVlnGBor2TkwOpPdWsmw.jpeg)<figcaption><em>Image by </em><a href="https://pixabay.com/users/geralt-9301/?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=942487"><em>Gerd Altmann</em></a><em> from </em><a href="https://pixabay.com/?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=942487"><em>Pixabay</em></a></figcaption>

When it comes to security tools, you’re typically balancing two things: how much time it takes for a tool to run to get deeper results vs. the quality of results returned.

As you might expect, faster tools scan just the source code in a single repo (without looking in the open-source libraries and SDK used) and may detect easy-to-find vulnerabilities. In contrast, tools that give better results and can find more challenging vulnerabilities with fewer false positives require more time to complete their scans.

This article covers these issues in-depth and how you can balance between accuracy and scan times.

### Basic security checks

You’re probably using linters already, and though they might not come to mind when someone mentions security tools, they do play a role.

Linters can help fix common issues, such as basic programming errors; not all of these cause build-time errors, so fixing these programming errors means that you’re not leaving pathways that someone could potentially exploit in the future. Linters can help maintain security hygiene.

Some options could even be considered lightweight scanners that offer a closer look at your code. For example, there are options for JavaScript users that check for things such as if/else loops that lack a closing statement or redundant branches in if/else blocks.

These tools are easy to use and provide near-instantaneous feedback often during the software development life cycle.

### Leveling up your security tools

One basic step for improving security is to reduce false negatives, which are real vulnerabilities that a tool fails to identify as issues. To get better results than what is provided by linters and lightweight scanners, you’ll need tools that can go deeper into your application’s code. One way to do so is with tools that specify rules to run against an application.

There are many language-specific options for which there are rules-based security tools available. These tools run against your application, looking for coding patterns that can indicate security issues such as hard-coded credentials, HTML templates that use unescaped data, and the use of an insecure random number source.

As we previously mentioned, these options provide better results than linters/lightweight scanners, but the trade-off is that these tools require more time to run.

### Improvements over simple rules: abstract syntax trees

More advanced security tools can parse a program and convert it to a graphical representation called the [abstract syntax tree (AST)](https://docs.shiftleft.io/core-concepts/c-syntaxtree#what-are-abstract-syntax-trees).

Abstract syntax trees are made up of nodes and edges, with nodes representing things like methods, variables, and control structures and edges indicating decomposition. For example, if we have a node representing the body of a function, then edges from this node to other nodes show that the function can be decomposed further into a return type and a block of code.

ASTs can provide more valuable results since they can use more complex rules that do more than look for commonly used patterns. For example, you might see a rule that looks for a prepared statement on the left side of an expression and concatenation on the right side (this would indicate a SQL injection vulnerability present in the code).

Targeted AST tools can be more effective than more general options, but you can still expect a fair number of false positives. False positives are problematic because they can waste time and distract engineers from real issues. AST-based tools also tend to require more time to run than the more straightforward tools mentioned so far.

### Getting serious: data flow analysis

To get good results with few false positives, you’ll need to look toward options that offer data flow analysis.

In short, what these options do is trace the path of data as it “flows” through your application. Such tools can track where data enters the application, called sources, and where the application uses the data, called sinks, to look for areas that could become security issues.

Typically, the biggest downside to tools relying on data flow analysis is that they require proper setup; you must know how the application is put together and how to build it. Typically they are also not as fast as AST-based tools because data flow analysis simply requires time to perform. One exception to these rules is ShiftLeft CORE which uniquely accomplishes fast and efficient data flow analysis by leveraging the [Code Property Graph](https://blog.shiftleft.io/why-your-code-is-a-graph-f7b980eab740).

Though data flow analysis can be resource-intensive, it is faster than DAST options and human audits. Human audits of applications for security issues are the gold standard, but this may not be feasible for companies. Not only can it be challenging to find someone to perform this task, but audits also take the longest to do; the upside is that there aren’t options that are better for finding security issues and minimizing false positives.

As such, data flow analysis is an appropriate compromise for those who want quality security scans but cannot rely on human audits. Data flow analysis strives to meet the level of analysis provided by human audits, while still being something that security engineers can automate and is fast enough to perform on the left side of the software development life cycle.

### Conclusion

When it comes to security scanning tools, it can seem like there are two significant trade-offs that you have to decide between:

- Fast tools that aren’t super in-depth or accurate
- Precise options that provide deeper analysis while taking more time (and possibly require more computing resources) to run

However, you don’t have to choose one or the other. You can use both types of tools in your software development life cycle (SDLC). You can use linters/lightweight scanners for fast, near-instantaneous feedback while also using tools offering data flow analysis when you’re ready to merge completed code into the main branch.

This way, you can avoid propagating simple issues throughout your application as it is created while also gaining reassurance at a later point that you’re finding the zero-day vulnerabilities that could compromise the integrity of your application.

* * *