Create Production-Quality Semgrep Rules

Semgrep Rule Creator guides the development of custom rules for bug patterns, security vulnerabilities and coding standards. Its workflow analyzes the problem, writes tests first, inspects AST structure, implements a rule, iterates until every test passes and then optimizes and retests. A final run completes the checklist.

Approach selection distinguishes simple syntactic matching from taint analysis. Prioritize taint mode when untrusted input flows to a dangerous sink: syntax alone may match both vulnerable input and a safe literal. The approach can change if propagation behavior or false-positive results justify it; the goal is a working, tested detector rather than rigid adherence to a mode.

Use it to author a specific custom Semgrep rule. Running an existing ruleset or performing general static analysis belongs elsewhere. Generic function-call patterns are too broad, while exact formatting assumptions can miss valid variations. Inspect the AST to understand how Semgrep represents the language before choosing patterns.

The workflow requires documentation review before implementation, tests before rules and a complete passing test set. Optimize only after correctness is established. For a language-specific target, avoid languages: generic. Each YAML file must contain exactly one rule, and todook or todoruleid annotations for deferred improvements are forbidden.

Start with the target language, unwanted behavior and examples of vulnerable and safe code. Include alternative coding styles, sanitized inputs, safe alternatives and boundary conditions. Use ruleid annotations for expected findings and ok annotations for expected non-findings; catching one vulnerable example is insufficient evidence of precision.

The output is a directory named for the rule ID containing exactly two files: its YAML rule and its language-specific test file. Test the pair from that directory with the prescribed command:

semgrep --test --config <rule-id>.yaml <rule-id>.<ext>

A complete rule needs its identification, language, message and relevant matching configuration. Short pattern fragments that omit required parts are not standalone rules. A quick-start taint example connects request.args.get input to eval, with a separate safe-literal test.

The process uses Semgrep's test runner and AST analysis. Read current rule syntax, pattern syntax and constant-propagation documentation, the writing-rules index and the referenced advanced testing handbook before authoring a rule.

Only the inline skill is bundled here: quick-reference.md and workflow.md are unavailable. Use the inline checklist and current documentation, report missing support and do not claim to have followed an absent workflow. Validate results in the actual environment and clarify missing permissions, inputs, safety boundaries or success criteria.