T08 · Insecure Dependencies
Warning
- Location
SKILL.md:26- Finding
Unpinned Third-Party CLI Execution and Unattended Global Skill Installation
- Content
View full analysis
]` - Search for skills interactively or by keyword, optionally scoped to a GitHub owner - `npx skills add ` - Install a skill from GitHub or other sources - `npx skills update` - Update all installed skills ``` Lines 88–94: ```markdown ### Step 6: Offer to Install If the user wants to proceed, you can install the skill for them: ```bash npx skills add -g -y ``` ``` ### Technical Analysis The skill instructs the agent to execute `npx skills` without pinning the CLI to a reviewed version or verifying its package integrity. By default, `npx` can resolve and execute a package from the npm registry if a suitable local copy is unavailable. Consequently, the code executed at audit time may differ from the code executed later. The installation instructions also accept GitHub packages or unspecified “other sources.” No requirement is imposed to pin skills to immutable commit hashes, verify signatures or checksums, inspect downloaded files, or constrain sources to an allowlist. The recommended installation command compounds this exposure: - `-g` installs the selected skill globally at the user level, increasing its reach across projects and future sessions. - `-y` suppresses confirmation prompts, reducing the opportunity to inspect the package, source, version, and requested changes. - The package reference is not pinned to an immutable revision. - Install counts, repository stars, and publisher reputation—although mentioned elsewhere in the document—do not provide code-integrity guarantees and cannot prevent repository compromise, malicious updates, dependency confusion, or account takeover. This is a supply-chain w ...[truncated 1979 chars]- Remediation
View remediation
skills`. - Use a lockfile and integrity metadata where the execution environment supports them. - Review every version update before changing the pin. 2. **Pin skills to immutable revisions** - Require an exact release artifact or Git commit SHA rather than a mutable branch, tag, or unversioned package reference. - Record the expected checksum or signature and verify it before installation. 3. **Restrict installation sources** - Establish an explicit allowlist of approved registries, GitHub organizations, repositories, and package owners. - Remove support for unspecified “other sources” unless they undergo equivalent verification. - Protect against lookalike names and typosquatting by validating the exact owner and repository identity. 4. **Review content before installation** - Download the candidate into an isolated temporary directory without executing it. - Inspect skill instructions, scripts, lifecycle hooks, dependencies, and configuration changes. - Scan the artifact for secrets, obfuscated code, external payload retrieval, destructive commands, and persistence mechanisms. 5. **Avoid unattended global installation** - Remove `-y` so the package identity, revision, source, and changes can be confirmed. - Avoid `-g` by default; prefer project-local or sandboxed installation with narrowly scoped permissions. - Require explicit, informed user authorization immediately before installation. 6. **Isolate execution** - Perform discovery and installation in a container or restricted environment without production credentials, SSH keys, sensitive environment variables, or broad filesystem access. - Deny network and filesystem access not required for the installation. 7. **Secure update behavior** - Do not use an ...[truncated 177 chars]