Semgrep

Overview

Semgrep (and OpenGrep) uses YAML rules to find code patterns via Abstract Syntax Tree matching. Rules detect vulnerabilities, anti-patterns, and policy violations in application code, IaC, and config files.

Capabilities

Pattern matching with metavariables ($VAR, ...)
Taint mode for tracking data flow from sources to sinks within a function (cross-function and cross-file tracking available with Semgrep Pro)
Supports 35+ languages
Lightweight, fast execution with no build step required

Limitations

Analyzes one file at a time by default — cross-file analysis available with Semgrep Pro
Not applicable to runtime or infrastructure state checks — check out InSpec or Goss for runtime validation, or Checkov for IaC static analysis

If you’ve got a paid Semgrep subscription and are looking for multi-file support, please let us know at zenable.io/feedback.

Generated Format

Language: YAML
Structure: Semgrep rule files with id, message, severity, languages, and pattern specification fields
Execution: semgrep --config rule.yaml

Example Guardrail

rules:
  - id: sql-injection-prevention
    mode: taint
    languages: [python]
    severity: HIGH
    message: User input flows to SQL query without sanitization
    pattern-sources:
      - pattern: request.args.get(...)
    pattern-sinks:
      - patterns:
          - pattern: cursor.execute($QUERY, ...)
          - focus-metavariable: $QUERY
    pattern-sanitizers:
      - pattern: sanitize(...)

Learn more at Semgrep rule syntax, pattern syntax, and supported languages.

Custom guardrails

You can author your own semgrep / opengrep rules and have Zenable apply them alongside marketplace guardrails. Configure each custom guardrail directory under the engine it belongs to:

guardrails:
  engines:
    semgrep:
      extras:
        custom_guardrail_dirs:
          - path: ~/.zenable/custom_guardrails/semgrep
            recurse: true
    opengrep:
      extras:
        custom_guardrail_dirs:
          - path: ~/.zenable/custom_guardrails/opengrep
            recurse: true

`metadata.category`

Every custom rule must declare a metadata.category from the upstream semgrep set: best-practice, correctness, maintainability, performance, portability, or security. Zenable translates these to its own FindingCategory taxonomy at the boundary. Rules with metadata.category: security must also declare confidence, likelihood, impact, subcategory, cwe, owasp, references, technology, and vulnerability_class per the upstream contributor requirements. You can use the zenable guardrail validate command in order to confirm your custom rule is valid for Zenable guardrail use, for instance:

zenable guardrail validate opengrep ~/.zenable/custom_guardrails/semgrep/custom-no-eval.yaml

Overview

Integrations

MCP Server

Guardrails Engines

IDE Installation Guides

Deprecated IDEs

Tools & Reference

Use Cases

Overview

Capabilities

Limitations

Generated Format

Example Guardrail

Custom guardrails

`metadata.category`

​Overview

​Capabilities

​Limitations

​Generated Format

​Example Guardrail

​Custom guardrails

​metadata.category

Overview

Capabilities

Limitations

Generated Format

Example Guardrail

Custom guardrails

`metadata.category`