Semgrep vs ESLint: Security-Focused SAST vs JavaScript Linter (2026)

Quick Verdict

This comparison is not a head-to-head battle between competitors - Semgrep and ESLint are fundamentally different tools that solve different problems, and most JavaScript teams should use both. Comparing them directly is like comparing a security camera system to a spell checker. Both improve your output, but they monitor entirely different dimensions.

ESLint is a JavaScript and TypeScript linter. It runs in your editor in real time, catches code style violations, potential bugs, and convention deviations as you type. It enforces team coding standards through configurable rules and a massive plugin ecosystem with over 2,900 npm packages. It is free, open source, and used by virtually every JavaScript project in existence.

Semgrep is a multi-language static application security testing (SAST) tool. It scans source code for security vulnerabilities - SQL injection, cross-site scripting, insecure deserialization, hardcoded credentials, and hundreds of other exploitable patterns. It supports 30+ languages, runs in CI/CD pipelines in seconds, and its YAML-based rule authoring is the most developer-friendly in the SAST industry. The open-source CLI is free for commercial use, and the full platform is free for up to 10 contributors.

The short answer: Use ESLint in development (editor + pre-commit hooks) for code quality and consistency. Use Semgrep in CI/CD for security scanning. ESLint catches the bugs and style issues you care about as you write code. Semgrep catches the security vulnerabilities that could get your application breached after deployment. If you only pick one, ESLint is essential for any JavaScript project. But skipping Semgrep means skipping security scanning entirely - and eslint-plugin-security is not a substitute for real SAST.

At-a-Glance Comparison

Category	Semgrep	ESLint
Type	SAST security scanner	JavaScript/TypeScript linter
Primary purpose	Find security vulnerabilities	Enforce code quality and conventions
Languages	30+ (JavaScript, TypeScript, Python, Java, Go, Ruby, C, etc.)	JavaScript, TypeScript (via plugins: JSX, Vue, Svelte)
Rule format	YAML (pattern-based, mirrors target language)	JavaScript (AST visitor functions)
Total rules	20,000+ Pro / 2,800+ community	~300 core + thousands via plugins
Security depth	Deep - taint tracking, cross-file analysis, reachability	Minimal - surface-level patterns via plugins
Runs in	CI/CD pipeline, CLI, VS Code extension	Editor (real-time), CLI, pre-commit hooks, CI
Real-time editor feedback	Limited - scans on file save	Native - runs as you type with zero delay
Taint analysis	Yes (Pro engine - cross-file and cross-function)	No
Cross-file analysis	Yes (Pro engine)	No - single-file AST analysis only
Code style enforcement	No	Yes - core purpose
Plugin ecosystem	Semgrep Registry (security-focused)	Massive npm ecosystem (2,900+ packages)
IaC scanning	Yes (Terraform, K8s, Docker, CloudFormation)	No
SCA / dependency scanning	Yes (Semgrep Supply Chain with reachability)	No
Secrets detection	Yes (Semgrep Secrets with validation)	No
Configuration	YAML rule files, semgrep.yml	eslint.config.js (flat config)
Scan speed (CI)	10-30 seconds (median 10s)	5-30 seconds
Pricing	Free OSS CLI; Team $35/contributor/month (free for 10)	Completely free and open source

What Is Semgrep?

Semgrep is a lightweight, programmable static analysis engine built for application security. Created by Semgrep, Inc. (formerly Return To Corp), it scans source code for patterns that match security rules you define or pull from a registry of over 20,000 Pro rules and 2,800+ community rules. The core engine is open source under the LGPL-2.1 license, runs as a single binary with no external dependencies, and completes scans in seconds rather than minutes.

Semgrep’s defining characteristic is its approach to rule authoring. Rules are written in YAML using patterns that mirror the syntax of the target language, making them readable by any developer - not just security specialists. A rule to detect SQL injection via string concatenation in JavaScript looks like this:

rules:
  - id: express-sql-injection
    patterns:
      - pattern: |
          $DB.query("..." + $INPUT + "...")
    message: >
      SQL query built with string concatenation.
      Use parameterized queries instead.
    severity: ERROR
    languages: [javascript, typescript]

Any JavaScript developer can read this rule and understand exactly what it detects. Writing, testing, and deploying a new Semgrep rule to CI takes under an hour. This accessibility is what separates Semgrep from traditional SAST tools that require specialized security engineering knowledge to configure.

