Skillv1.0.1

ClawScan security

gog-safety · ClawHub's context-aware review of the artifact, metadata, and declared behavior.

Scanner verdict

BenignMar 6, 2026, 3:51 AM

Verdict: benign
Confidence: medium
Model: gpt-5-mini
Summary: The skill's code, scripts, and instructions are coherent with its stated purpose (building and deploying compile-time‑profiled gog binaries), but it requires fetching and executing upstream code during the build and the registry metadata omits some required tools — review the upstream repo and run builds in a trusted/isolated environment before installing on production hosts.
Guidance: This skill appears to do what it says (build and deploy safety‑profiled gog binaries) but before using it: 1) verify the upstream repository and branch being cloned (https://github.com/drewburchfield/gogcli-safe.git, branch feat/safety-profiles) actually contains the intended PR/patch — the SKILL.md refers to steipete/gogcli#366 so confirm the fork is trustworthy or prefer the official upstream commit/hash; 2) inspect the cloned code, especially cmd/gen-safety and any build scripts, because the build runs 'go run' (i.e., executes code from that repo) and could run arbitrary actions on your build machine; 3) run builds in an isolated environment (container/VM) and only deploy binaries you have reviewed; 4) ensure the deploying user has appropriate sudo/backup procedures on target hosts (deploy will overwrite /usr/local/bin/gog and creates gog-backup); and 5) update any registry metadata or provenance notes to declare required tools (git, Go) and the exact upstream commit/URL you reviewed. If you cannot or will not review the upstream source, treat this as higher risk and avoid running the build on sensitive hosts.

Review Dimensions

Purpose & Capability: noteThe name/description (build+deploy safety-profiled gog binaries) matches the included scripts, YAML profiles, and SKILL.md instructions. One mismatch: registry metadata lists no required binaries, but SKILL.md and scripts explicitly require git and Go (Go 1.22+) and use ssh/scp for deployment. Those tools are reasonable for the stated purpose but should be declared.
Instruction Scope: noteInstructions and scripts stay within the declared goal: choosing a YAML profile, injecting it into a gogcli checkout, running a code generator (go run ./cmd/gen-safety), building the binary, and deploying via scp/ssh. However, the build step runs code from the cloned repository (go run), which means arbitrary code in that repo will execute on the builder machine — this is expected for a source build but is a notable risk that requires review of the upstream source before running.
Install Mechanism: concernThere is no packaged install spec; the scripts clone an external repository (UPSTREAM_REPO=https://github.com/drewburchfield/gogcli-safe.git, branch feat/safety-profiles) and run code from it. The SKILL.md references steipete/gogcli PR #366 but the clone target is a different fork/URL, which is a potential coherence issue: either a mirror or an unverified fork. Cloning and executing code from an external/unverified repo is the highest‑risk install pattern here and should be reviewed.
Credentials: noteThe skill does not request environment variables or credentials. Deployment uses ssh/scp and remote sudo to replace /usr/local/bin/gog, which is proportionate but requires privileged access on remote hosts. There is no evidence the skill tries to access unrelated credentials or local config paths, but building executes upstream code (see instruction_scope) which could access the builder environment if malicious.
Persistence & Privilege: okalways is false and the skill does not request persistent platform-level privileges. The deploy script replaces a system binary on remote hosts (requires sudo there) which is expected for installing a CLI binary; no self-modifying or cross-skill config changes are present.