T08 · Insecure Dependencies
Warning
- Location
- references/README.md:13
- Finding
- Security-Critical Functionality Is Delegated to an Unreviewed External Runtime and Dependency Installer## Vulnerability Details **File Location**: `references/README.md:13-51`; related invocation instructions in `SKILL.md:60-73, 130-159` **Vulnerability Type**: External runtime and dependency supply-chain risk **Risk Level**: Medium ### Vulnerable Code Snippets `references/README.md:13-51`: ```markdown 1. Get the `linkedin-automation-runtime-<version>` archive and its published `.sha256` digest from the maintainer's canonical release source: the GitHub Releases page of this project's repository (the same repository this skill package ships from) — never a third-party mirror, forum link, or unofficial re-upload, even if it claims to host the same archive. Prefer a specific pinned version over "latest" — treat any archive without a published digest, or one obtained from anywhere other than that canonical release page, as untrusted and do not install it. 2. Verify the archive **before** extracting it — a `cli.py` file existing inside is not itself a trust signal, only a shape check: ``` # Windows Get-FileHash linkedin-automation-runtime-<version>.zip -Algorithm SHA256 # macOS / Linux sha256sum linkedin-automation-runtime-<version>.zip ``` Compare that output against **two independent sources**, not just one: - the `.sha256` file published next to the archive, and - `expectedRuntimeSha256` in this skill's own `SKILL.md` frontmatter. These two are published through separate channels (the runtime's own distribution point vs. this skill package, reviewed and distributed through ClawHub) — a `.sha256` file sitting beside the archive proves nothing on its own if that whole channel is compromised, since an attacker who can swap the archive can swap the file next to it too. Only trust the archive if it matches **both**. If either doesn't match, stop — do not extract or run anything from that archive, and do not proceed assuming ...[truncated 4739 chars]
- Remediation
- ## Remediation Suggestions 1. Include the complete runtime source, installer scripts, and dependency manifests in the reviewable project or as a verifiable source submodule tied to the exact release commit. 2. Publish an explicit canonical repository and release URL rather than describing the source only as the project's GitHub Releases page. 3. Lock all direct and transitive Python dependencies to exact versions and require hashes, such as with a hash-locked requirements file. 4. Generate reproducible builds and publish provenance or signed attestations linking the reviewed source commit to the runtime archive and pinned SHA-256 digest. 5. Digitally sign releases using a separately protected signing identity and verify signatures in addition to checksums. 6. Extend runtime integrity verification beyond `cli.py` to imported modules, installer outputs, and dependency lockfiles, or verify a signed manifest covering the complete installed tree. 7. Replace broad installer execution with a documented, minimal installation process that does not require elevated privileges and runs in an isolated virtual environment. 8. Sandbox runtime execution under a dedicated low-privilege account or container. Mount only the required profile, resume, and log paths. 9. Enforce outbound network restrictions to `linkedin.com`, `www.linkedin.com`, and `api.anthropic.com`, while accounting for any explicitly documented browser support endpoints. 10. Restrict filesystem permissions on the Chrome profile, `.env`, application log, and runtime directory to the owning user. 11. Avoid exposing the API key globally; pass it only to the isolated runtime process and use a narrowly scoped, revocable credential where supported. 12. Preserve the existing version and digest fail-closed checks, as they are valuable defense-in-depth controls.