T08 · Insecure Dependencies
Warning
- Location
README.md:29- Finding
Unpinned npm Package Execution in Installation Instructions
- Content
View full analysis
/ ``` Anyone can install from **this repository’s address** on your Git host (GitHub `owner/repo`, a full repo URL, or another format the [Skills CLI](https://skills.sh/docs/cli) accepts). Use the `owner/repo` shown on the repo home page, for example: ```bash npx skills add OWNER/partnerboost-brand ``` Run `npx skills add --help` for flags such as `-g` / `--global` and `-a` / `--agent` (target Cursor, Claude Code, OpenCode, etc.). ``` ### Technical Analysis The documented command invokes `npx skills` without pinning the npm package to a reviewed version or integrity value. If the executable is not already available locally, `npx` can resolve and execute the package supplied by the configured npm registry. Consequently, the code executed during installation may differ from the version that was originally reviewed. Security depends on the continued integrity of the registry package, its publisher account, the user's registry configuration, and the repository identifier supplied to the command. The documentation does not specify an authoritative publisher, fixed package version, integrity hash, or repository revision. This is a supply-chain weakness rather than evidence that the current repository contains malicious code. ### Attack Path 1. An attacker compromises the package publisher, registry account, package distribution channel, or a registry used by the victim. 2. The attacker publishes or substitutes a malicious package version that exposes the expected `skills` executable. 3. A user follows the documented unpinned `npx skills add` command. 4. `npx` resolves the attacker-controlled package vers ...[truncated 965 chars]- Remediation
View remediation
add / ``` 2. Replace placeholders in the primary installation example with the exact authoritative repository owner and name. 3. Document the official npm package name, verified publisher, and expected registry. 4. Where supported, verify the package checksum, provenance, or registry signature before execution. 5. Pin the imported Skill to a reviewed commit hash or signed release rather than an unrestricted moving branch. 6. Advise users to inspect the resolved package and repository identity before approving execution. 7. Run installation with an unprivileged account and a minimal environment that does not expose unrelated secrets. 8. Keep the pinned version under periodic review and update it only after validating the new release. ]]>