# Opengrep: the LGPL Semgrep fork and what it changes for rule-based SAST

> Opengrep is a fork of Semgrep under LGPL 2.1, created after Semgrep moved features behind a commercial licence. It keeps Semgrep rule compatibility, adds taint analysis work and languages such as Visual Basic and Apex, and ships self-contained signed binaries.

**opengrep/opengrep** — 🔎 Static code analysis engine to find security issues in code.

- Repository: https://github.com/opengrep/opengrep
- Stars: 3,128 · Forks: 269
- Language: OCaml
- License: LGPL-2.1
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/opengrep-opengrep

## What Opengrep solves, and for whom

Opengrep is a static analysis engine that searches source code for patterns and reports matches as findings. The README states the project exists because Semgrep moved critical features behind a commercial licence, and that Opengrep was created so advanced static analysis stays open. That origin story defines the audience: teams that already write Semgrep rules, or already run Semgrep rule sets, and want to keep executing them without depending on a vendor's licence tier.

The compatibility claim is the practical one. The README says existing rules and rulesets work unchanged, and the getting started example uses the same rule schema Semgrep users know: a rule has an id, a pattern, a message, a list of languages and a severity. If that claim holds for your rule set, migration is a binary swap rather than a rewrite. If it does not, you find out quickly, because a rule that fails to parse fails at scan time.

The second audience is teams that need a language Semgrep CE does not cover. The README lists Visual Basic as unavailable in both Semgrep CE and Semgrep Pro, and Apex and Elixir as absent from Semgrep CE. Codebases with Salesforce Apex or Elixir services have a concrete reason to look here rather than at the engine it forked from.

What Opengrep is not: it is not a hosted platform. The README describes a CLI, a rule format, JSON and SARIF output, and a release page of binaries. There is no dashboard in the README, no account, no rule feed described as managed.

## How the engine runs a rule against a file

The flow visible in the README is short. You point the scanner at a directory of rules with -f and at a target path. The engine parses the target files according to the languages declared in the rules, matches the pattern against the parsed structure, and prints findings with file, line and the rule's message. In the documented example, one rule runs on one file and produces one finding.

The matching is semantic rather than textual. The example rule pattern is $VAR.unwrap(), where $VAR is a metavariable that binds to whatever expression precedes the call. That is why the finding lands on divide(10, 0).unwrap() and not on a string search for the literal text unwrap. The README calls this semantic grep, and the metavariable is the mechanism.

The repository is written in OCaml and builds through dune and opam; the Makefile states that OCaml 5.5.0, dune and opam are required for development, along with C tooling such as gcc, ld, pkgconfig and libraries including PCRE and gmp. That is the build path for contributors. Users do not need it, because the README says distribution is through self-contained binaries compiled from OCaml.

Taint analysis is the area the README highlights most. Opengrep documents a --taint-intrafile mode with constructor and field assignment tracking, inter-method taint flow, higher-order function support across 12 languages, and collection method tainting for map, filter and reduce. Those are claims about the analysis, not about the CLI surface; the README points to two wiki tutorials for detail rather than reproducing the semantics.

## Installing Opengrep and running a first scan

The README recommends the install script. On Linux and macOS it is fetched and piped to bash:

```bash
curl -fsSL https://raw.githubusercontent.com/opengrep/opengrep/main/install.sh | bash
```

The same script can be run from a clone with ./install.sh. On Windows the README gives a PowerShell equivalent, irm ... | iex, and shows that a specific version can be pinned by passing -Version, with v1.16.0 as the example value. The README also notes that the Windows package contains opengrep.exe and the DLLs it needs, and that they must stay together in the installation directory. If you would rather not run a remote script, binaries are on the releases page.

For a first scan, the README's example uses two files. The rule goes in rules/demo-rust-unwrap.yaml:

```yaml
rules:
- id: unwrapped-result
  pattern: $VAR.unwrap()
  message: "Unwrap detected - potential panic risk"
  languages: [rust]
  severity: WARNING
```

