T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:46
- Finding
- Automatic Execution of an Unreviewed Third-Party npm Package## Vulnerability Details **File Location**: `SKILL.md`, lines 46 and 70–76 **Vulnerability Type**: Third-party dependency and supply-chain risk **Risk Level**: Medium ### Vulnerable Code ```markdown - Any HTTP client, or no install at all via the official CLI (`npx -y sentisense@0.52.0`). Plain `curl` works, or Python 3.8+ using only the standard library (`urllib`, `json`); no third-party packages required. ``` ```bash npx -y sentisense@0.52.0 congress npx -y sentisense@0.52.0 congress NVDA npx -y sentisense@0.52.0 congress --days 30 --limit 50 npx -y sentisense@0.52.0 congress NVDA --json ``` ```markdown Auth: `SENTISENSE_API_KEY` in the environment, or store it once with `npx -y sentisense@0.52.0 auth "$SENTISENSE_API_KEY"` (saved to `~/.config/sentisense/`, file mode 600, local to your machine, removable with `auth --remove`). The version is pinned deliberately: a pinned version runs reviewed, immutable code. ``` ### Technical Analysis The documented `npx -y` commands automatically retrieve and execute the `sentisense` npm package, which is not included in this project and therefore could not be reviewed as part of the audited artifact. The `-y` option suppresses the installation confirmation that would otherwise provide a limited opportunity for users to notice that external code is about to run. Pinning the package to version `0.52.0` improves reproducibility but does not, by itself, establish that the package is trustworthy, locally reviewed, or cryptographically verified. The documentation's claim that pinning means the code is “reviewed, immutable” is not supported by anything in the audited project. The authentication command is particularly sensitive because the downloaded package executes while `SENTISENSE_API_KEY` is available both as a command-line argument and in the environment. The package is also instructed to write persistent configuration under the user's home directory. There is no evidence in t ...[truncated 1611 chars]
- Remediation
- ## Remediation Suggestions 1. Prefer the documented `curl` workflow because it avoids executing third-party package code and is sufficient for the skill's read-only API operations. 2. If the CLI is necessary, vendor its reviewed source into a controlled repository or provide a separately auditable package artifact. 3. Verify downloaded artifacts against a trusted cryptographic digest or signed provenance record before execution. Do not rely solely on a version number. 4. Remove `-y` from the recommended `npx` commands so package retrieval is not silently approved. 5. Install dependencies through a reviewed lockfile using integrity metadata and a trusted registry configuration. 6. Audit the CLI's direct and transitive dependencies, installation lifecycle scripts, network behavior, and credential-handling implementation. 7. Avoid passing secrets as command-line arguments. Read the key from a narrowly scoped environment variable or protected standard input, and prevent it from appearing in shell history or process listings. 8. Use a dedicated, least-privilege API key that can be rotated and cannot perform operations beyond the required read-only API access. 9. If local credential storage remains supported, document the exact file, enforce owner-only permissions, avoid plaintext storage where a platform credential manager is available, and provide key revocation guidance. 10. Replace the unsupported assertion that pinned npm code is “reviewed, immutable” with an accurate explanation of pinning's limited reproducibility benefit and the remaining supply-chain risk.