T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:5
- Finding
- Unpinned External Go Dependency Installed from a Mutable Version## Vulnerability Details **File Location**: `SKILL.md`, lines 5–13 **Vulnerability Type**: Unpinned third-party executable dependency **Risk Level**: Medium **Vulnerable code snippet**: ```yaml metadata: {"clawdbot":{"emoji":"📰","requires":{"bins":["blogwatcher"]},"install":[{"id":"go","kind":"go","module":"github.com/Hyaxia/blogwatcher/cmd/blogwatcher@latest","bins":["blogwatcher"],"label":"Install blogwatcher (go)"}]}} ``` ```markdown Install - Go: `go install github.com/Hyaxia/blogwatcher/cmd/blogwatcher@latest` ``` ### Technical Analysis The Skill directs the installation system and users to install `github.com/Hyaxia/blogwatcher/cmd/blogwatcher@latest`. The `@latest` selector is mutable and resolves to whichever upstream version is considered latest at installation time. Consequently, the installed source is not necessarily the version reviewed when this Skill was published. This creates a supply-chain risk because a compromised upstream repository, maintainer account, module release process, or malicious future release could alter the executable delivered through these instructions. The project does not pin an immutable reviewed version or commit and does not specify an independent checksum or provenance-verification mechanism. ### Attack Path 1. An attacker compromises the upstream repository, a maintainer account, or its release process. 2. The attacker publishes a malicious version that becomes the module version resolved by `@latest`. 3. A user or automated Skill installer processes the installation metadata or follows the documented `go install` command. 4. Go downloads and compiles the attacker-controlled source into the local `blogwatcher` executable. 5. When the Skill or user invokes `blogwatcher`, the malicious executable runs with the invoking user's privileges. ### Impact Assessment Successful exploitation could provide arbitrary code execution under the account that installs or invokes the ...[truncated 518 chars]
- Remediation
- ## Remediation Suggestions 1. Replace `@latest` in both the installation metadata and documentation with a specific, reviewed semantic version, such as `@vX.Y.Z`. 2. For stronger immutability, pin a reviewed commit or otherwise ensure the selected version cannot be replaced in the trusted distribution channel. 3. Keep the version in the metadata and human-readable installation instructions synchronized. 4. Verify the selected release's source provenance and review upstream changes before upgrading. 5. Where the distribution workflow permits it, validate release checksums or signed provenance and document the expected publisher and repository. 6. Process dependency updates through an explicit review and testing workflow rather than automatically tracking the latest release.