The target goes in code/rust/main.rs and contains a call to .unwrap() on a Result. Then you run the scan:

```bash
opengrep scan -f rules code/rust
```

The README shows the expected output: a banner, a progress bar, one code finding under code/rust/main.rs attributed to rules.unwrapped-result with the message and the matching line, and a summary reading "Ran 1 rule on 1 file: 1 finding." One detail in that output is easy to miss: the scanner reports it is scanning files that are git-tracked, so an untracked file may not appear in results.

For machine consumption the README uses SARIF:

```bash
opengrep scan --sarif-output=sarif.json -f rules code
```

The resulting file declares SARIF version 2.1.0 and carries a runs array with results, each holding a ruleId, a message, a location with start and end line and column, and a fingerprints object. The tool driver name in the sample output is "Opengrep OSS". That fingerprint field is what lets a code scanning system track a finding across commits instead of re-reporting it as new.

## Where Opengrep is the wrong tool

Opengrep only sees files it is given, and the documented default is git-tracked files. Generated code, vendored dependencies checked in outside git, or build artifacts are outside that set unless you widen the invocation. A finding count from a default scan is therefore a statement about tracked source, not about everything that ships.

Pattern-based analysis also has a ceiling. A rule that matches $VAR.unwrap() flags every unwrap, including ones on values that cannot fail. The engine has no way to know your invariants unless you encode them in the rule. On a large codebase this produces the familiar SAST outcome: a long findings list that a human must triage, and the README offers no baseline, suppression or triage workflow. The .semgrepignore file at the repository root suggests an ignore mechanism exists, but the README does not document its syntax or behaviour, so treat it as something to verify in the docs directory rather than assume.

The taint improvements are scoped. The README describes --taint-intrafile, and the name says intrafile: cross-file flows are not what that flag covers, and a separate alpha release in the release list carries the string nopython-interfile, which signals that interfile work is still in flux. If your threat model is a source in one service reaching a sink in another, a single-file taint mode will not answer it.

Finally, this is a fork, and forks carry a maintenance question. The last push to the default branch was on 2026-09-23, one day before this writing, and the release list shows a 1.30.x line alongside 2.0.0 alpha builds. That is a fast-moving project. Fast-moving also means rule behaviour and flags can shift between minor versions, so pinning matters more here than in a tool that changes yearly.

## Opengrep against Semgrep, SonarQube and Trivy

The comparison that matters most is with Semgrep, because Opengrep is a fork of it. The difference is governance and licence, not the rule language. The README states Opengrep is under LGPL 2.1, that it was created when Semgrep moved critical features behind a commercial licence, and that it is backed by a consortium of AppSec organisations including Aikido, Amplify, Endor Labs, Kodem and Orca Security. In practice, a rule set written for Semgrep should run on Opengrep, and the reverse compatibility is not something the README claims. If your organisation has a Semgrep licence and depends on the vendor's managed rules or platform features, Opengrep does not replace those; it replaces the open engine.

SonarQube is a different shape of tool. It is a platform with a server, a database and a web UI, and its analysis is built around its own rule catalogue and quality gates rather than a user-authored pattern language. Choosing between them is choosing between writing your own rules as YAML and adopting someone else's curated set with a dashboard attached. Opengrep's README describes a CLI and SARIF output, which means any UI is something you supply through a code scanning system that consumes SARIF.

Trivy sits at a different layer. It is known for scanning container images, filesystems and dependencies for known vulnerabilities, which is a data-driven match against advisory databases. Opengrep reads your source and matches structural patterns, so it can catch a missing authorisation check that no CVE describes. The two are complementary rather than competing: dependency and image scanning on one side, source-level pattern and taint analysis on the other. Running Opengrep does not remove the need to scan what you deploy, and scanning what you deploy does not tell you whether the code checks permissions.

