T08 · Insecure Dependencies
Warning
- Location
SKILL.md:30- Finding
Unpinned npm Packages Are Downloaded and Executed
- Content
View full analysis
[--json]` (fetched from npm; needs only Node) - Local script: `node scripts/validate.js ` (needs the `yaml` package — the repo's `npm install` covers it) ``` ```markdown 1. **Validate** — `npx skill-validator-omni ` (or `node scripts/validate.js `). Read the PASS/FAIL report. Add `-s ` to run one standard (repeatable; `--list-standards` shows names; `--all` is the default). 2. **Fix failures** — each check prints the offending detail; fix frontmatter/structure and re-run until exit 0. 3. **CI gate** — `npx skill-validator-omni --json | jq -e '.ok'` (JSON report, exit 1 on failure). 4. **Verify installability for publish** — `npx skills add / --list -y` must list your skills; for Claude, confirm the marketplace/plugin layouts above. ``` ```markdown - **`yaml` package missing** — install deps: `npm install` in the skill-validator-omni repo, or use the published CLI which bundles it ``` ### Technical Analysis The documented primary workflow invokes npm packages through `npx` without specifying exact versions. When the requested package is not already available locally, `npx` can resolve the current package release from the npm registry, download it, and execute its CLI. Consequently, the code that runs may differ from the version reviewed in this audit. The `npx skills add` verification command has the same supply-chain exposure. In addition, the project does not include a `package.json` or lockfile that constrains the stated `yaml` dependency or provides reproducible dependency resolution for the local workflow. This is a supply-chain weakness rather than evidence that the currently supplied validator script is malicious. The reviewed `scrip ...[truncated 1768 chars]- Remediation
View remediation
npx --yes @ add / --list -y ``` 2. Confirm the correct package name and reviewed version for the `skills` CLI rather than relying on ambiguous registry resolution. 3. Prefer the bundled local validator when possible: ```bash node scripts/validate.js ``` 4. Add a reviewed `package.json` that pins `yaml` to an exact version and commit the generated lockfile. Use reproducible installation in automation: ```bash npm ci ``` 5. Review and verify lockfile integrity entries before release. Configure automated dependency monitoring while requiring manual review before version updates. 6. In CI, install dependencies in an isolated, least-privileged environment with minimal filesystem access, no unnecessary deployment credentials, restricted network access, and read-only source mounts where practical. 7. Consider publishing checksums, signed release provenance, or npm provenance attestations for the expected CLI artifact. Document how users can verify the package identity before execution. 8. Update all examples consistently; leaving even one unpinned `npx` command preserves the vulnerable execution path. ]]>