T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:5
- Finding
- Unpinned CLI Installation from a Third-Party Homebrew Tap## Vulnerability Details **File Location**: `SKILL.md`, line 5 **Vulnerability Type**: Third-party supply-chain dependency installed without version or integrity pinning **Risk Level**: Medium ### Vulnerable Code Snippet ```yaml metadata: {"clawdbot":{"emoji":"🎮","requires":{"bins":["gog"]},"install":[{"id":"brew","kind":"brew","formula":"steipete/tap/gogcli","bins":["gog"],"label":"Install gog (brew)"}]}} ``` ### Technical Analysis The skill instructs the platform to install `gog` from the third-party Homebrew tap `steipete/tap/gogcli`. The dependency declaration does not identify an immutable release, commit, package digest, or expected checksum. Consequently, the code installed at a later date may differ from the dependency that was available when this skill was reviewed. If the tap, formula repository, maintainer account, release infrastructure, or referenced package artifact is compromised, an attacker could replace the expected CLI with a malicious build. Homebrew formula installation may also execute formula-defined build or installation logic under the invoking user's account. This finding does not establish that the current `gog` package or its maintainer is malicious. The risk arises from reliance on mutable third-party supply-chain state without integrity verification. ### Attack Path 1. An attacker compromises the third-party tap, its maintainer account, release infrastructure, or an artifact referenced by the formula. 2. The attacker changes the formula or distributed artifact while preserving the expected package name. 3. A user or agent installs the dependency through the skill's declared Homebrew installation method. 4. Homebrew retrieves and executes or installs the attacker-controlled package content. 5. The malicious package executes with the privileges of the user running Homebrew. 6. The substituted `gog` binary can later intercept OAuth setup, tokens, command arguments, and Google Workspace data ...[truncated 897 chars]
- Remediation
- ## Remediation Suggestions 1. Pin the dependency to a specifically reviewed release rather than relying solely on a mutable formula name. 2. Verify downloaded artifacts against a publisher-provided cryptographic checksum or signature before installation. 3. Where supported, reference an immutable source commit or versioned artifact and record its expected digest in the installation metadata. 4. Prefer an official, trusted distribution channel with signed releases and documented provenance. 5. Add installation documentation that identifies the expected package version, checksum, signer, and verification procedure. 6. Use automated dependency monitoring to detect upstream ownership changes, formula modifications, checksum changes, and newly disclosed vulnerabilities. 7. Perform OAuth setup only after verifying the installed binary's provenance and integrity. 8. Grant only the Google Workspace scopes required for the intended operation, separating accounts or authorizations when broad multi-service access is unnecessary.