T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:14
- Finding
- Unpinned Third-Party CLI Dependency## Vulnerability Details **File Location**: `SKILL.md`, lines 14–17 and line 31 **Vulnerability Type**: Supply-chain risk caused by a mutable dependency reference **Risk Level**: Medium **Vulnerable code snippets**: ```yaml { "id": "go", "kind": "go", "module": "github.com/Hyaxia/blogwatcher/cmd/blogwatcher@latest", "bins": ["blogwatcher"], "label": "Install blogwatcher (go)", }, ``` ```markdown - Go: `go install github.com/Hyaxia/blogwatcher/cmd/blogwatcher@latest` ``` ### Technical Analysis The skill configuration and installation documentation instruct users to install a third-party Go CLI using the mutable `@latest` version selector. This means the installed source code is determined at installation time rather than being fixed to the version reviewed when the skill was published. Consequently, future upstream releases can silently change the effective code executed by users. The skill does not specify an audited version or commit and does not document checksum, signature, or provenance verification. A compromise of the upstream repository, release process, module distribution infrastructure, or maintainer account could therefore turn the installation step into an arbitrary-code execution channel. The audited project contains only `SKILL.md`; it does not include the third-party CLI's implementation. The behavior of the remotely obtained executable could not be verified as part of this audit. ### Attack Path 1. An attacker compromises the upstream repository, a maintainer account, or another relevant part of the dependency publication chain. 2. The attacker publishes malicious source code under a version selected by `@latest`. 3. A user or automated skill installer follows the declared installation configuration or documented `go install` command. 4. Go downloads and compiles the attacker-controlled dependency. 5. The resulting `blogwatcher` binary is installed in the user's Go binary dire ...[truncated 777 chars]
- Remediation
- ## Remediation Suggestions 1. Replace `@latest` with a specific, reviewed semantic version or immutable commit identifier in both the metadata and installation instructions. 2. Establish a controlled dependency-update process that reviews upstream source changes before advancing the pinned version. 3. Verify available module checksums through Go's checksum infrastructure and document any required trusted checksum-database policy. 4. Where supported, verify signed releases, build provenance, and maintainer identity before accepting updates. 5. Consider distributing a reproducibly built artifact with published cryptographic hashes and require hash verification before execution. 6. Keep the metadata and human-readable installation command synchronized so neither path falls back to a mutable version selector.