T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:4
- Finding
- Unverified Third-Party npm Package Installation and Execution<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:4, 52-65`; `SKILL-cn.md:4, 52-65` **Vulnerability Type**: Third-party supply-chain exposure without artifact integrity verification **Risk Level**: Medium ### Vulnerable Code Snippets The English Skill metadata declares installation and execution of a package retrieved from npm: ```json "install":"npm install -g @dlazy/cli@1.2.3", "installAlternative":"npx @dlazy/cli@1.2.3" ``` The English instructions also recommend directly retrieving and executing the package: ```bash npx @dlazy/cli@1.2.3 <command> ``` ```bash npm install -g @dlazy/cli@1.2.3 ``` The Chinese Skill contains the same installation metadata and commands: ```json "install":"npm install -g @dlazy/cli@1.2.3", "installAlternative":"npx @dlazy/cli@1.2.3" ``` ```bash npx @dlazy/cli@1.2.3 <command> ``` ```bash npm install -g @dlazy/cli@1.2.3 ``` ### Technical Analysis The audited project contains only Skill documentation and metadata; it does not include the source code of `@dlazy/cli` or a cryptographic integrity value for the expected npm artifact. The Skill therefore delegates its sensitive runtime behavior to code downloaded from an external package registry. Pinning the package to version `1.2.3` reduces accidental version drift, but it does not independently authenticate the package contents or its transitive dependencies. The available files also provide no lockfile, software bill of materials, package signature, or reproducible checksum against which the downloaded artifact can be verified. Both installation methods can execute externally supplied code. npm packages may execute lifecycle scripts during installation, while `npx` retrieves and runs the package. The global installation option additionally persists the executable outside the Skill directory. No evidence was found in the audited files that the named package is currently malicious. The confirmed issue is the unverified trust boundary: the Skill instructs th ...[truncated 1761 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. **Provide artifact integrity verification** - Publish a SHA-256 or stronger checksum for the exact npm package tarball. - Verify the downloaded artifact against that checksum before installation or execution. - Prefer registry or provenance signatures supported by the package-distribution platform. 2. **Make dependency contents auditable** - Bundle the required implementation with the Skill when practical, or vendor a reviewed release. - Include a lockfile covering all transitive dependencies. - Publish a software bill of materials for the exact CLI release. - Provide reproducible build instructions so users can compare the distributed artifact with the public source repository. 3. **Reduce installation risk** - Prefer a project-local, isolated installation over `npm install -g`. - Avoid elevated privileges when installing or running the package. - Disable npm lifecycle scripts where compatible with the package, and document any scripts that are strictly required. - Execute the CLI in a sandbox or container with narrowly scoped filesystem and network access. 4. **Protect credentials and local files** - Grant the CLI access only to files explicitly selected for upload. - Keep the API key in a restricted credential store rather than exposing it broadly through the environment. - Ensure `~/.dlazy/config.json` has user-only permissions and document key rotation and revocation procedures. - Restrict outbound traffic to the documented service endpoints where feasible. 5. **Strengthen release governance** - Require multi-factor authentication and protected publishing workflows for the npm publisher account. - Use automated dependency scanning and provenance validation for every release. - Document a process for revoking compromised releases and notifying Skill users. ]]>