Skillv1.0.0

ClawScan security

Config Drift Scanner · ClawHub's context-aware review of the artifact, metadata, and declared behavior.

Scanner verdict

SuspiciousApr 28, 2026, 11:46 PM

Verdict: suspicious
Confidence: medium
Model: gpt-5-mini
Summary: The skill's instructions broadly match a config-drift scanner, but it omits and assumes sensitive runtime requirements (kubectl/kube credentials, ripgrep, python3, access to secrets/vault) and therefore its declared metadata is incomplete and disproportionate to its purpose.
Guidance: This skill appears to do what it says but is missing important runtime requirements and safety guidance. Before installing or running it: 1) Confirm which binaries are required (kubectl, python3, rg/ripgrep, grep/find) and ensure they exist in the runtime environment. 2) Do not point it at a kubeconfig with wide privileges — provide a read-only, least-privilege service account or a context limited to non-production if possible. 3) Ask the publisher to declare required credentials (KUBECONFIG, VAULT_TOKEN, cloud creds) and to add explicit handling to avoid printing or transmitting secrets (redaction, minimal outputs). 4) Prefer running this in an isolated CI job with limited credentials rather than on a developer laptop with full access. 5) If you need secrets-check functionality, require explicit, auditable integrations with your secrets manager (and avoid storing secrets in plaintext in reports). If the publisher cannot clarify these points, treat the skill as risky to run against real clusters or repos containing secrets.

Review Dimensions

Purpose & Capability: noteThe skill's stated purpose (compare configs, env vars, feature flags, secrets across environments) aligns with the commands in SKILL.md (search repo, read .env/tfvars, query Kubernetes ConfigMaps). However the SKILL.md assumes tools and access (kubectl, python3, rg/ripgrep, read access to repo and cluster contexts) that are not declared in the registry metadata. Also the doc claims to check 'secrets' and 'secrets manager' but the provided kubectl example only reads ConfigMaps (not Kubernetes Secrets) and there are no concrete vault/secret-manager integration steps — an inconsistency between claimed capability and concrete instructions.
Instruction Scope: concernInstructions direct the agent to scan local repository files, run ripgrep over source, and query Kubernetes namespaces (dev/staging/prod), producing files in /tmp and a markdown report. These actions legitimately fit the goal but will require reading potentially sensitive data (env files, tfvars, ConfigMaps and possibly Secrets if adapted). The SKILL.md gives no guidance on safe handling/redaction of secrets, nor does it constrain which kube contexts to use — it implicitly assumes kubeconfig with access to dev/staging/prod. That grants broad data access and could expose secrets if the agent transmits outputs.
Install Mechanism: okThis is an instruction-only skill with no install spec and no code files, which minimizes disk write/install risk. Risk derives from runtime commands (kubectl, rg, python3) rather than an install mechanism.
Credentials: concernRegistry metadata declares no required env vars or credentials, yet the instructions require access to cluster credentials (kubeconfig or context with rights to read ConfigMaps/possibly Secrets), and mention cross-referencing with secrets managers/vault without declaring needed tokens (VAULT_TOKEN, cloud provider creds, etc.). The absence of declared credentials is disproportionate to the sensitive operations described and makes the skill's security assumptions unclear.
Persistence & Privilege: okThe skill does not request always:true and is user-invocable only; autonomous invocation is allowed (platform default). There is no install-time persistence. Note: if given cluster credentials and autonomous invocation, the agent could repeatedly access sensitive config — consider this when granting runtime credentials.