T08 · Insecure Dependencies
- Location
SKILL.md:14- Finding
Unpinned Third-Party CLI Dependency
- Content
View full analysis
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: MediumVulnerable 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
@latestversion 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
- An attacker compromises the upstream repository, a maintainer account, or another relevant part of the dependency publication chain.
- The attacker publishes malicious source code under a version selected by
@latest. - A user or automated skill installer follows the declared installation configuration or documented
go installcommand. - Go downloads and compiles the attacker-controlled dependency.
- The resulting
blogwatcherbinary is installed in the user's Go binary dire ...[truncated 777 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace
@latestwith a specific, reviewed semantic version or immutable commit identifier in both the metadata and installation instructions. - Establish a controlled dependency-update process that reviews upstream source changes before advancing the pinned version.
- Verify available module checksums through Go's checksum infrastructure and document any required trusted checksum-database policy.
- Where supported, verify signed releases, build provenance, and maintainer identity before accepting updates.
- Consider distributing a reproducibly built artifact with published cryptographic hashes and require hash verification before execution.
- Keep the metadata and human-readable installation command synchronized so neither path falls back to a mutable version selector.
- Replace
