T08 · Insecure Dependencies
- Location
SKILL.md:46- Finding
Silent Global Installation of Insufficiently Verified Third-Party Tools
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 46-59
Vulnerability Type: Supply-chain risk through unpinned and insufficiently verified tool installation
Risk Level: MediumVulnerable Code
markdown ## Tool Auto-Installation If a tool required to complete any step is not installed on the current machine, apply the following policy before asking the user: 1. **Check availability** — verify whether the tool is missing (e.g. `where tool` or `which tool` returns nothing) 2. **Assess risk** — a tool is considered low-risk if it is: - Publicly available (official npm package, well-known CLI, OS package manager) - Widely used and maintained (e.g. `npm-check-updates`, `snyk`, `yarn`, `pnpm`) - Non-destructive by default (does not modify system files, does not require elevated permissions) 3. **Auto-install if low-risk** — install silently without asking the user: - npm global tool: `npm install -g <tool>` - winget (Windows): `winget install <tool>` - Other package managers as appropriate for the OS 4. **Ask the user if high-risk** — if the tool requires admin rights, modifies system config, or is from an unverified source, show the install command and ask for confirmation before proceeding.Technical Analysis
The skill instructs the agent to install tools silently and globally when they are subjectively classified as “low-risk.” Its validation criteria do not require an exact canonical package identity, trusted repository, pinned version, integrity digest, publisher signature, or independent verification of the package source.
The unrestricted
<tool>placeholder and authorization to use “other package managers” make the set of installable components open-ended. Public availability and apparent popularity are not sufficient supply-chain controls: a package may be typosquatted, dependency-confused, renamed, transferred to a malicious maintainer, or compromised after becoming established.F ...[truncated 2026 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove silent auto-installation and require explicit user approval before installing any missing tool.
- Display the exact package name, publisher, registry or repository, version, installation scope, and full command before requesting approval.
- Maintain a restrictive allowlist mapping supported tools to canonical package identifiers and trusted sources.
- Pin each dependency to a reviewed version rather than resolving an unconstrained latest release.
- Verify package signatures, checksums, provenance attestations, or registry integrity metadata where supported.
- Prefer project-local or isolated ephemeral installation over global installation so the tool cannot unexpectedly affect unrelated projects or future sessions.
- Review transitive dependencies and package lifecycle scripts before installation. Disable lifecycle scripts where feasible and only enable them after review when required.
- Do not infer package identity directly from a missing executable name, because executable and package names may differ and can be spoofed.
- Require separate confirmation for elevated installation, system-wide modification, unverified publishers, custom registries, and operating-system package managers.
- Record the selected package, source, version, integrity information, approval, and installation result in the workflow report.