The Semgrep engine operates in three tiers. The Community Edition (OSS) provides single-file, single-function analysis with 2,800+ community rules - free forever. The Pro Engine adds cross-file and cross-function dataflow analysis, tracing tainted data from sources (like HTTP request parameters) to sinks (like database queries) across entire codebases. Independent testing found that the Pro engine detected 72-75% of vulnerabilities in test suites compared to 44-48% for the Community Edition. The Semgrep AppSec Platform wraps the engine with AI-powered triage (Semgrep Assistant), managed dashboards, and three product modules - Semgrep Code (SAST), Semgrep Supply Chain (SCA with reachability analysis), and Semgrep Secrets (credential detection with validation).

For JavaScript and TypeScript specifically, Semgrep’s rule registry includes hundreds of rules covering Express.js, React, Next.js, Node.js core APIs, and common npm packages. These rules detect authentication bypasses, injection vulnerabilities, insecure cookie configurations, prototype pollution, and dozens of other JavaScript-specific security patterns. For a detailed breakdown of Semgrep’s capabilities, see our Semgrep review. For pricing details, see our Semgrep pricing guide.

What Is ESLint?

ESLint is the de facto standard linter for JavaScript and TypeScript, originally created by Nicholas Zakas in 2013 and now maintained by the OpenJS Foundation. It analyzes source code to find problematic patterns, enforce coding conventions, and catch potential bugs before runtime. ESLint is installed on over 30 million VS Code instances and is used by virtually every professional JavaScript project.

ESLint runs locally - in the developer’s editor as a real-time extension, as a CLI command during development, in pre-commit hooks via tools like Husky and lint-staged, and optionally in CI/CD pipelines. The key distinction is that ESLint provides immediate, in-editor feedback. When a developer writes if (x = 5) instead of if (x === 5), ESLint highlights the issue instantly with a red underline and an explanation. This tight feedback loop is ESLint’s core value proposition - catching issues at the moment they are written, not minutes or hours later in a CI pipeline.

ESLint’s rule system is infinitely extensible. The core package includes approximately 300 rules covering potential errors, best practices, variable handling, and stylistic conventions. The ecosystem expands this dramatically through community plugins. Popular plugins include @typescript-eslint (TypeScript-specific rules), eslint-plugin-react (React best practices), eslint-plugin-vue (Vue.js rules), eslint-plugin-import (module import/export conventions), eslint-plugin-jsx-a11y (accessibility rules), eslint-plugin-security (basic security patterns), and eslint-plugin-prettier (Prettier integration). Teams can also write entirely custom rules in JavaScript by traversing the AST, making ESLint adaptable to any coding standard.

In 2024, ESLint completed its migration to the “flat config” system (eslint.config.js), replacing the legacy .eslintrc format. ESLint 9.x dropped support for the legacy format entirely. The flat config simplifies configuration, makes rule resolution more predictable, and is now the default for all new projects.

ESLint does have security-related plugins - most notably eslint-plugin-security and eslint-plugin-no-unsanitized - but these catch only surface-level patterns within individual files. They cannot trace data flow across files, perform taint analysis, or detect the kind of multi-file injection vulnerabilities that dedicated SAST tools find. This is a fundamental limitation of single-file, AST-based analysis, not a criticism of ESLint itself. ESLint was never designed to be a security scanner.

Feature Breakdown

Purpose and Scope

This is the most fundamental difference between the two tools, and understanding it is critical to using each one effectively.

ESLint is a code quality tool. Its purpose is enforcing coding conventions, catching common bugs, and maintaining consistent code style across a team. ESLint answers questions like: “Is this variable declared but never used?”, “Does this function have too many parameters?”, “Are imports ordered correctly?”, “Is this any type suppressing a TypeScript error that should be fixed?” These are code health questions - important for maintainability, readability, and developer productivity, but not security questions.

Semgrep is a code security tool. Its purpose is finding exploitable vulnerabilities before they reach production. Semgrep answers questions like: “Does user input from this Express route handler reach a SQL query without sanitization?”, “Is this JWT verification using an insecure algorithm?”, “Are there hardcoded API keys in this codebase?”, “Is this React component rendering unsanitized HTML?” These are security questions - important for preventing data breaches, unauthorized access, and exploitation.

