T08 · Insecure Dependencies
- Location
SKILL.md:211- Finding
Unpinned Third-Party Dependency Installation
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, line 9 and lines 211–214
Vulnerability Type: Unpinned and mutable third-party dependencies
Risk Level: MediumVulnerable Code
yaml dependencies: [cellcog]text **Claude Code, Cursor, Codex + 70 more agents:** `npx skills add cellcog/skills --skill cellcog` **OpenClaw:** `openclaw skills install @cellcog/cellcog` **CellCog plugin users:** run `/cellcog-setup` (or `/cellcog:cellcog-setup` depending on your tool) **Manual setup:** `pip install -U cellcog` and set `CELLCOG_API_KEY`. See the **cellcog** skill for SDK reference.Technical Analysis
The Skill declares and recommends installing the external
cellcogdependency without an exact version, immutable source revision, integrity hash, lockfile, or signature-verification procedure. The manual Python command uses-U, explicitly requesting the latest available package version.Consequently, the code installed by these commands can change after the Skill has been reviewed. Package installation can execute package-controlled installation or runtime code that is not included in this project and was therefore outside the audit scope. This creates a supply-chain trust boundary in which compromise of the relevant registry account, package release, namespace, distribution infrastructure, or upstream repository could deliver unauthorized code.
There is no evidence in the reviewed project that the current dependency is malicious. The vulnerability arises from installing mutable, unaudited dependency content without integrity controls.
Attack Path
- An attacker compromises an upstream package, registry account, namespace, repository, or distribution channel used by one of the documented installation commands.
- The attacker publishes a malicious release under the expected dependency or Skill identity.
- A user or agent follows the instructions in
SKILL.md, such as running `pip ...[truncated 1223 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin every dependency to an exact, reviewed version rather than resolving the latest release.
- For repository-based installation, pin an immutable commit hash instead of a branch or mutable tag.
- Publish and verify cryptographic hashes for package artifacts. For Python installations, use a locked requirements file with hashes and enforce hash checking.
- Provide lockfiles or equivalent reproducible dependency manifests for each supported installation method.
- Remove
-Ufrom the default installation command so reviewed installations are not silently replaced by newer releases. - Document the authoritative package registry, publisher identity, and expected package provenance to reduce dependency-confusion and typosquatting risks.
- Verify package signatures or registry provenance attestations where supported.
- Audit each pinned dependency release, including installation hooks and transitive dependencies, before updating the documented version.
- Run installation and execution with least privilege in an isolated environment, exposing only required files, network destinations, and environment variables.
- Avoid placing unrelated credentials in the process environment when running the dependency, and rotate
CELLCOG_API_KEYif dependency compromise is suspected.
