ClawSec suite manager with embedded advisory-feed monitoring, cryptographic signature verification, approval-gated malicious-skill response, and guided setup for additional security skills.

ClawSec Suite Vercel Skills Installation Install with the Vercel Skills CLI for this harness: Operational Notes Required runtime: node , npx , openclaw , curl , jq , shasum , openssl , unzip Side effects: setup scripts install an advisory hook under ~/.openclaw/hooks , optionally create an unattended openclaw cron job, and use npx clawhub@latest install for guarded installs Network behavior: fetches signed advisory feed artifacts and remote catalog metadata unless you pin local paths Trust model: the suite can recommend removal or block risky installs, but removal/install overrides stay approval gated This means clawsec suite can: monitor the ClawSec advisory feed, track which advisories are new since last check, cross reference advisories against locally installed skills, recommend removal for malicious skill advisories and require explicit user approval first, and still act as the setup/management entrypoint for other ClawSec protections. Included vs Optional Protections Built into clawsec suite Embedded signed advisory trust set: advisories/feed.json , feed.json.sig , checksums.json , checksums.json.sig , and feed signing public.pem Portable heartbeat workflow in HEARTBEAT.md Advisory polling + state tracking + affected skill checks OpenClaw advisory guardian hook package: hooks/clawsec advisory guardian/ Setup scripts for hook and optional cron scheduling: scripts/ Guarded installer: scripts/guarded skill install.mjs Dynamic catalog discovery for installable skills: scripts/discover skill catalog.mjs Installed separately (dynamic catalog) clawsec suite does not hard code add on skill names in this document. Discover the current catalog from the authoritative index ( https://clawsec.prompt.security/skills/index.json ) at runtime: Fallback behavior: If the remote catalog index is reachable and valid, the suite uses it. If the remote index is unavailable or malformed, the script falls back to suite local catalog metadata in skill.json . Installation Cross shell path note In bash / zsh , keep path variables expandable (for example, INSTALL ROOT="$HOME/.openclaw/skills" ). Do not single quote home variable paths (avoid '$HOME/.openclaw/skills' ). In PowerShell, set an explicit path: $env:INSTALL ROOT = Join Path $HOME ".openclaw\\skills" If a path is passed with unresolved tokens (like \$HOME/... ), suite scripts now fail fast with a clear error. Option A: Via clawhub (recommended) Option B: Manual download with signature + checksum verification OpenClaw Automation (Hook + Optional Cron) After installing the suite, enable the advisory guardian hook: The setup script prints a preflight review before it installs and enables the persistent hook. Optional: create/update a periodic cron nudge (default every 6h ) that triggers a main session advisory scan: The cron setup script prints a preflight review before it creates or updates the unattended job. What this adds: scan on agent:bootstrap and /new ( command:new ), compare advisory affected entries against installed skills, consider advisories with application: "openclaw" (and legacy entries without application for backward compatibility), notify when new matches appear, and ask for explicit user approval before any removal flow. Restart the OpenClaw gateway after enabling the hook. Then run /new once to force an immediate scan in the next session context. Guarded Skill Install Flow (Double Confirmation) When the user asks to install a skill, treat that as the first request and run a guarded install check: Behavior: If no advisory match is found, install proceeds. If version is omitted, matching is conservative: any advisory that references the skill name is treated as a match. If advisory match is found, the script prints advisory context and exits with code 42 . Then require an explicit second confirmation from the user and rerun with confirm advisory : This enforces: 1. First confirmation: user asked to install. 2. Second confirmation: user explicitly approves install after seeing advisory details. Embedded Advisory Feed Behavior The embedded feed logic uses these defaults: Remote consolidated feed URL: https://clawsec.prompt.security/advisories/feed.json Feed contents: NVD CVEs, approved community advisories, and provisional GHSA without CVE advisories. Remote feed signature URL: ${CLAWSEC FEED URL}.sig (override with CLAWSEC FEED SIG URL ) Remote checksums manifest URL: sibling checksums.json (override with CLAWSEC FEED CHECKSUMS URL ) Local seed fallback: ~/.openclaw/skills/clawsec suite/advisories/feed.json Local feed signature: ${CLAWSEC LOCAL FEED}.sig (override with CLAWSEC LOCAL FEED SIG ) Local checksums manifest: ~/.openclaw/skills/clawsec suite/advisories/checksums.json Pinned feed signing key: ~/.openclaw/skills/clawsec suite/advisories/feed signing public.pem (override with CLAWSEC FEED PUBLIC KEY ) State file: ~/.openclaw/clawsec suite feed state.json Hook rate limit env (OpenClaw hook): CLAWSEC HOOK INTERVAL SECONDS (default 300 ) Fail closed verification: Feed signatures are required by default. Checksum manifests are verified when companion checksum artifacts are available. Set CLAWSEC ALLOW UNSIGNED FEED=1 only as a temporary migration bypass when adopting this version before signed feed artifacts are available upstream. Quick feed check Exploitability Context Advisories in the feed can include exploitability score and exploitability rationale fields to help agents prioritize real world threats: Exploitability scores : high , medium , low , or unknown Context aware assessment : Considers attack vector, authentication requirements, and AI agent deployment patterns Exploit availability : Detects public exploits and weaponization status When processing advisories, prioritize by exploitability in addition to severity. A HIGH severity + HIGH exploitability CVE is more urgent than a CRITICAL severity + LOW exploitability CVE. For detailed methodology, see the [exploitability scoring documentation](../../wiki/exploitability scoring.md). Heartbeat Integration Use the suite heartbeat script as the single periodic security check entrypoint: skills/clawsec suite/HEARTBEAT.md It handles: suite update checks, feed polling, new advisory detection, affected skill cross referencing, approval gated response guidance for malicious/removal advisories, and persistent state updates. Approval Gated Response Contract If an advisory indicates a malicious or removal recommended skill and that skill is installed: 1. Notify the user immediately with advisory details and severity. 2. Recommend removing or disabling the affected skill. 3. Treat the original install request as first intent only. 4. Ask for explicit second confirmation before deletion/disable action (or before proceeding with risky install). 5. Only proceed after that second confirmation. The suite hook and heartbeat guidance are intentionally non destructive by default. Advisory Suppression / Allowlist The advisory guardian pipeline supports opt in suppression for advisories that have been reviewed and accepted by your security team. This is useful for first party tooling or advisories that do not apply to your deployment. Activation Advisory suppression requires a single gate: the configuration file must contain "enabledFor" with "advisory" in the array. No CLI flag is needed the sentinel in the config file IS the opt in gate. If the enabledFor array is missing, empty, or does not include "advisory" , all advisories are reported normally. Config File Resolution (4 tier) The advisory guardian resolves the suppression config using the same priority order as the audit pipeline: 1. Explicit config <path argument 2. OPENCLAW AUDIT CONFIG environment variable 3. ~/.openclaw/security audit.json 4. .clawsec/allowlist.json Config Format Sentinel Semantics "enabledFor": ["advisory"] only advisory suppression active "enabledFor": ["audit"] only audit suppression active (no effect on advisory pipeline) "enabledFor": ["audit", "advisory"] both pipelines honor suppressions Missing or empty enabledFor no suppression active (safe default) Matching Rules checkId: exact match against the advisory ID (e.g., CVE 2026 25593 or CLAW 2026 0001 ) skill: case insensitive match against the affected skill name from the advisory Both fields must match for an advisory to be suppressed Required Fields per Suppression Entry Field Description Example checkId Advisory ID to suppress CVE 2026 25593 skill Affected skill name clawsec suite reason Justification for audit trail (required) First party tooling, reviewed by security team suppressedAt ISO 8601 date (YYYY MM DD) 2026 02 15 Shared Config with Audit Pipeline The advisory and audit pipelines share the same config file. Use the enabledFor array to control which pipelines honor the suppression list: Audit entries (with check identifiers like skills.code safety ) are only matched by the audit pipeline. Advisory entries (with advisory IDs like CVE 2026 25593 or CLAW 2026 0001 ) are only matched by the advisory pipeline. Each pipeline filters for its own relevant entries. Optional Skill Installation Discover currently available installable skills dynamically, then install the ones you want: Machine readable output is also available for automation: Security Notes Always verify checksums.json signature before trusting its file URLs/hashes, then verify each file checksum. Verify advisory feed detached signatures; do not enable CLAWSEC ALLOW UNSIGNED FEED outside temporary migration windows. Keep advisory polling rate limited (at least 5 minutes between checks). Treat critical and high advisories affecting installed skills as immediate action items. If you migrate off standalone clawsec feed , keep one canonical state file to avoid duplicate notifications. Pin and verify public key fingerprints out of band before first use.

clawsec-suite