The scope difference extends to language coverage. ESLint analyzes JavaScript and TypeScript exclusively (with framework support through plugins for React, Vue, Svelte, and others). Semgrep analyzes 30+ programming languages - JavaScript and TypeScript alongside Python, Java, Go, Ruby, Rust, C, C++, C#, Kotlin, PHP, and many more. For teams working in polyglot stacks, Semgrep provides consistent security scanning across the entire codebase while ESLint covers only the JavaScript portion.

Semgrep also extends beyond application code into infrastructure-as-code. It natively scans Terraform configurations, Kubernetes manifests, CloudFormation templates, and Dockerfiles for security misconfigurations - detecting issues like overly permissive IAM policies, containers running as root, and unencrypted storage buckets. ESLint has no awareness of infrastructure concerns.

Rule Syntax and Custom Rules

ESLint rules are JavaScript programs. Each rule is a module that exports a create function returning an object with visitor methods. When ESLint parses a file, it walks the AST and calls the appropriate visitor for each node type. Here is a simplified custom ESLint rule that detects direct use of innerHTML:

module.exports = {
  meta: {
    type: "suggestion",
    docs: {
      description: "Disallow innerHTML assignment"
    }
  },
  create(context) {
    return {
      AssignmentExpression(node) {
        if (
          node.left.property &&
          node.left.property.name === "innerHTML"
        ) {
          context.report({
            node,
            message: "Avoid innerHTML. Use textContent or a sanitization library."
          });
        }
      }
    };
  }
};

This rule requires JavaScript knowledge, familiarity with AST node types, and understanding of ESLint’s rule API. The learning curve for writing custom ESLint rules is moderate - most experienced JavaScript developers can write basic rules within a few hours but may need days to handle complex patterns involving scope analysis and type inference.

Semgrep rules are declarative YAML patterns. The equivalent Semgrep rule to detect innerHTML assignment looks like this:

rules:
  - id: no-innerhtml
    patterns:
      - pattern: $EL.innerHTML = $VALUE
    message: >
      Avoid innerHTML assignment. Use textContent or a sanitization library.
    severity: WARNING
    languages: [javascript, typescript]

This rule is readable by anyone who writes JavaScript. The pattern $EL.innerHTML = $VALUE mirrors the actual code it detects, with metavariables ($EL, $VALUE) acting as wildcards. No AST knowledge required. No JavaScript programming required. The rule can be extended to include taint tracking, metavariable constraints, and cross-file analysis without changing the fundamental YAML format.

The key difference is that Semgrep’s rule syntax was designed specifically for security patterns - taint sources and sinks, data flow tracking, and cross-language support. ESLint’s rule API was designed for code quality patterns - AST visitors, scope analysis, and fix suggestions. Each rule system excels at its intended purpose.

Security Capabilities

This is where the tools diverge most sharply.

ESLint’s security coverage is minimal and surface-level. The most commonly used security plugin, eslint-plugin-security, includes approximately 15 rules that detect patterns like:

• eval() usage
• child_process.exec() with non-literal arguments
• Non-literal require() calls
• innerHTML and outerHTML assignments
• RegExp with non-literal patterns (potential ReDoS)
• Object bracket notation with non-literal keys (potential prototype pollution)

These rules catch the most obvious security mistakes by checking for specific API calls within a single file. They do not and cannot perform data flow analysis. If a developer wraps eval() behind two layers of abstraction - calling a helper function that calls another function that eventually calls eval() - eslint-plugin-security will not trace the input back to its source to determine whether it is user-controlled. This is a fundamental limitation of single-file, AST-based analysis.

Semgrep’s security coverage is deep and purpose-built. The platform provides multiple layers of security scanning:

Taint tracking traces data from untrusted sources (HTTP request parameters, form inputs, environment variables, external APIs) through the application to dangerous sinks (SQL queries, system commands, file operations, HTML rendering). The Pro engine follows data across function calls, module boundaries, and framework-specific patterns (like Express middleware chains). This catches injection vulnerabilities that span multiple files - the kind of security bugs that actually cause data breaches.

Reachability analysis through Semgrep Supply Chain determines whether vulnerable functions in your dependencies are actually called from your code. A CVE in a library function your code never invokes is still worth knowing about, but it is not the same priority as one in a function called on every request. This reduces SCA noise dramatically.

