Security Team
ReviewAudited by ClawScan on May 10, 2026.
Overview
This is mostly a coherent local security-audit skill, but its privacy and no-network assurances are broader than the included npm-audit and optional webhook/Supabase data flows support.
Install only if you are comfortable giving the agent shell access to scan selected project directories and security files. Review config/security-config.json before running, keep scan scope narrow, treat audit history as sensitive, and do not enable npm audit, cron/webhook scheduling, or dashboard/Supabase sync unless you understand what data may leave your machine.
Findings (7)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A user may believe all audit activity is strictly local, while some configurations or companion dashboard use can send dependency or audit data to external services.
This absolute assurance is broader than the artifacts support: scripts/security-scan.sh runs `npm audit --json`, and dashboard-kit/DASHBOARD-SPEC.md describes sending audit JSON to a webhook/Supabase. Those may be legitimate features, but the privacy claim is overbroad for a tool that scans security-sensitive files.
No data exfiltration. Scripts make no outbound network requests except to user-configured health check endpoints.
Disclose all outbound data flows clearly, make npm audit and dashboard/webhook sync explicit opt-in choices, and avoid absolute 'no outbound' or '100% private' claims unless they are true for every mode.
If the dashboard sync is enabled, security audit details may leave the local machine and be stored in a remote database.
The dashboard companion spec includes an optional remote webhook/Supabase flow for audit results, which may contain security findings and architecture details. The spec includes database RLS, but endpoint authentication and data-minimization details are not shown here.
A webhook endpoint (`/api/security/ingest`) can receive this data and persist it to Supabase for the dashboard.
Only enable webhook/dashboard sync with explicit consent, authenticated ingest endpoints, RLS enabled, minimal raw_log contents, and clear retention rules.
The agent will execute local audit commands that read project files, git state, service status, and dependency metadata.
The skill relies on local shell scripts and system tools to perform audits. This is central to its stated purpose, but users should understand it runs commands against configured local directories and endpoints.
Execute both scripts: ```bash bash scripts/security-scan.sh bash scripts/platform-health.sh ```
Review the scripts and configuration before first run, and keep scan_directories and monitored URLs limited to intended targets.
The scan may expose secret locations, file paths, and partial secret prefixes to the agent and its audit logs.
The scanner intentionally inspects files that may contain credentials and also searches for hardcoded secret patterns. The artifacts show redaction behavior, so this is purpose-aligned, but it is still sensitive access.
find "$dir" \( -name '.env' -o -name '.env.local' -o -name '.env.production' \)
Limit scanned directories, verify redaction before sharing reports, and protect security-team/state.json and audit-history as sensitive files.
Accepted risks or stored findings can suppress future alerts or reveal security posture if the files are exposed.
The skill persists audit history plus known and accepted risks. This is expected for trend tracking and alert suppression, but persistent state can influence future security reports.
"known_issues": [], "accepted_risks": [] ... Save the baseline to `security-team/audit-history/`.
Review accepted risks periodically, keep the state and audit-history directories permission-restricted, and avoid storing raw secrets in audit logs.
Once scheduled, the skill may continue running scans and producing audit records without a new manual prompt each time.
The skill supports recurring autonomous scans through external scheduling. This is disclosed and aligned with the 'daily audit' purpose, but it is still persistent automation.
For automated daily scans: Set up a cron job or Trigger.dev webhook to trigger me at your preferred time
Only enable cron/webhook automation after reviewing configuration, and document how to disable the schedule.
A user relying only on metadata may not realize the skill expects shell execution and local audit tooling.
The registry-style metadata under-describes the runtime footprint: the skill is marked instruction-only, but included setup instructions copy and run local shell scripts.
No install spec — this is an instruction-only skill. Code file presence: scripts/platform-health.sh; scripts/security-scan.sh.
Declare required runtime tools and script execution in metadata, and inspect the included scripts before installing or scheduling the skill.