T08 · Insecure Dependencies
- Location
SKILL.md:19- Finding
Unpinned Third-Party Dependencies Are Installed and Executed
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a straightforward testing guide with disclosed commands; its main risk is that some example installs and npx commands are not version-pinned.
Before using the commands, prefer project-local pinned devDependencies, committed lockfiles, and npm/uv frozen install workflows. Run tests in a least-privileged development or CI environment without production secrets when possible.
SKILL.md:19Unpinned Third-Party Dependencies Are Installed and Executed
The skill instructs users to invoke Vitest via npx without pinning an exact package version. If the dependency is absent locally or a compromised/transitively changed version is resolved, this can result in execution of unexpected code from the package registry, which is a supply-chain risk.
The npx vitest run command relies on whatever version npx resolves at execution time unless a local pinned installation already exists. That creates a supply-chain exposure where an unexpected or malicious package version could be fetched and executed.
Using npx vitest --coverage without an exact version allows non-deterministic package resolution and possible remote package execution. In a skill meant to be copied and run by users, that increases the practical exploitability of a registry compromise or typo/package confusion issue.
npx jest may execute an unpinned version resolved at runtime, exposing users to supply-chain tampering if the package source is compromised or if the tool is not already installed locally. Because this is instructional content, users may run it directly without understanding the trust implications.
The npx jest --watch example inherits the same risk of unpinned package execution through npx. If runtime resolution pulls a different version than expected, arbitrary package code may run on the developer machine.
npx jest --coverage is a true supply-chain risk because the skill recommends executing a package manager-resolved binary without pinning a version. The exposure is amplified by the fact that testing tools often run in developer environments with access to source code and secrets.
The single-file test command still depends on unpinned npx jest resolution, so it carries the same arbitrary code execution risk through package retrieval. The content is not overtly malicious, but it normalizes unsafe execution practices.
npx playwright install can download and execute package-managed tooling without an exact version being specified. This is a realistic supply-chain concern because Playwright commands may also trigger browser binary downloads, increasing trust placed in remote artifacts.
The npx playwright test command is unpinned and may fetch or run an unexpected version at execution time. Since test runners execute project code and often access credentials, the downstream impact of a compromised package can be significant.
npx playwright test --headed has the same unpinned resolution problem as the other Playwright examples. The risk is contextualized by this being a test-runner skill: users are likely to run these commands directly on development workstations or CI agents.
The debug-mode Playwright command still causes unpinned package execution through npx, which is a known supply-chain anti-pattern. Debug workflows can also expose sensitive data or tokens during interactive runs if the package is malicious.
Specifying a browser project does not reduce the underlying issue: npx playwright test --project=chromium remains an unpinned runtime package invocation. A compromised package would still execute with the privileges of the user or CI job running tests.
npx playwright show-report is also subject to unpinned package resolution and arbitrary code execution risk. Even though it appears read-only, invoking the CLI still executes package code from the resolved version.
The coverage command npx vitest --coverage repeats the same unsafe unpinned execution pattern later in the file. Repetition in a how-to skill increases the chance users adopt the pattern broadly across projects.
npx jest --coverage remains a true positive because it encourages runtime resolution of an unpinned executable package. In developer and CI contexts, malicious package execution could expose source code, environment variables, and repository credentials.
No suspicious patterns detected.