Secrets detection through Semgrep Secrets identifies hardcoded credentials - API keys, database passwords, authentication tokens - and validates whether they are still active. An active AWS key committed to a repository is a critical security incident. An expired test key is noise. Semgrep distinguishes between them.

AI-powered triage through Semgrep Assistant analyzes findings, assesses exploitability, and prioritizes fixes. Instead of presenting a flat list of 200 findings sorted by severity, Assistant groups them by likelihood of real impact and can auto-triage known false positive patterns. Semgrep reports that Assistant reduces false positive noise by 20-40% out of the box.

The contrast is stark. eslint-plugin-security catches eval() calls. Semgrep traces user input from an Express req.body parameter through three middleware functions and a service layer to a database query, determining that unsanitized data reaches a SQL execution sink. These are different orders of magnitude in security analysis depth.

Performance

ESLint and Semgrep operate in fundamentally different performance contexts because they run at different stages of the development workflow.

ESLint is optimized for real-time editor feedback. The VS Code extension runs ESLint incrementally - when you type a character, ESLint re-analyzes the affected portion of the current file and updates diagnostics in milliseconds. There is no perceptible delay between typing and seeing feedback. In CI, ESLint scans an entire project by analyzing each file independently, typically completing in 5-30 seconds depending on codebase size and the number of enabled rules and plugins.

Semgrep is optimized for fast CI/CD scanning. A typical Semgrep scan completes in 10-30 seconds, with a median CI scan time of 10 seconds reported by Semgrep. This speed comes from Semgrep’s pattern-matching engine, which matches YAML rules against parsed source files without building a full semantic model of the program. Diff-aware scanning in CI means Semgrep only analyzes changed files, keeping incremental scans fast regardless of total codebase size. Semgrep’s VS Code extension provides in-editor feedback but triggers on file save rather than on every keystroke, making it noticeably slower than ESLint’s real-time analysis.

Performance comparison in CI:

Codebase size	ESLint	Semgrep
Small (10K LOC)	2-5 seconds	5-10 seconds
Medium (100K LOC)	10-20 seconds	10-30 seconds
Large (1M LOC)	20-60 seconds	30-90 seconds

Both tools are fast enough for CI/CD without creating pipeline bottlenecks. The meaningful performance difference is in the editor - ESLint provides instant feedback as you type, while Semgrep provides feedback on save. For daily development workflow, ESLint’s real-time editor integration is significantly more responsive.

Language Support

ESLint supports JavaScript and TypeScript exclusively. Through plugins, it extends to JSX, TSX, Vue single-file components, Svelte components, and Astro files. ESLint does not analyze Python, Java, Go, or any other language. This focus is a strength for JavaScript teams - ESLint’s JavaScript analysis is unmatched in depth and ecosystem breadth - but it means JavaScript-only security coverage.

Semgrep supports 30+ programming languages. In addition to JavaScript and TypeScript, Semgrep scans Python, Java, Go, Ruby, Rust, C, C++, C#, Kotlin, Swift, PHP, Scala, Lua, Elixir, and many more. It also scans infrastructure-as-code formats - Terraform/HCL, CloudFormation, Kubernetes YAML, and Dockerfiles.

For a full-stack team building an Express.js backend with a React frontend, a Python ML pipeline, and Terraform infrastructure, the coverage picture looks like this:

Language / Format	ESLint	Semgrep
JavaScript / TypeScript	Full linting + quality	Security scanning
React (JSX/TSX)	Full linting + quality (with plugin)	Security scanning
Python	Not supported	Security scanning
Terraform	Not supported	Security scanning
Dockerfiles	Not supported	Security scanning
package.json / lock files	Not supported	SCA with reachability (Supply Chain)

ESLint covers the JavaScript portion deeply. Semgrep covers the entire stack for security. The tools complement each other perfectly in polyglot environments.

Plugin Ecosystem

ESLint’s plugin ecosystem is massive and unmatched. With over 2,900 ESLint-related npm packages, there is a plugin for almost every framework, library, and coding convention imaginable. Key plugins include:

• @typescript-eslint - TypeScript-specific rules and parser
• eslint-plugin-react and eslint-plugin-react-hooks - React best practices
• eslint-plugin-vue - Vue.js rules
• eslint-plugin-import - Module import/export conventions
• eslint-plugin-jsx-a11y - Accessibility rules for JSX
• eslint-plugin-prettier - Prettier integration
• eslint-plugin-jest and eslint-plugin-vitest - Testing library rules
• eslint-plugin-next - Next.js specific rules
• eslint-plugin-security - Basic security patterns

