T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:5
- Finding
- Unpinned Third-Party CLI Installation## Vulnerability Details **File Location**: `SKILL.md`, line 5; repeated at line 13 **Vulnerability Type**: Unpinned 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)"}]}} ``` The same unsafe installation target is presented to users at line 13: ```markdown - Go: `go install github.com/Hyaxia/blogwatcher/cmd/blogwatcher@latest` ``` ### Technical Analysis The Skill installs the executable `blogwatcher` CLI from a third-party GitHub-hosted Go module using the mutable `@latest` version selector. The downloaded source code is not included in this artifact, and `@latest` may resolve to a different release after the Skill has been reviewed. This prevents reproducible security verification and creates a supply-chain trust boundary between the audited Skill and the upstream repository. The repository path is consistent with the homepage declared by the Skill, so there is no evidence of typosquatting, dependency confusion, or currently malicious upstream code. The risk arises from installing future, unreviewed executable content. ### Attack Path 1. An attacker compromises the upstream repository, its release process, or a maintainer account, or publishes a malicious future release. 2. The mutable `@latest` selector resolves to the attacker-controlled release during installation. 3. The Go toolchain downloads and compiles the changed source code. 4. The resulting `blogwatcher` executable is installed into the user's Go binary directory. 5. When the agent or user invokes a documented command such as `blogwatcher scan`, the malicious code executes with the privileges of that user. ### Impact Assessment Successful exploitation could provide arbitrary code execution un ...[truncated 548 chars]
- Remediation
- ## Remediation Suggestions 1. Replace `@latest` with a specific, security-reviewed semantic version, for example: ```yaml "module":"github.com/Hyaxia/blogwatcher/cmd/blogwatcher@vX.Y.Z" ``` 2. Record the approved version in both the installation metadata and the human-readable installation instructions so they cannot diverge. 3. Prefer an immutable reviewed commit when stronger reproducibility is required. 4. Verify downloaded module checksums through the Go checksum database or an organization-controlled trusted proxy. 5. Review source changes and release provenance before updating the pinned version. 6. Use an automated dependency-update process that opens reviewed changes rather than silently resolving the newest upstream release during installation. 7. Where supported, verify signed releases or attestations and build the executable in a restricted environment with minimal credentials and filesystem access.