DriftGuard Security Scanner+

DriftGuard Security Scanner+ is a local-first security drift scanner for repos, OpenClaw skills, and AI agent tools. Use to scan before trust, save trusted baselines, compare after updates, generate human review tickets, review file/hash drift, dependency drift, install-hook changes, symlink changes, prompt-injection signals, sensitive-path references, obfuscation, shell execution, network access, and risky capability diffs.

Audits

Pass

Install

openclaw skills install driftguard

DriftGuard Security Scanner+

Trust what you review. Compare what changed since trust.

Use this skill for local security/integrity checks and post-update drift detection on repos, installed skills, and AI agent tool folders.

This skill is intentionally narrower than a generic security scanner. Its best use is:

  • scan a local skill folder or repo before trust
  • save a trusted baseline after review, including approver, note, git commit, package version, risk snapshot, and finding summary
  • compare later to answer what changed since trust
  • highlight risky new capabilities like shell, network, sensitive file access, symlinks, dependencies, prompt-injection signals, obfuscation, or install hooks

Quick start

Run the scanner directly from the installed skill folder:

node {baseDir}/scripts/cli.js scan <path>

Save a trusted baseline after review:

node {baseDir}/scripts/cli.js trust <path>

Save a trusted baseline to a custom location:

node {baseDir}/scripts/cli.js trust <path> --baseline ./reports/skill-baseline.json

Compare a skill or repo against a saved baseline:

node {baseDir}/scripts/cli.js compare <path> --baseline ./reports/skill-baseline.json

Generate a reviewer approval ticket for a scan or comparison:

node {baseDir}/scripts/cli.js compare <path> --baseline ./reports/skill-baseline.json --review ./reports/review-ticket.md

Recommended workflow

1. Scan before trust

Review the candidate repo or skill first.

node {baseDir}/scripts/cli.js scan /path/to/skill

Treat high or critical output as a stop sign until manually reviewed.

2. Trust after review

If the findings are acceptable, save a trusted baseline.

node {baseDir}/scripts/cli.js trust /path/to/skill

3. Compare after updates

After the skill changes or updates, compare it to the saved baseline.

node {baseDir}/scripts/cli.js compare /path/to/skill --baseline ./reports/baseline.json

Look especially for:

  • newly added or changed files
  • new shell or network findings
  • dependency or install-hook drift
  • new symlinks or sensitive file references

4. Create a review ticket before re-trusting

For marketplace publishing, PR review, or team handoff, write a human approval checklist:

node {baseDir}/scripts/cli.js compare /path/to/skill --baseline ./reports/baseline.json --review ./reports/review-ticket.md

The ticket includes:

  • approve/reject/needs-review checkboxes
  • required security checks based on detected drift
  • trust recommendation and reasons
  • risk deltas and new capability categories
  • why each new finding received its severity and what the reviewer should check next
  • a copy-paste approval note for PRs or release notes

What it checks

  • risky shell execution patterns like curl | bash, eval, exec, subprocess, os.system
  • outbound network patterns like fetch, axios, requests, curl, webhook usage
  • references to sensitive files like .env, SSH keys, SOUL.md, MEMORY.md, OpenClaw config
  • prompt injection style content in SKILL.md, SOUL.md, MEMORY.md
  • obfuscation hints like base64 helpers and long encoded blobs
  • symlink drift without following symlinks
  • dependency drift in package.json, requirements.txt, and pyproject.toml
  • install-hook changes in package.json
  • combo risks like:
    • shell + network
    • network + sensitive files
    • shell + prompt-injection signals
    • obfuscation + active capabilities

Config suppressions

Prefer a reviewer-controlled config passed with --config <file>. By default, the scanner does not automatically honor .driftguard.json inside the target being scanned, because an untrusted target could suppress its own risky findings. Use --use-target-config only after reviewing the target-provided suppressions.

Example:

{
  "ignorePaths": ["dist/", "fixtures/"],
  "ignoreRules": ["net.fetch", "shell.exec_generic", "shell.*"]
}

Use suppressions sparingly. If a rule is noisy, prefer narrowing it later instead of muting the whole category.

Exit codes

  • 0 for low risk and no drift
  • 1 for medium risk or drift detected
  • 2 for high or critical risk

Use this for CI or install gating.

Review tickets

Use --review <file> when the output needs to be read by a human before refreshing trust. This is the best default for publishing updates because it turns scanner output into an approval artifact instead of just a machine report. Each finding should include severity rationale and reviewer guidance so users understand why something is high, medium, or low instead of treating the scanner as a black box.

Positioning

Use this skill when you want a transparent, local, deterministic trust workflow. Do not use it as the sole authority for safety. It is a heuristic scanner plus drift guard, not a guarantee.