Semgrep Explained: Rules That Look Like Code, semgrep scan vs semgrep ci, and the Opengrep Fork

Semgrep is the static analysis tool security engineers reach for when they want to write their own check in minutes. Its rules look like the code they match, which makes it a favourite for variant hunting after a bug is found, and a common topic in AppSec interviews: "a bug was found in one service; how do you find every copy of it?"

What it is

Semgrep comes in two forms:

• Semgrep Community Edition (CE) is the open-source engine, licensed LGPL-2.1. It was called Semgrep OSS until December 2024.
• The Semgrep AppSec Platform is the commercial product: Semgrep Code (with cross-file analysis and Pro rules), Semgrep Supply Chain (dependency scanning with reachability), Semgrep Secrets, and AI-assisted triage.

In December 2024 Semgrep moved the rules it maintains to a more restrictive licence and moved some engine features behind a login. In January 2025 a group of vendors forked CE at version 1.100.0 as Opengrep, which keeps the LGPL licence and rule compatibility but publishes no rules of its own.

How it works

Semgrep parses each file into a syntax tree and matches patterns written in the target language, with metavariables such as $X standing for any expression and ... standing for any sequence. Rules are YAML files that combine patterns (pattern, pattern-either, pattern-not, pattern-inside) and can declare taint rules with sources, sinks and sanitisers. Community Edition analyses one file at a time; the paid engine adds cross-file analysis, though the documentation notes that cross-file analysis does not run on diff-aware pull request scans.

How to use it

Day one: run it with no account

semgrep scan --config auto              # rules chosen for the detected languages
semgrep scan --config p/default --error # exit code 1 if anything is found
semgrep scan --config rules/ --sarif --sarif-output=semgrep.sarif

Without --error, semgrep scan reports findings but exits 0, which is a common reason a "security gate" never blocks anything.

Week one: write your own rule

The best use of Semgrep is turning a real bug into a rule. Suppose a review found shell commands built from request data in one service. A rule like this finds every other copy:

rules:
  - id: subprocess-shell-true-with-variable
    languages: [python]
    severity: ERROR
    message: "Command built from a variable and run with shell=True"
    patterns:
      - pattern: subprocess.$FUNC($CMD, ..., shell=True, ...)
      - pattern-not: subprocess.$FUNC("...", ..., shell=True, ...)

Test it against known-good and known-bad examples in the repository, then add it to the shared ruleset so the bug class cannot return.

Every day: gate pull requests and manage exceptions

With the platform, semgrep ci runs in the pipeline with a SEMGREP_APP_TOKEN, scans only what changed on pull requests and fails on findings from rules set to block. Suppress a reviewed false positive with an inline # nosemgrep: rule-id comment (on the platform this becomes an Ignored finding, and only if the organisation allows inline suppressions), and exclude paths with a .semgrepignore file. By default Semgrep skips folders such as node_modules/ and vendor/ and files over 1 MB, so check that generated or bundled code you care about is actually scanned.

Where it stops

• Single-file in CE. Data flowing through helper functions in other files is invisible to the open-source engine.
• Rules find what you describe. A clean scan means no rule matched, not that the code is secure.
• Licensing matters for vendors. Using Semgrep-maintained rules inside a competing product or SaaS is not allowed under the Rules License; check before building on them.
• Large and generated files are skipped by default.

How it comes up in interviews

• "You found an injection bug in one service. How do you find its variants across 400 repositories?" Write a rule, test it, run it everywhere, then gate on it.
• "Why do SAST tools produce so many false positives, and how do you get developers to trust one?" Talk about rule precision, taint versus pattern rules, blocking only high-confidence rules, and fast suppression with review.
• "What changed with Semgrep's licence, and why did Opengrep fork?" A good test of whether you follow the tooling ecosystem.

Sources

Checked on 13 November 2026: Semgrep CLI reference (semgrep scan, semgrep ci, exit codes); Semgrep documentation on ignoring files and code, sample CI configurations, and Semgrep Pro versus Community Edition; Semgrep blog "Important updates to Semgrep OSS" (13 December 2024); Semgrep's Opengrep comparison page; Opengrep GitHub README.