T08 · Insecure Dependencies
- Location
SKILL.md:5- Finding
Unpinned Third-Party CLI Installation
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 5 and 13
Vulnerability Type:T08: Insecure Dependencies
Risk Level: MediumVulnerable Code Snippet:
yaml metadata: {"clawdbot":{"emoji":"✅","os":["darwin"],"requires":{"bins":["things"]},"install":[{"id":"go","kind":"go","module":"github.com/ossianhempel/things3-cli/cmd/things@latest","bins":["things"],"label":"Install things3-cli (go)"}]}}text - Install (recommended, Apple Silicon): `GOBIN=/opt/homebrew/bin go install github.com/ossianhempel/things3-cli/cmd/things@latest`Technical Analysis
The installation configuration and documentation use the mutable Go version selector
@latest. Consequently, the source code installed by this Skill can change after the Skill has been reviewed, without any corresponding modification to the package itself.This creates a supply-chain trust boundary around the upstream repository, its maintainers, release process, and transitive dependencies. If a future release is compromised or malicious, the installation command can produce an attacker-controlled
thingsexecutable. The resulting binary is then invoked to access the local Things database and perform task-management operations.No evidence was found that the currently referenced upstream project is malicious. The risk arises from accepting an unpinned future version rather than an immutable, reviewed release.
Attack Path
- An attacker compromises the upstream module repository, a maintainer account, or its release process.
- The attacker publishes a malicious version that becomes the version selected by
@latest. - A user or Agent follows the Skill installation instructions.
go installresolves and builds the attacker-controlled release.- The installed
thingsexecutable is subsequently invoked for a legitimate-looking Skill operation. - The executable runs with the permissions of the invoking user or host appli ...[truncated 654 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace
@latestwith a reviewed, explicit release version or immutable commit identifier in both the metadata and installation documentation. - Keep the metadata installation target and documented command synchronized.
- Verify the resolved Go module and transitive dependency checksums through the standard Go checksum database or an organization-controlled verification process.
- Record the expected source revision and binary provenance in release documentation.
- Establish a controlled dependency-update process that includes source review, changelog review, testing, and security scanning before changing the pinned version.
- Where practical, distribute a signed release artifact and verify its signature or cryptographic digest before installation.
- Replace
