How do you get started with JavaScript static analysis?

To get started with JavaScript static analysis, install a linter, run it in your editor and in CI, then add security-focused rules and a scanner that tracks data flow from inputs to risky functions. Begin in report-only mode, tune the noise, and fail builds only on rules the team trusts.

What is static analysis?

Static analysis examines code without running it. NIST's Secure Software Development Framework, SP 800-218, includes reviewing and analyzing code for vulnerabilities and testing it as practices for producers, and names automated tools as one way to do it. For JavaScript that covers two quite different layers.

The first is linting: style problems and likely bugs, such as unused variables, unreachable code and comparisons that are always false. ESLint is the widely used linter in the ecosystem, and its documentation describes setup through a project configuration file and a command line tool.

The second is security analysis: rules that know which functions are dangerous, which inputs are untrusted, and whether untrusted data reaches a dangerous function without cleaning. That second layer is where taint analysis lives.

Why does JavaScript need extra care?

JavaScript is dynamic. Objects can gain properties at runtime, strings can become code with eval, and functions are passed around freely. That limits what a tool can prove. Expect false positives where a tool cannot know a value is safe, and false negatives where data flow is too tangled to follow. This is normal for the technique. It is also why static analysis complements, and does not replace, dependency scanning and testing of the running application.

What should you look for first?

Pick a handful of classes that matter in JavaScript applications:

• Injection: user input reaching a database query, a shell command or eval.
• Path handling: request data used in file paths.
• Cross-site scripting: untrusted data written into HTML.
• Unsafe deserialization and prototype pollution in object merges.
• Hard-coded secrets in source.
• Weak or misused cryptography.

A constructed example

A team adds ESLint with its recommended rules and finds 140 style warnings. They fix a few real bugs, such as a variable shadowing bug in a retry loop, and silence the rest by rule. Then they add a security ruleset and scan the web routes. One finding stands out: a request parameter flows through two helper functions into a child process call. It looks harmless until someone passes a semicolon. They replace the shell call with an argument array, which removes the problem, and add a rule to the CI gate so that class cannot return.

How do you handle false positives?

Every tool produces some. Decide the rule up front: a finding is either fixed, or suppressed with a written reason and a reviewer. Suppress at the narrowest scope, a single line, rather than switching off a rule for the whole project. Track the suppression count over time. If it grows faster than the codebase, the ruleset is too noisy or the team has stopped looking, and either way it needs attention.

How to check or apply this

1. Add a linter and a config file to the repository, and run it in the editor.
2. Run the same checks in CI, in report-only mode for the first two weeks.
3. Add a security ruleset or a data-flow scanner, and run it on the whole repository once.
4. Sort the findings by class. Fix one class at a time, starting with injection and secrets.
5. For each suppressed finding, write a short reason in the code or the config.
6. Turn on blocking for rules with a low false positive rate, and keep noisy ones as warnings.
7. Review new findings in pull requests, where the author still remembers the code.
8. Pair it with dependency scanning, since most JavaScript risk arrives through packages.

Safeguard offers SAST code scanning, IDE extensions for VS Code, Cursor and JetBrains, and a CLI that runs in CI, so the same checks run in the editor and the pipeline.

Open the full demo

Quick check

Sources

• NIST SP 800-218, Secure Software Development Framework
• ESLint, Getting Started
• OWASP Web Security Testing Guide
• Node.js, Security Best Practices

Last reviewed: 18 October 2026.