Documentation Index
Fetch the complete documentation index at: https://docs.zenable.io/llms.txt
Use this file to discover all available pages before exploring further.
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
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: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: