T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:34
- Finding
- Third-Party CLI and SDK Packages Are Installed Without Integrity Verification<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:34-43`, `SKILL.md:1369-1387` **Vulnerability Type**: Supply-chain exposure caused by unverified third-party dependencies **Risk Level**: Medium ### Vulnerable Code ```bash npm install -g @maton/cli@0.3.1 ``` ```bash brew install maton-ai/cli/maton brew pin maton ``` ```bash pip install 'maton-ai==0.3.1' ``` ```bash npm install @maton/sdk@0.3.1 ``` The surrounding documentation states that the dependency versions are pinned, but it does not require verification of artifact signatures, package checksums, registry provenance, or lockfile integrity before installation. ### Technical Analysis The Skill instructs users or agents to obtain executable CLI and SDK packages from npm, PyPI, and a custom Homebrew tap. Version pinning reduces accidental upgrades but does not establish that the downloaded artifact is authentic or unchanged. Package installation may execute package-controlled installation hooks and place executable files in trusted command paths. The global npm installation is particularly sensitive because it modifies the user's global executable environment. The Homebrew command additionally trusts a vendor-controlled tap. If a publisher account, package registry, distribution channel, or tap is compromised, an attacker could replace the pinned artifact while retaining the expected package name and version. The audited project does not itself contain an embedded malicious payload, and there is no evidence that the named packages are currently malicious. The vulnerability is the absence of an integrity-verification boundary before externally supplied code is installed and executed. ### Attack Path 1. An attacker compromises the package publisher, registry entry, release infrastructure, or custom Homebrew tap used by one of the documented dependencies. 2. The attacker publishes or substitutes a malicious artifact under the documented package and version. 3. A user or agent follows the ...[truncated 1560 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Publish cryptographic checksums for every reviewed CLI and SDK artifact and require checksum verification before installation. 2. Sign release artifacts using a verifiable mechanism such as Sigstore, npm provenance attestations, or another documented package-signing process. 3. Document the expected registry namespace, publisher identity, package digest, and verification procedure. 4. Prefer isolated, non-global installation over `npm install -g` where practical. 5. Use lockfiles with integrity hashes for SDK dependencies and commit those lockfiles alongside executable projects. 6. For Homebrew, provide a versioned formula with a pinned source archive and SHA-256 checksum rather than relying only on `brew pin`. 7. Where compatible, acquire npm packages with lifecycle scripts disabled and inspect them before enabling any required scripts. 8. Run installation and initial verification in a minimally privileged container or sandbox without production credentials. 9. Establish a controlled upgrade process that validates signatures, checksums, provenance, and release notes before changing the reviewed version. ]]>