T08 · Insecure Dependencies
- Location
SKILL.md:13- Finding
Unpinned Third-Party Executable Dependency
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 13–23
Vulnerability Type:T08: Insecure Dependencies
Risk Level: HighVulnerable Code Snippet:
yaml "openclaw": { "emoji": "👤", "requires": { "bins": ["sam-faces"] }, "install": [ { "id": "pip", "kind": "pip", "package": "sam-faces", "bins": ["sam-faces"], "label": "Install sam-faces from PyPI", }, ], },Related installation instructions at lines 50–58:
bash pip install sam-facesOr use the OpenClaw skill installer:
bash openclaw skills install sam-facesTechnical Analysis
The Skill installs and executes the
sam-facespackage from PyPI without specifying an exact version, package hash, signature, lockfile, or other integrity constraint. The external package supplies the executable that processes user images and writes data within the workspace.Because the dependency source is not included in the audited project, its implementation and the documentation claim that all processing remains local cannot be verified from this artifact. An unpinned dependency can also change after the Skill has been reviewed, causing later installations to execute code that differs from the reviewed behavior.
This finding does not establish that the current PyPI package is malicious. It identifies a supply-chain weakness that would permit a compromised publisher account, distribution channel, or future package release to introduce arbitrary executable behavior.
Attack Path
- An attacker compromises the package publisher, package distribution account, or another relevant supply-chain component.
- The attacker publishes a modified release under the expected
sam-facespackage name. - A user or OpenClaw installer runs the documented installation command without a version or hash constraint.
- The p ...[truncated 876 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin the dependency to a specifically reviewed version rather than installing the latest available release.
- Require cryptographic package hashes through a locked requirements file or an equivalent verified installation mechanism.
- Include audited source code in the project or link to an immutable source revision used to build the package.
- Verify package publisher identity, provenance, release signatures, and distribution metadata.
- Use reproducible builds and compare generated artifacts with trusted release hashes.
- Run the executable in a sandbox with network access disabled unless explicitly required.
- Restrict filesystem access to the specific input image, temporary directory, and face database required for the operation.
- Perform recurring dependency review and vulnerability scanning before updating the pinned release.
