T08 · Insecure Dependencies
Warning
- Location
- commands.md:36
- Finding
- Unpinned Third-Party Packages Executed Through npx## Vulnerability Details **File Location**: `commands.md`, lines 36, 46, and 55 **Vulnerability Type**: Supply-chain exposure through unpinned executable dependencies **Risk Level**: Medium ### Complete Code Snippet ```bash # commands.md:36 npx get-graphql-schema https://api.example.com/graphql > schema.graphql # commands.md:46 npx graphql-inspector diff old.graphql new.graphql # commands.md:55 npx graphql-inspector validate './src/**/*.graphql' schema.graphql ``` ### Technical Analysis The documentation recommends invoking third-party npm command-line packages with `npx` without specifying reviewed versions or requiring locally installed, lockfile-controlled copies. If a requested package is not already available locally, `npx` may retrieve and execute it from the configured npm registry. Consequently, the code that runs can change after this Skill has been reviewed. A compromised package release, transitive dependency, package-registry account, registry configuration, or package-resolution path could cause arbitrary package code to execute under the user's account. This behavior is not inherently malicious, and the examples are optional commands that users run themselves. Nevertheless, directly executing unpinned remote dependencies is unnecessary for the Skill's core documentation functionality and does not provide reproducible or integrity-controlled execution. ### Attack Path 1. A developer follows one of the documented `npx` examples. 2. The requested package is not available as a trusted local dependency. 3. `npx` resolves and downloads the package and its dependency tree from the configured registry. 4. An attacker has compromised the selected package release, a dependency, a maintainer account, or the registry-resolution path. 5. Malicious package lifecycle or CLI code executes with the developer's operating-system privileges. 6. That code can access resources available to the invoking account, subject to host-level sandboxing and permissions ...[truncated 869 chars]
- Remediation
- ## Remediation Suggestions 1. Add the reviewed tools as development dependencies with exact or tightly constrained versions, and commit the package-manager lockfile. 2. Invoke only the lockfile-resolved local binaries, such as through package scripts. 3. If retaining `npx`, use `npx --no-install` so execution fails rather than downloading an absent package. 4. Document the expected official package names and registry source to reduce dependency-confusion and registry-substitution risks. 5. Use lockfile integrity verification and reproducible installation commands such as `npm ci` in CI. 6. Apply dependency scanning and update review to the tools and their transitive dependencies. 7. Run schema-inspection tools in a restricted environment with minimal filesystem access, network access, and credentials. 8. Separate the examples by package where practical and identify a verified version for each command rather than presenting mutable registry resolution as the default.
