semgrep-rules

branch	using semgrep docker image	test status
`master`	`returntocorp/semgrep:latest`
`develop`	`returntocorp/semgrep:develop`

This is an repository containing rules written for semgrep, organized by language. Go to the main semgrep documentation for details on semgrep and the syntax for the yaml files in this repository. You can also browse these rules online.

Security Coverage

semgrep features security rules that target common weaknesses and OWASP categories. Each security rule in this repository has metadata fields for cwe (and owasp when applicable). OWASP coverage for rules in this repository, organized by language, is shown below.

Contributing

We welcome contributions to this repo! Please fork and make a pull request; we'll contact you about signing our CLA.

Rule Namespacing

The namespacing format for contributing rules is <language>.<framework>.<category>.$MORE. If a framework isn't applicable, use lang instead.

category is one of:

security
correctness
best-practice
maintainability
performance

If a security rule is discouraging the use of a bad pattern (such as formatted SQL strings), it is recommended to append audit to your namespace. This distinguishes it from a security rule that is specifically aiming to detect a vulnerability.

Running Rules in CI/Pre-Commit/Developer Workflow

If you want run these rules rather than write them, see the CI instructions on the Semgrep Registry (click through to any rule pack). That website is a convenient frontend for this repository.

Help

Join slack for the fastest answers to your questions! Or contact the team at semgrep@r2c.dev.

Testing Rules

A testing system is available which can be used to check the rules against example source code files. It requires semgrep from semgrep

If you wrote a rule in a yaml named eqeq-bad.yaml with a rule id named my-eqeq-bad, you could put a file in the same directory named eqeq-bad.py (it just needs to have the same name except for the extension as eqeq-bad.yaml). Then:

# ruleid:my-eqeq-bad
x == x

Running make test will execute the test suite, and if my-eqeq-bad does not fire on the line below the comment, your rule will fail.

If you have a rule that is not working, but you want to commit it soo it's documented but not fail the tests, use #todoruleid:...:

# todoruleid:my-eqeq-bad
x != x

Github Action To Run Tests

If you fork this repo or create your own, you can add a special semgrep-rules-test Github Action to your workflow that will automatically test your rules by running make test using the latest version of semgrep.

See ours here

Benchmarks

The benchmark job runs every weekend. It uploads a few artifacts, which can be downloaded. If you download the test logs, there are two relevant pieces of information in there: the benchmark table, which roughly shows the performance of every rule that completes in under 60 seconds, and any failed tests are rules that did not complete within 60 seconds.

To run benchmark tests locally, do the following from the root of semgrep-rules:

pipenv shell
pipenv install --dev
export PYTHONPATH=.
pytest --timeout=60 --rule-directory=[path_to_rule_directory] --git-repo=[git_URL] tests/performance/test_public_repos.py

If you omit --git-repo from the pytest command, it will run the provided benchmark repo.

dbaxa / semgrep-rules