Teams can adopt shared configurations like eslint-config-airbnb, @antfu/eslint-config, or eslint-config-standard to get a comprehensive rule set with a single install. The ecosystem’s breadth is ESLint’s strongest competitive advantage - no other JavaScript tool offers this level of framework-specific linting coverage.

Semgrep’s rule ecosystem is security-focused. The Semgrep Registry contains 20,000+ Pro rules and 2,800+ community rules. Rules are organized by language, framework, and vulnerability category (OWASP Top 10, CWE). Framework-specific rules cover Express.js, Django, Flask, Spring Boot, Rails, React, Next.js, and many more. The registry includes rules from the Semgrep team, community contributors, and partner organizations.

The ecosystems do not overlap. ESLint plugins focus on code quality, style, framework conventions, and developer productivity. Semgrep rules focus on security vulnerabilities, secrets detection, and infrastructure misconfigurations. You cannot use ESLint plugins in Semgrep or Semgrep rules in ESLint. This is precisely why using both tools provides the broadest coverage.

IDE Integration

ESLint’s IDE integration is the gold standard for JavaScript development. The ESLint VS Code extension runs rules in real time as you type, highlighting issues with red and yellow underlines, providing fix suggestions through the quick-fix menu, and optionally auto-fixing issues on save. The experience is instantaneous - zero delay between writing code and seeing feedback. Extensions are also available for JetBrains IDEs (WebStorm, IntelliJ), Vim/Neovim, Sublime Text, and virtually every other editor. For most JavaScript developers, ESLint’s editor integration is the primary way they interact with the tool.

Semgrep’s IDE integration is functional but secondary. Semgrep offers a VS Code extension built on the Language Server Protocol (LSP). It runs Semgrep scans when files are saved and displays findings as diagnostics in the editor. However, the experience is not as seamless as ESLint’s. Scans trigger on save rather than on every keystroke, there is a brief delay while the scan completes, and the extension is more resource-intensive than ESLint’s lightweight integration.

For most teams, the recommended workflow is running ESLint in the editor for real-time feedback and running Semgrep in CI/CD for security scanning. Developers who want Semgrep findings in their IDE can install the VS Code extension as a supplementary tool, but it should not replace ESLint’s editor experience. SonarLint (SonarQube’s IDE plugin) follows a similar pattern - it supplements rather than replaces ESLint in the editor. For more on this complementary approach, see our SonarQube vs ESLint comparison.

Pricing

ESLint Pricing

ESLint is completely free. There is no paid tier, no enterprise edition, no per-user or per-repo licensing. The core package, all official plugins, the VS Code extension, and the flat config system are free and open source under the MIT license. The total cost of ESLint is zero dollars, forever, regardless of team size or codebase scale.

Semgrep Pricing

Tier	Price	What You Get
Community Edition (OSS)	Free	Open-source engine, 2,800+ community rules, single-file analysis, CLI and CI/CD
Team	$35/contributor/month (free for first 10 contributors)	Cross-file analysis, 20,000+ Pro rules, Semgrep Assistant (AI triage), Semgrep Supply Chain (SCA), Semgrep Secrets, dashboard
Enterprise	Custom pricing	Everything in Team plus SSO/SAML, custom deployment, advanced reporting, dedicated support

For a detailed pricing breakdown with cost scenarios, see our Semgrep pricing guide.

Cost Comparison for JavaScript Teams

The cost equation for JavaScript teams is straightforward:

• ESLint: $0/year. Always.
• Semgrep Community Edition (OSS CLI): $0/year. Run it in CI with custom rules and community rules at no cost.
• Semgrep Team (up to 10 contributors): $0/year. Full platform with cross-file analysis, AI triage, and 20,000+ Pro rules.
• Semgrep Team (25 contributors): $6,300/year (15 paid contributors at $35/month).
• Semgrep Team (50 contributors): $16,800/year (40 paid contributors at $35/month).

