T08 · Insecure Dependencies
- Location
SKILL.md:170- Finding
Execution of an Unpinned and Mutable npm Dependency
- Content
View full analysis
npm install -g @dlazy/cli@latest ``` The dependency table repeats the unsafe global installation command at line 291: ```bash npm install -g @dlazy/cli@latest ``` ### Technical Analysis The Skill directs users or agents to download and execute the mutable `latest` release of `@dlazy/cli`. No exact version, lockfile, package integrity hash, verified publisher identity, or provenance requirement is supplied. The `npx` form can download and immediately execute package code. The global installation form also installs package-controlled executables into the user's environment. Because the `latest` tag can point to a different artifact after this Skill has been audited, the effective code executed by the Skill is not fixed by the reviewed project. This creates a supply-chain risk if the package, publisher account, registry resolution, or a future release is compromised. The audit did not establish that the current package is malicious; the vulnerability is the unsafe dependency retrieval and execution policy. ### Attack Path 1. An attacker compromises the npm package publisher, package repository, release process, or registry resolution path. 2. The attacker publishes a malicious version of `@dlazy/cli` and assigns it the `latest` tag. 3. An agent or user follows the Skill instructions and invokes `npx @dlazy/cli@latest` or installs the package globally. 4. npm downloads the attacker-controlled package. 5. Package lifecycle code or the installed CLI executes with the invoking user's privileges. 6. The malicious dependency may access files available to that user, read the configured dlazy API credential, modify user-owned data, or make arbitrary network requests. ### Impact Assessment Successful ...[truncated 565 chars]- Remediation
View remediation
``` 2. Verify the pinned version independently and update it only through a documented security review process. 3. Publish and verify the expected package integrity hash and package provenance. 4. Explicitly require the official npm registry and document the expected package publisher. 5. Prefer a project-local installation governed by a lockfile over a global installation. 6. Disable or carefully review package lifecycle scripts where operationally possible. 7. Run the dependency in a restricted environment with only the required filesystem paths, environment variables, and network destinations available. 8. Avoid exposing unrelated credentials to the CLI process. ]]>
