semgrep-rules: the community rule corpus behind Semgrep CE

The free corpus and the paid one, and what the split costs you

This repository contains the Semgrep Community Edition rules, maintained by Semgrep and the community, and the README is direct that the Semgrep Registry offers proprietary Pro rules in addition to what is here, with additional language coverage, and with cross-file and deep dataflow analysis. That sentence is the most important thing in the document for anyone deciding what to use. A community edition rule matches within a file, essentially a pattern plus some metavariable reasoning, and the deeper analyses the Pro rules add are what let a rule follow a value across a function call, across a file or through a data structure. So the practical consequence is that some vulnerability classes are simply out of reach of the rules in this repository, and a team that believes its scans are comprehensive because it runs the Community Edition rules is mistaken. The README gives you the three entry points for the platform, a registry search to find rules, the AppSec Platform to scan with them, and the contributing guide.

What a rule is made of

The writing section points at two documents, one on pattern syntax and one on rule syntax, and the summary of what they cover is a good description of the model. Pattern syntax describes what Semgrep patterns can do, with worked use cases for the ellipsis operator and for metavariables, which are the named placeholders that let a pattern match a shape rather than a literal. Rule syntax describes the YAML rule files themselves, which can have multiple patterns, detailed output messages and autofixes, and the syntax allows the composition of individual patterns with boolean operators, so a finding can require a pattern and the absence of another one. The output message and autofix fields are what separate a useful rule from a noisy one, since a rule that fires without explaining itself is a rule people learn to ignore, and an autofix turns a scan result into a diff you can apply. There is also an interactive, example based tutorial for people who would rather not start from the reference documentation.

One directory per language, and the directories that hold something else

The repository root is a map of the corpus. There are language directories for bash, C, Clojure, C#, Dockerfile, generic, Go, HTML, Java, JavaScript, JSON, Kotlin, OCaml, PHP, Python, Ruby, Rust, Scala, Solidity, Swift, Terraform, TypeScript and YAML. Then there are three categories that are not languages in that sense, and the Makefile names them, with `apex` and `elixir` as the Pro directories and `ai` and `problem-based-packs` as other directories, the latter holding rule packs organised around a class of problem rather than a language. A few directories are explicitly not rule directories. The Makefile comment says it skips `libsonnet/` and `trusted_python/` because they do not contain rules, and that `stats/` and `scripts/` would otherwise produce errors, along with the GitHub workflow files. There is a `template.yaml` at the root, which is the starting point for a new rule, and a `metadata-schema.yaml.schm` file that describes the schema those metadata files must satisfy.

The test rig, and why the whitelist exists

The Makefile is the part of this repository that makes it a project rather than a folder of YAML, and the comments explain the design. The `test` target runs `validate` and then `test-only`, and the description says that these check rule validity and check that Semgrep finds the expected findings, with a link to the documentation on testing rules, and it notes that the Semgrep repository itself runs those tests as part of its own CI for consistency. Validation is `semgrep validate --pro` over the directory list, and the test run is `semgrep test --pro .`. The `--pro` flag is there because the engine that runs the tests is the commercial one, even for the community rules. The whitelist in the Makefile comes with an honest explanation, since the validate command uses a different targeting than the test command, so the directories of statistics, scripts and workflow files have to be excluded to stop them being reported as errors. There is also a `test-oss-only` target that loops over the directories running the plain `semgrep test` per directory, and the `SEMGREP` variable can be pointed at a non standard command, which is what you want when you are testing a build of the engine itself.

Contributing means granting a redistribution licence

The contribution section contains the clause that makes this repository different from a normal open source project. The README says contributions are welcome directly to the repository, and that when you submit a contribution you grant Semgrep, Inc. a licence to use, modify and distribute your contribution under the Semgrep Rules License version 1.0, and that this ensures your rule can be shared with other Semgrep Registry users. So the deal is not the GPL or the MIT, it is a grant that lets the registry redistribute what you wrote, which is the point of a central registry and also the part you should read before you contribute. There is an alternative path for people who want their rules available but not via a pull request, since the README says the team will help import your rules for others to use if you reach out to [email protected]. The repository also carries a contribution guide, a code of conduct, a security policy and a pre-commit configuration, and there is a GitHub Action example for testing rules that you can copy into a fork so your own rules are checked by the same rig.

Rulesets, the registry search and where the rules actually come from

Rulesets are groups of rules organized by purpose, language or framework, sourced from the Semgrep Registry, and the README says that if you want to modify existing rulesets or create your own you should contact the team. That is a notable difference from the rules themselves, because a rule is a file you can fork and change, while a ruleset is a curated bundle that lives in the registry. The registry search is described as the way to find both Community Edition and Pro rules, which means the registry is the index over both this repository and the proprietary set, and the README points at the explore page for browsing. The practical workflow the README describes has three steps, learn the syntax and write rules, run existing and custom rules locally with the command line interface or continuously in CI with the AppSec Platform, and contribute back. The last piece of the story is the `ai/` directory, which is a category of rules that did not exist a few years ago and is a reminder of how fast the corpus changes.

What the state of the repository tells you

The default branch is `develop`, the last push was on 2026-10-14, and the repository publishes no GitHub releases, which fits a corpus that is consumed by cloning or by a registry index rather than by versioned downloads. The primary language of the repository is listed as HCL, which is a curiosity worth a second look, since the rules themselves are YAML with a bit of Jsonnet in the libsonnet directory, and the HCL designation likely reflects the configuration files in the tree rather than the rules. The practical guidance for anyone building on this corpus is short. Pin the rules you rely on by commit, because a corpus that changes daily is a corpus whose findings change daily, run the validation and test rig on any rules you vendor, and read the Pro rules documentation before you promise anyone a deep analysis, because the free rules will not do it. Everything else is a matter of picking the right pattern for the language you write in.

Editorial conclusion

Adopt semgrep-rules as the rule source for your Semgrep Community Edition scanning, and treat the registry search as the place to find the rule you want rather than writing one from scratch. Do not expect the free corpus to cover what the Pro rules cover, since the README is explicit that the proprietary rules add language coverage along with cross-file and deep dataflow analysis, and single-file rules will miss whole classes of vulnerability. Before you write your own rule, look at the `template.yaml` file and the test rig, because a rule without a test is a rule you cannot trust, and before you contribute, read the licence grant, since by submitting you allow Semgrep to redistribute your rule under the Semgrep Rules License. The licence is the custom Semgrep Rules License, the default branch is `develop`, and the last push was on 2026-10-14.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. semgrep/semgrep-rules on GitHub