The decision is not ESLint or Semgrep from a cost perspective. ESLint is free, so you always use it. The question is whether to add Semgrep for security scanning, and whether the security coverage justifies the cost. For teams with 10 or fewer contributors, the answer is easy - the full Semgrep platform is free. For larger teams, the open-source CLI is free and covers the most common security patterns. The paid Team tier adds cross-file analysis and AI triage that significantly improve detection quality.

Do You Need Both Semgrep and ESLint?

For most professional JavaScript and TypeScript teams, yes - you should use both. The tools are not redundant. They operate at different layers of the development workflow and catch entirely different categories of issues.

ESLint provides the fast feedback loop for code quality. Issues appear in the editor as you type. Fix them before you even save the file. This immediate feedback is the most effective way to prevent code style violations, common bugs, and convention deviations from ever entering the codebase. No CI pipeline, no delay, no security scanner needed for this purpose.

Semgrep provides the security scanning layer. Cross-file taint analysis, injection vulnerability detection, secrets scanning, and dependency vulnerability assessment happen during the CI/CD pipeline. These capabilities require security-specific analysis that ESLint’s code quality rules cannot provide. Running Semgrep on every pull request takes 10-30 seconds and catches the security issues that could lead to data breaches.

The workflow looks like this:

1. Developer writes code. ESLint highlights style issues, potential bugs, and convention violations in real time.
2. Developer commits code. Pre-commit hook runs ESLint (via lint-staged) and blocks commits with linting errors.
3. Developer pushes code. CI pipeline runs Semgrep security scan.
4. Semgrep posts findings to the pull request as inline comments. If critical security issues are found, the PR is flagged.
5. Developer fixes security issues, pushes again. Scan passes. PR is reviewed and merged.

This layered approach catches code quality issues at the earliest stage (editor) and security issues at the CI stage. ESLint never catches a SQL injection vulnerability. Semgrep never complains about inconsistent semicolons. Each tool does exactly what it was designed to do, at the stage where it provides the most value.

When ESLint Alone Might Be Sufficient

If your JavaScript project does not handle sensitive user data, does not process authentication credentials, does not interact with databases, and has no attack surface - a purely static marketing site, an internal tool behind a VPN, or a design system component library - ESLint with eslint-plugin-security may be sufficient for your minimal security needs. But the moment your application handles user input, makes database queries, or stores sensitive data, you need more than ESLint can provide.

When to Skip ESLint and Use Only Semgrep

Almost never. ESLint is free, takes minutes to configure, and provides real-time editor feedback that no security scanner can match. Even if your primary concern is security, ESLint’s code quality enforcement prevents the kind of sloppy code that often introduces security vulnerabilities in the first place. The only scenario where skipping ESLint makes sense is if you are scanning a non-JavaScript codebase - in which case ESLint is not an option and Semgrep (or SonarQube) stands alone.

Use Cases

JavaScript/TypeScript Web Applications

For teams building web applications with Express, Next.js, React, or similar frameworks, the recommended stack is:

• ESLint with @typescript-eslint, eslint-plugin-react, and eslint-plugin-import for code quality
• Prettier for code formatting (integrated via eslint-config-prettier)
• Semgrep with JavaScript/TypeScript security rules and Express/React/Next.js framework-specific rules for SAST
• Semgrep Supply Chain for dependency vulnerability scanning with reachability analysis

This combination provides real-time code quality feedback, consistent formatting, security scanning on every PR, and awareness of vulnerable dependencies. Total cost for a team of 10 or fewer: $0.

Node.js API Services

For teams building backend API services that handle sensitive data:

• ESLint for code quality (essential baseline)
• Semgrep with taint tracking enabled for detecting injection vulnerabilities that span middleware, services, and data access layers
• Semgrep Secrets for detecting hardcoded database credentials, API keys, and authentication tokens

The taint tracking capability is especially valuable for API services. A common vulnerability pattern is user input flowing from req.body through validation middleware (that does not actually validate), through a service function, to a database query that concatenates the input into SQL. ESLint cannot trace this flow. Semgrep can - across files and function boundaries.

Full-Stack Polyglot Projects

For teams with JavaScript/TypeScript alongside Python, Go, Java, or other languages:

• ESLint for JavaScript/TypeScript code quality
• Language-specific linters for other languages (Ruff for Python, golangci-lint for Go, etc.)
• Semgrep as the unified security scanner across all languages

