T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:5
- Finding
- Unpinned Third-Party Homebrew Dependency## Vulnerability Details **File Location**: `SKILL.md`, line 5 **Vulnerability Type**: Unpinned third-party package installation **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 directs users to install `gogcli` from the third-party Homebrew tap `steipete/tap` without pinning an immutable version, formula revision, commit, checksum, or cryptographic signature. Consequently, the package installed in the future may differ from the artifact that was available when this Skill was reviewed. This creates a supply-chain trust boundary: control of the tap, formula, release assets, or associated distribution infrastructure can influence code executed during installation and subsequent CLI use. The risk is particularly relevant because the installed CLI is intended to receive OAuth authorization for Gmail, Calendar, Drive, Contacts, Sheets, and Docs. The project contains no embedded executable scripts, and the reviewed files do not themselves demonstrate malicious behavior. The vulnerability is limited to the mutable and unverified dependency installation mechanism. ### Attack Path 1. An attacker compromises the third-party Homebrew tap, its maintainer account, the referenced release infrastructure, or another component in the package distribution chain. 2. The attacker modifies the formula or replaces a release artifact with a malicious version while retaining the expected package name. 3. A user installs or upgrades the dependency through the Skill's unpinned `steipete/tap/gogcli` formula. 4. Homebrew executes attacker-controlled installation logic or installs an attacker-controlled `gog` binary under the user's account. 5. When the user performs OAuth setup or invokes Workspace commands, the malicious ...[truncated 830 chars]
- Remediation
- ## Remediation Suggestions 1. Pin installation to a reviewed, immutable release version and, where supported, an immutable formula commit. 2. Verify downloaded release artifacts using a published cryptographic checksum or signature before installation. 3. Prefer an authoritative package source controlled by the upstream project and document the source repository and release-verification procedure. 4. Avoid automatic upgrades to unreviewed releases; require explicit review before changing the pinned version. 5. Document the exact OAuth scopes requested and apply least privilege by authorizing only the Workspace services needed for each user workflow. 6. Store OAuth credentials using operating-system-protected credential storage, restrict file permissions, and provide token revocation and rotation instructions. 7. Consider reproducible builds or provenance attestations so users can verify that the distributed binary corresponds to reviewed source code.
