T08 · Insecure Dependencies
- Location
SKILL.md:14- Finding
Unpinned npm Dependency Is Installed and Executed
- Content
View full analysis
**Security**: Always install `@tryghost/ghst` from the official npm registry (`https://www.npmjs.com/package/@tryghost/ghst`). Consider pinning to a specific, reviewed version rather than relying on whatever version resolves at runtime (e.g., `npm install -g @tryghost/ghst@1.2.3`). Keep the package updated intentionally and review release notes before upgrading. ### Docker / Containerized Environments If you are running OpenClaw in Docker, ensure the `ghst` binary is included in your container image by adding the installation command to your `Dockerfile`: ```dockerfile RUN npm install -g @tryghost/ghst ``` ``` ### Technical Analysis The installation metadata, `npm install`, `npx`, and Docker examples all resolve `@tryghost/ghst` without specifying an exact reviewed version or package integrity value. Consequently, the code executed during installation or invocation can change after the Skill itself has been audited. The document acknowledges this risk and recommends considering version pinning, but the executable metadata and default examples remain unpinned. Installing from the official npm registry reduces dependency-confusion and typosquatting exposure, but it does not protect against a compromised maintainer account, malicious upstream release ...[truncated 1579 chars]- Remediation
View remediation
" command: "npx --yes @tryghost/ghst@" ``` 2. Update every npm, npx, and Docker example to use the same exact version: ```bash npm install -g @tryghost/ghst@ npx --yes @tryghost/ghst@ --help ``` 3. Use a lockfile and verified package integrity hashes where the deployment mechanism supports them. 4. Build and scan a fixed container image in a controlled pipeline rather than dynamically installing the latest package at runtime. 5. Disable unnecessary npm lifecycle scripts during installation where compatible: ```bash npm install --ignore-scripts -g @tryghost/ghst@ ``` If lifecycle scripts are required, inspect them before approving the package version. 6. Upgrade only through an explicit review process that verifies release notes, package provenance, published contents, and integrity metadata. ]]>
