T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:5
- Finding
- Unpinned Third-Party CLI Installation## Vulnerability Details **File Location**: `SKILL.md`, lines 5 and 13 **Vulnerability Type**: `T08: Insecure Dependencies` **Risk Level**: Medium **Vulnerable 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 `things` executable. 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 1. An attacker compromises the upstream module repository, a maintainer account, or its release process. 2. The attacker publishes a malicious version that becomes the version selected by `@latest`. 3. A user or Agent follows the Skill installation instructions. 4. `go install` resolves and builds the attacker-controlled release. 5. The installed `things` executable is subsequently invoked for a legitimate-looking Skill operation. 6. The executable runs with the permissions of the invoking user or host appli ...[truncated 654 chars]
- Remediation
- ## Remediation Suggestions - Replace `@latest` with 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.
