T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:20
- Finding
- Unpinned npm Packages Are Executed Through npx## Vulnerability Details **File Location**: `SKILL.md:20-23`; additional occurrences in `README.md:10-13` and `README.md:35-38` **Vulnerability Type**: Unpinned third-party package execution through `npx` **Risk Level**: Medium ### Vulnerable Code `SKILL.md:20-23`: ```bash ## Quick Start No dependencies needed. Run directly: ```bash npx tsx {baseDir}/scripts/strikeradar.ts status ``` ``` `README.md:10-13`: ```bash ## Installation ```bash npx skills add alexpolonsky/agent-skill-strikeradar ``` ``` `README.md:35-38`: ```bash Or run it as a standalone CLI: ```bash npx tsx scripts/strikeradar.ts status ``` ``` ### Technical Analysis The documented installation and execution paths invoke the npm packages `skills` and `tsx` through `npx` without specifying exact versions or integrity constraints. Neither package is declared or locked in `package.json`, which contains no dependency list or lockfile-backed resolution. When a requested executable is not already installed locally, `npx` can resolve and download a package from the configured npm registry and immediately execute its package code. Because no version is pinned, the effective executable can change after this skill has been reviewed. A future compromised, malicious, or otherwise unsafe package release could therefore execute during skill installation or normal use. This is a supply-chain weakness rather than evidence that the currently resolved packages are malicious. Exploitation requires compromise of the relevant package, registry resolution, maintainer account, or package source. ### Attack Path 1. An attacker compromises the npm package or publishing account for `tsx` or `skills`, or otherwise influences package resolution through the user's npm registry configuration. 2. The attacker publishes a malicious version that contains executable package logic. 3. A user or agent follows the documented command without an already tru ...[truncated 1270 chars]
- Remediation
- ## Remediation Suggestions 1. Declare required runtime tooling in `package.json` using reviewed, exact versions rather than relying on unconstrained registry resolution. For example, pin `tsx` to an exact version without a caret or tilde. 2. Commit a lockfile generated by the selected package manager and require lockfile-enforced installation, such as `npm ci`, before execution. 3. Replace the documented `npx tsx ...` command with an invocation of the installed, lockfile-controlled executable, such as an npm script: ```json { "scripts": { "strikeradar": "tsx scripts/strikeradar.ts" }, "devDependencies": { "tsx": "REVIEWED_EXACT_VERSION" } } ``` Users can then run: ```bash npm ci npm run strikeradar -- status ``` 4. If `npx` must remain supported, specify an explicitly reviewed version and prevent silent alternative resolution. Version pinning reduces unexpected upgrades, although a committed lockfile and local installation provide stronger reproducibility. 5. Pin or otherwise verify the installer used in `npx skills add ...`; document its expected package identity and reviewed version. 6. Use a trusted npm registry, retain package integrity metadata, and incorporate dependency provenance, vulnerability, and publisher-change checks into release review. 7. Run installation and skill execution in a restricted environment with minimal filesystem access, no unnecessary credentials in environment variables, and limited outbound network permissions.
