T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:12
- Finding
- Unpinned Mutable Third-Party CLI Installation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 12-27 **Vulnerability Type**: Unpinned third-party executable dependency **Risk Level**: Medium ### Vulnerable Code ```yaml [ { "id": "brew", "kind": "brew", "formula": "steipete/tap/ordercli", "bins": ["ordercli"], "label": "Install ordercli (brew)", }, { "id": "go", "kind": "go", "module": "github.com/steipete/ordercli/cmd/ordercli@latest", "bins": ["ordercli"], "label": "Install ordercli (go)", }, ], ``` ### Technical Analysis The skill offers two installation methods for the `ordercli` executable, but neither identifies an immutable, reviewed artifact: - The Go installation explicitly uses the mutable `@latest` version selector. - The Homebrew installation references a third-party custom tap without pinning a package version, commit, checksum, or signature. The effective executable can therefore change after the skill has been reviewed. If the upstream repository, release process, Go module, or Homebrew tap is compromised, a future installation could retrieve and execute substituted code. This risk is especially relevant because the installed executable is subsequently trusted to process Foodora passwords, browser cookies, imported sessions, order history, delivery information, and cart-changing operations. The project contains only `SKILL.md`, so the implementation and security properties of the external executable could not be independently audited. ### Attack Path 1. An attacker compromises the upstream `ordercli` repository, release workflow, module publication process, or custom Homebrew tap. 2. The attacker publishes a malicious version or changes the package definition to reference a substituted artifact. 3. A user or agent installs the dependency through the document ...[truncated 1055 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Replace `@latest` with a reviewed, immutable version or commit, for example a specific semantic version backed by a fixed module checksum. 2. Pin the Homebrew installation to a reviewed release rather than implicitly accepting future formula changes. 3. Publish SHA-256 checksums for release artifacts and verify them before installation. 4. Sign releases using a verifiable mechanism such as Sigstore or GPG and enforce signature verification during installation. 5. Prefer an official, auditable package source over a custom tap where practical. 6. Add an explicit dependency-update process that requires security review before changing the pinned version or digest. 7. Run the CLI with least privilege and avoid exposing unrelated environment variables, files, browser profiles, or credentials to the process. 8. Document the exact reviewed dependency version and its expected integrity digest in the skill metadata. ]]>