T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:27
- Finding
- Unpinned Third-Party Package Installation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 27-55 **Vulnerability Type**: Unpinned third-party dependencies and globally installed executable package **Risk Level**: Medium ### Vulnerable Code ```bash npm install @thisispamela/sdk # or: yarn add @thisispamela/sdk # or: bun add @thisispamela/sdk ``` ```bash pip install thisispamela ``` ```bash npm install @thisispamela/react @thisispamela/sdk # or: bun add @thisispamela/react @thisispamela/sdk ``` ```bash npm install -g @thisispamela/cli ``` ```bash npm install @thisispamela/mcp ``` ```bash npm install @thisispamela/widget ``` ### Technical Analysis The installation commands do not pin dependencies to exact, reviewed versions and do not provide lockfiles or integrity hashes. They therefore resolve package versions from external registries at installation time. The effective code installed can change after this skill has been reviewed. The globally installed CLI is particularly sensitive because it places executable third-party code in the user's global environment. Depending on the package manager configuration, package installation hooks may also execute with the installing user's privileges. The document identifies official package names and advises users to avoid typosquatting, but the package source code is not included in this project and could not be audited. No evidence establishes that the currently published packages are malicious; the risk arises from mutable, unpinned supply-chain inputs. ### Attack Path 1. An attacker compromises a publisher or registry account, or introduces a malicious future release into the dependency chain. 2. A user follows one of the unpinned installation commands in `SKILL.md`. 3. The package manager resolves the compromised release because no exact version or integrity constraint is specified. 4. Malicious package installation hooks or runtime code execute with the privileges of the installing user. 5. The compromised package may acce ...[truncated 917 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Pin every package to an exact, reviewed release, such as `@thisispamela/sdk@1.2.0` and `thisispamela==1.2.0`, rather than relying on mutable latest-version resolution. 2. Supply and maintain lockfiles for supported JavaScript package managers, using immutable installation modes such as `npm ci` where applicable. 3. Publish expected package integrity hashes or package signatures and document a verification procedure. 4. Avoid global CLI installation where possible. Prefer a project-local, exactly pinned CLI invoked from the local dependency directory. 5. Review package contents, transitive dependencies, and installation scripts before approving version updates. 6. Disable package lifecycle scripts during installation when they are unnecessary and compatibility has been verified. 7. Use restricted API keys, apply least privilege, avoid exposing production credentials to installation processes, and rotate credentials if dependency compromise is suspected. 8. Document a controlled update process that includes provenance checks, security review, and dependency vulnerability scanning. ]]>