On language coverage, the README lists more than 30 languages, including Apex, Elixir, Visual Basic, Solidity, Terraform, Dockerfile and a generic mode for ERB and Jinja templates. That breadth is the strongest argument for a polyglot repository, and the README explicitly positions Visual Basic, Apex and Elixir as gaps in Semgrep CE.

## Licence, releases and the cost of staying current

Opengrep is licensed under LGPL 2.1, and the README frames that as a long-term commitment to open source. LGPL is a copyleft licence with a linking exception aimed at libraries. What that means for your organisation depends on whether you ship Opengrep itself, link against it, or merely run the CLI in CI, and the repository carries a COPYRIGHT file alongside the LICENSE. This is not legal advice; if you redistribute a modified engine, get your own reading of the licence text.

The practical upgrade cost is the release cadence. The release list contains v1.30.0 from 2026-09-07, a v1.30.1 release candidate from 2026-09-21, and a v2.0.0 alpha line from 2026-09-11. A release candidate and an alpha in the same month as a stable release means three moving targets. Pinning is available: the Windows install example passes -Version v1.16.0, and the same pinning is the obvious approach on Linux and macOS even though the README's quick install does not show it. If you do not pin, a CI job that pulls the latest binary can change its rule behaviour without a commit in your repository.

Building from source is the other cost, and it is real. The Makefile documents a development environment of OCaml 5.5.0, dune, opam, gcc, ld, pkgconfig, PCRE and gmp, with make install-deps followed by make all. That is a contributor workflow, not a deployment one. Most users should take the binaries and treat the OCaml toolchain as irrelevant.

## Conclusion

Opengrep fits teams that already own Semgrep rule sets and want them executed by an engine licensed under LGPL 2.1, with taint analysis and language coverage the project documents as absent from Semgrep CE. Teams that need a hosted dashboard, a managed rule feed or a single vendor contract should not switch on the strength of the README alone, because the repository documents a CLI and rule format, not a service. Before adopting, install a pinned version, run your existing rules unchanged against one repository, and compare the findings with what your current scanner reports; the rule format is the compatibility claim, so that comparison is the only test that matters.

## FAQ

### What is Opengrep?

Opengrep is a static code analysis engine, described in its README as a fork of Semgrep released under LGPL 2.1. It searches source code for patterns and reports findings, and the README states that existing Semgrep rules and rulesets work unchanged.

### How to install Opengrep?

The README recommends the install script, fetched from the repository and piped to bash on Linux and macOS, or an equivalent PowerShell one-liner on Windows. Binaries are also available on the releases page for a manual install.

### How to use Opengrep?

Write a rule in YAML with an id, a pattern, a message, a languages list and a severity, then run opengrep scan -f rules followed by the target path. The README's example runs one rule on one Rust file and reports one finding, and --sarif-output writes results in SARIF 2.1.0.

### Does Opengrep work with VS Code?

The README does not document a VS Code extension. It describes a CLI, a rule format, JSON and SARIF output, so editor integration would have to come from a tool that consumes SARIF rather than from Opengrep itself.

### How does Opengrep compare with Snyk?

The README does not mention Snyk. What it does describe is a local CLI that matches structural patterns in source code and writes JSON or SARIF, which is a different shape of product from a hosted scanning service.

### What are the alternatives to Opengrep?

The most direct alternative is Semgrep, since Opengrep is a fork of it created after Semgrep moved critical features behind a commercial licence. SonarQube and Trivy sit at different layers: a platform with its own rule catalogue, and a scanner for images and dependencies.

## Sources

- [Issues](https://github.com/opengrep/opengrep/issues)
- [License: LGPL-2.1](https://github.com/opengrep/opengrep/blob/main/LICENSE)
- [opengrep/opengrep on GitHub](https://github.com/opengrep/opengrep)
- [README](https://github.com/opengrep/opengrep/blob/main/README.md)
- [Releases](https://github.com/opengrep/opengrep/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/opengrep-opengrep