T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:5
- Finding
- Unpinned Node.js Dependencies Create a Supply-Chain Exposure<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 5 **Vulnerability Type**: `T08: Insecure Dependencies` **Risk Level**: Medium ### Vulnerable Code ```json "install":[ {"kind":"node","package":"ccxt"}, {"kind":"node","package":"technicalindicators"} ] ``` ### Technical Analysis The Skill requests installation of the `ccxt` and `technicalindicators` Node.js packages without specifying exact versions or integrity hashes. Consequently, installation may resolve to whatever package version is current at execution time rather than to an artifact reviewed alongside the Skill. Although the named packages are not demonstrated to be malicious, this configuration creates supply-chain risk. A compromised maintainer account, package registry, newly published malicious version, or vulnerable upstream release could cause unreviewed code to be installed. Package installation may also execute lifecycle scripts unless the package manager or runtime explicitly disables them. This risk is heightened because the Skill declares access to `EXCHANGE_API_KEY`, `EXCHANGE_API_SECRET`, and `SKILLPAY_API_KEY`. If installation or package execution occurs in a process that inherits these environment variables, a compromised dependency could read and transmit them. ### Attack Path 1. An attacker compromises an upstream package publisher, package release process, or registry distribution channel. 2. The attacker publishes a malicious release under one of the unpinned dependency names. 3. The Skill installation mechanism resolves the dependency to that malicious release because no exact version or integrity constraint is present. 4. Malicious lifecycle or runtime code executes with the permissions of the installing or running Agent process. 5. If sensitive environment variables are inherited, the malicious code reads the exchange or billing credentials. 6. The attacker may exfiltrate those credentials or use exchange credentials according to their assigned permis ...[truncated 917 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Pin each dependency to an exact, reviewed version rather than resolving the latest available release. 2. Maintain a lockfile containing registry-resolved integrity hashes and verify it during installation. 3. Use a trusted package registry and enforce package provenance or signature verification where supported. 4. Disable dependency lifecycle scripts during installation unless they are explicitly required and reviewed. 5. Install and execute dependencies in a sandbox with restricted filesystem and network access. 6. Prevent installation processes from inheriting exchange and billing secrets. Inject credentials only into the final runtime process and only when required. 7. Use exchange API keys restricted to the necessary trading pair and operations, with withdrawal permissions disabled. 8. Rotate credentials immediately if dependency integrity cannot be established or if an unexpected package version has already executed. 9. Add automated dependency vulnerability, provenance, and integrity scanning to the release process. ]]>