T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:29
- Finding
- Unverified Third-Party CLI Installation Creates a Supply-Chain Execution Risk<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:29-44` **Vulnerability Type**: Unverified third-party executable dependency installation **Risk Level**: Medium ### Vulnerable Code ```markdown ## Installation ### NPM ```bash npm install -g @maton/cli@0.3.1 ``` ### Homebrew ```bash brew install maton-ai/cli/maton brew pin maton ``` Versions are pinned to the release this skill was reviewed against. Upgrade deliberately - check the release notes, then move the pin - rather than by re-running an unpinned install. Homebrew cannot select a version from a tap, so `brew pin maton` holds the installed build until you choose to upgrade; `maton-ai/cli` is Maton's own tap. ``` ### Technical Analysis The Skill directs users to install executable third-party software globally through npm or from a vendor-controlled Homebrew tap. Although the npm dependency is pinned to version `0.3.1` and the Homebrew package is pinned after installation, version pinning alone does not establish artifact integrity or provenance. The repository does not include the dependency source, a package lockfile, cryptographic checksums, signature-verification instructions, or reproducible-build metadata. Consequently, the executable behavior of the installed CLI cannot be verified from the audited project. A compromised package registry account, release artifact, distribution channel, or custom Homebrew tap could replace the expected binary or package with attacker-controlled code. The risk is elevated because the installed CLI is subsequently trusted to manage OAuth sessions, API keys, OS credential-store interactions, Notion connections, hosted functions, and trigger destinations. This finding does not establish that the currently referenced packages are malicious; it identifies an insufficiently verified supply-chain trust boundary. ### Attack Path 1. An attacker compromises the npm publisher account, package release process, Homebrew tap, or an associated distributio ...[truncated 1718 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. **Publish verifiable artifacts** - Provide SHA-256 or stronger cryptographic hashes for every supported package and binary. - Sign releases using a documented signing identity. - Require signature and checksum verification before installation. 2. **Provide dependency provenance** - Link the package to publicly reviewable source code corresponding exactly to version `0.3.1`. - Publish reproducible-build instructions and software bill of materials metadata. - Use registry provenance or equivalent attestations to bind artifacts to the expected source and build workflow. 3. **Avoid global installation where possible** - Recommend an isolated container, virtual environment, or dedicated unprivileged account. - For npm, prefer a project-local dependency with a lockfile and integrity fields over `npm install -g`. - Warn users not to install or run the package with administrator or root privileges. 4. **Harden the Homebrew path** - Pin the formula to a specific immutable artifact. - Verify the formula's artifact checksum and release signature. - Document the exact expected tap owner, formula revision, and checksum before installation. 5. **Reduce credential exposure** - Continue preferring OS-backed credential storage and OAuth over long-lived API keys. - Ensure the CLI cannot export stored credentials and redacts sensitive headers and response fields. - Run dependency scanning and release-artifact verification before updating the documented version. 6. **Document the residual trust boundary** - State clearly that the CLI is external executable software not contained in the Skill. - Require deliberate user approval before installation rather than treating installation as an automatic prerequisite. ]]>