Semgrep’s value increases in polyglot environments because it provides consistent security scanning across the entire stack. Rather than configuring and maintaining separate security tools for each language, Semgrep covers everything with a single rule set and a single CI pipeline step.

Alternatives to Consider

If you are evaluating tools to pair with ESLint for security and code quality coverage beyond what eslint-plugin-security provides, several alternatives to Semgrep are worth considering.

SonarQube is the most direct alternative if you want code quality and security in a single platform. SonarQube provides 6,000+ built-in rules, quality gate enforcement, technical debt tracking, code coverage integration, and duplication detection alongside security vulnerability scanning. For teams that want comprehensive code health management rather than focused security scanning, SonarQube is the better choice. The Community Build is free and self-hosted. However, SonarQube’s custom rule authoring is significantly more complex than Semgrep’s, scan times are longer (2-10 minutes), and it requires server infrastructure. See our SonarQube vs ESLint comparison and Semgrep vs SonarQube comparison for detailed breakdowns.

Snyk Code provides developer-first security scanning with strong IDE integration across VS Code, JetBrains, Eclipse, and Visual Studio. Snyk’s platform also includes SCA (dependency vulnerability scanning), container security, and infrastructure-as-code scanning. If you want a single vendor covering SAST, SCA, and container security with an emphasis on developer experience, Snyk is worth evaluating. See our Snyk vs Semgrep comparison for details.

Codacy is a cloud-native code quality and security platform that embeds ESLint as one of its analysis engines for JavaScript. This means you get ESLint analysis plus additional security and quality coverage without running ESLint separately. Codacy adds SAST, SCA, secrets detection, coverage tracking, and AI-powered review at $15/user/month. For teams that want a single platform with minimal setup, Codacy is worth considering.

DeepSource offers 5,000+ analysis rules with an emphasis on low false positive rates and AI-powered auto-fix capabilities. At $12/user/month, it is priced below both Codacy and SonarQube’s paid tiers. DeepSource supports JavaScript, TypeScript, Python, Go, Java, Ruby, and other languages. Its PR report cards provide multi-dimensional quality assessment covering bugs, anti-patterns, performance, security, and style.

For a broader view of tools in this space, see our best SAST tools roundup, our Semgrep alternatives guide, and our best code review tools for JavaScript roundup.

Final Recommendation

The Semgrep vs ESLint question almost always has the same answer: use both, because they do different things.

ESLint is the non-negotiable foundation for any JavaScript or TypeScript project. It is free, universal, instantly integrated into every editor, and catches the vast majority of code style and convention issues at the earliest possible point - while you are writing the code. ESLint plus Prettier plus a good shared configuration gives you a solid code quality baseline that costs nothing and takes minutes to set up. No JavaScript team should ship code without ESLint.

Semgrep is the recommended addition for security-conscious teams. If your application handles user input, stores sensitive data, makes database queries, or is accessible from the internet - you need security scanning beyond what eslint-plugin-security can provide. Semgrep’s taint tracking, cross-file analysis, secrets detection, and supply chain scanning catch the vulnerabilities that linting fundamentally cannot detect. The open-source CLI is free for unlimited use. The full platform is free for up to 10 contributors. Adding Semgrep to your CI pipeline takes minutes and scans in seconds.

For JavaScript/TypeScript teams under 10 developers: ESLint + Prettier in the editor. Semgrep Team (free) in CI/CD. Total cost: $0. Total setup time: under 30 minutes.

For JavaScript/TypeScript teams of 10-50 developers: ESLint + Prettier in the editor. Semgrep (OSS CLI or Team tier) in CI/CD. Add SonarQube if you need quality gates and technical debt tracking. Consider Snyk for comprehensive dependency scanning.

For security-sensitive applications of any size: ESLint + Prettier for code quality. Semgrep Team for SAST with taint tracking. Semgrep Supply Chain for SCA with reachability. Semgrep Secrets for credential detection. This gives you the most comprehensive security coverage available for a JavaScript application at a fraction of the cost of enterprise SAST tools like Checkmarx or Veracode.

For enterprise engineering organizations: ESLint + Prettier for JavaScript/TypeScript code quality. Semgrep or SonarQube (or both) for security and quality analysis. See our best code review tools for JavaScript guide for a comprehensive toolchain recommendation.

The tools are not competitors. ESLint is your code quality layer. Semgrep is your security layer. Your JavaScript application needs both.