Semgrep

Semgrep is the code scanner I actually keep installed. It started as a pattern-matching static analysis engine — write rules that look like source code, match them against source code — and grew into a full AppSec platform spanning SAST, software composition analysis (SCA) for dependencies, and secrets detection, with an AI layer for triage and autofix. The engine is open source (LGPL-2.1, roughly 17,200 stars on GitHub as of late October 2026, still committing daily), and that open core is why it got into so many CI pipelines before the commercial platform existed. It is one of the few developer security tools where the free tier is genuinely usable rather than a funnel.

What it actually does

At the base is the scanner. Semgrep rules are written in a syntax that mirrors the code you are hunting — a pattern like subprocess.call(..., shell=True) matches literally what it looks like — and the engine applies them across a codebase with metavariables, operators, and taint-mode dataflow. The registry ships community rules plus paid "Pro rules" (170-plus for major languages) that add cross-file dataflow analysis, framework-specific control-flow reasoning, reachability analysis for dependency findings, open-source license detection, and malicious-package detection. Language support is broad — 30-plus languages, with Python, JavaScript/TypeScript, Java, Go and others at generally-available maturity and cross-file analysis on the leading languages; the docs' support matrix is refreshingly honest about which capabilities exist per language.

Around the engine sits the Semgrep AppSec Platform: CI integration (one-click deploy on Semgrep's own infrastructure or self-managed), pull-request comments, IDE plugins for VS Code and JetBrains, Slack and email alerting, monorepo support, SSO, and Semgrep Multimodal — the AI layer that does autofix suggestions, triage, and remediation guidance, metered as AI credits (20 per developer per month on Team plans, 50 on Enterprise, with custom model providers on Enterprise only). Supply Chain adds dependency scanning with reachability, and Secrets detects credentials in code and history. These are sold as separate products rather than one bundle.

Pricing at time of writing, from semgrep.dev/pricing: a Free Edition at no charge for up to 10 contributors (10 private repositories max, unlimited public), and Teams starting at $30 per contributor per month for Code (SAST) or Supply Chain (SCA) — with Secrets Detection a separate $15 per contributor per month. Enterprise is custom-priced with unlimited private repos, 500-repo limits on Team, and support tiers. Some third-party trackers quote $35 per contributor; the official pricing page says $30, and I treat the vendor page as authoritative.

My testing notes

This is the tool in this batch I tested most directly, because I could. I installed Semgrep into a clean virtual environment via pip — it pulled version 1.136.0 and ran immediately. I then wrote a small Python file with four planted problems: a subprocess.call(cmd, shell=True) command-injection pattern, pickle.loads on untrusted data, a raw eval, and a SQL query built by string concatenation. First scan with the standard p/python ruleset: 3.75 seconds wall clock including rule download, and exactly one finding — the subprocess shell=True call. Second scan with p/security-audit: three findings — subprocess, pickle, and eval — and still nothing on the SQL concatenation.

Those two runs tell you more about using Semgrep than any feature list. Rule-pack choice dominates recall: the default pack is tuned for precision and missed three of my four planted issues, while the audit pack caught three of four and would produce more noise in a real codebase. The SQL injection pattern lives in other packs (framework-specific or taint-mode rules) and would likely fire in a Django or SQLAlchemy-aware configuration. This is not a flaw in Semgrep — it is the fundamental trade-off of configurable static analysis — but it means "we run Semgrep" and "we find our vulnerabilities" are different claims, and the gap between them is your ruleset engineering.

The third observation is infrastructure-shaped: every scan reached out to the Semgrep registry to fetch rules. In an air-gapped or egress-restricted CI environment you must vendor rules or run a private registry, which is documented but not automatic. Autofix output is pragmatic — for the subprocess finding it suggested flipping shell=True to False inline in the output — and the finding format (file, rule, severity, remediation link) is the cleanest in the CLI scanner space.

Worth situating against the incumbents, since Semgrep's own site publishes head-to-heads against Snyk, Checkmarx, and GitHub Advanced Security. Those pages are vendor-authored and I read them as such, but the structural difference is real: Snyk leads with dependency scanning and developer UX at a similar per-developer price, Checkmarx sells heavyweight enterprise SAST with far more configuration and far more ceremony, and GitHub Advanced Security bundles scanning into the platform where your code already lives but at a comparable per-active-committer cost and with less rule customisation. Semgrep's angle is the rule language: because a rule looks like code, your own engineers can extend coverage without becoming security-tooling specialists. In my runs I wrote a custom rule against my test file in a few lines and had it matching the same afternoon — that extensibility is the reason security teams with engineering taste pick it.

The registry is the other half of the value. Thousands of community rules ship for free, and the CI checks work out of the box with a sensible default posture. For teams that want someone else to own the rules, the managed platform, Pro rules, and Semgrep's own triage reduce the tuning burden — but note that the pricing turns on contributors, so the bill tracks your engineering headcount rather than your code volume.

Limits

The open-source Community Edition is single-file analysis; cross-file dataflow, the thing that catches real vulnerability chains across modules, is a paid Pro-rules capability. That is the honest line between the free engine and the platform, and teams that stop at CE should know their blind spot. Per-contributor pricing adds up: a 30-person engineering org paying for Code plus Secrets is $45 per contributor per month before Supply Chain, which is real money versus the free engine. The AI features are metered and lightly documented in terms of accuracy; custom model providers are Enterprise-only. Semgrep is static analysis — it sees code, not runtime behaviour, so logic flaws that only manifest in production configuration remain invisible. Secrets detection and SCA being separate SKUs means the "complete" AppSec story is three invoices. And as with every pattern-based scanner, a finding is a hypothesis: my p/security-audit run would flood a large legacy codebase with audit-level noise without a triage process behind it. Finally, the platform's managed-scan mode clones your repository at scan time — the docs state the clone is destroyed afterwards, but security-sensitive teams will want that verified against their own threat model.

Verdict

Semgrep remains the strongest default in developer-first application security scanning: an open-source engine with a real community ruleset, a commercial layer that adds the cross-file analysis serious programs need, and a developer experience — PR comments, IDE plugins, autofix — that gets findings in front of people before merge. Rated 4.1 on the rubric: high core-functionality marks for the engine and rule language (40% weighting), good value because the free tier genuinely works (20%), strong usability (20%), and a mature ecosystem of 17,000-plus stars, a public registry, and active development propping up the reliability score (10% each). The caveats are about scope and pricing, not quality. If you write code for a living, the Community Edition costs you an afternoon. One caveat on my own testing: I exercised the CLI scanner on a small synthetic file, not the hosted platform's dashboard, PR integration, or AI autofix pipeline end to end. Those layers are widely used and well documented, but my direct evidence here is engine-level, and I would want a proof-of-concept on your own repositories before trusting the AI triage to suppress findings. That done, it is the security tool I am most comfortable recommending sight-unseen. That is the review.

Sources

• https://semgrep.dev/pricing
• https://docs.semgrep.dev/supported-languages
• https://docs.semgrep.dev/licensing
• https://github.com/semgrep/semgrep
• https://pypi.org/project/semgrep/
• https://semgrep.dev/products/community-edition
• https://dev.to/rahulxsingh/semgrep-pricing-in-2026-open-source-vs-team-vs-enterprise-costs-3dic
• https://aicodereview.cc/blog/semgrep-pricing
• https://appsecsanta.com/semgrep
• https://semgrep.dev/docs/semgrep-assistant/overview