openclaw/security/opengrep

Compiled OpenGrep super-configs

precise.yml is OpenClaw's shipped precise OpenGrep rulepack. Each rule is tied to a source advisory, vulnerability report, or review identifier through metadata and is intended to have concrete coverage of the original vulnerable behavior or a verified variant.

Rule provenance lives in each compiled rule's metadata; no separate manifest is committed or generated by default.

Noisy exploratory rules are intentionally kept out of the tracked repo. Anything appended to precise.yml must be low-noise enough to run as a blocking PR-diff check and as a manual full-repository audit.

Editing rules

precise.yml is the checked-in compiled rulepack. Prefer changing source rule YAML and rerunning security/opengrep/compile-rules.mjs instead of hand-editing compiled rules. The compiler appends new rule IDs by default. Use --update-existing to repair selected existing rules without changing unrelated rules or their formatting. Use --replace-precise only when intentionally rebuilding the rulepack from a complete source folder. Direct edits are discouraged because they can bypass ID, metadata, duplicate, and OpenGrep validation.

Rule naming and metadata

Every rule's id is rewritten to <source-id>.<original-id>. Every rule's metadata block is augmented with source fields enforced by pnpm check:opengrep-rule-metadata:

Key	Value
ghsa	GHSA-xxxx-xxxx-xxxx for GHSA-backed rules
advisory-id	non-GHSA source identifier, or the GHSA ID normalized by the compiler
advisory-url	durable URL to the advisory, report, review record, or source context
detector-bucket	precise
source-rule-id	the original source rule id
source-file	optional source YAML file used during compilation

Recompiling

# from the openclaw repo root
node security/opengrep/compile-rules.mjs \
  --rules-dir <folder-with-source-rule-yaml>

The script:

1. Recursively walks every .yml / .yaml file under --rules-dir
2. Reads top-level rules arrays from those source files
3. Requires each source rule to provide metadata.ghsa or metadata.advisory-id
4. Requires metadata.advisory-url for non-GHSA source identifiers
5. Rewrites ids and injects metadata as above
6. Appends only new precise rule ids to the existing precise.yml by default; pass --replace-precise to rebuild it from just the supplied source folder
7. Runs opengrep scan --no-strict against an empty target to identify schema-invalid or parser-invalid rules and drops mapped bad rules so the published super-config loads cleanly
8. Writes precise.yml

Skipped, duplicate, or invalid rules are summarized on stdout/stderr for follow-up.

For a scoped correction, pass the source folder for that rule:

node security/opengrep/compile-rules.mjs \
  --rules-dir security/opengrep/rules/ghsa-82g8-464f-2mv7 \
  --update-existing

This mode requires nonempty valid input and unique existing and generated IDs. Unknown IDs, duplicate IDs, YAML errors, or failed OpenGrep validation stop the operation without changing precise.yml. It validates the whole candidate pack and replaces only the selected YAML nodes, preserving unrelated bytes. Unlike append/rebuild mode, it never drops invalid rules. It cannot be combined with --replace-precise.

Run the non-executing TypeScript and JavaScript scanner fixtures with:

opengrep test --config security/opengrep/rules/ghsa-82g8-464f-2mv7 \
  security/opengrep/rules/ghsa-82g8-464f-2mv7

The skill-environment rule follows skill configuration, resolved entries, and metadata-derived keys into host environment writes. Only the consumed allowed output of sanitizeSkillEnvOverrides clears that flow; an unrelated or ignored sanitizer call and the generic sandbox sanitizer do not. Trusted service configuration and saved host environment restoration are not skill inputs. The rule uses local dataflow, including explicit tuple-loop/map propagation; it is not an interprocedural proof of every possible wrapper or mutation. Keep new source, mutation, and sanitizer shapes covered by scanner fixtures.

Validating locally

pnpm check:opengrep-rule-metadata
opengrep validate security/opengrep/precise.yml

The metadata check must pass before rules are committed. OpenGrep validation must exit zero. Warnings about unknown fields are acceptable only when OpenGrep still reports Configuration is valid and a non-zero rule count. The compile script drops mapped schema/parser-invalid rules and fails closed when OpenGrep validation itself cannot be completed.

Running locally

scripts/run-opengrep.sh

For SARIF output matching the PR workflow's diff-scoped scan:

scripts/run-opengrep.sh --changed --sarif

For SARIF output matching the manual full-repository workflow:

scripts/run-opengrep.sh --sarif

Why --no-strict?

Some generated rules trigger non-fatal opengrep warnings (for example, unknown-field warnings on compatibility-only keys). --no-strict keeps opengrep's exit code clean for those warnings. Parser-invalid rules are still dropped during compilation so the checked-in super-config validates before CI uses it.

Why --no-git-ignore?

Some OpenClaw paths are excluded by .gitignore for build reasons even though they contain meaningful source code we want scanned. --no-git-ignore keeps opengrep from skipping them.