T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:9
- Finding
- Unpinned Executable Go Dependency## Vulnerability Details **File Location**: `SKILL.md`, lines 9–14 **Vulnerability Type**: `T08: Insecure Dependencies` **Risk Level**: Medium **Complete Code Snippet**: ```yaml install: - kind: go module: github.com/openclaw/graincrawl/cmd/graincrawl@latest bins: - graincrawl ``` ### Technical Analysis The installation configuration retrieves executable Go code through the mutable `@latest` version selector. Consequently, the installed implementation can change after the skill has been reviewed without any corresponding change to this repository. If the upstream repository, release process, maintainer account, or dependency chain is compromised, a later installation could compile and execute attacker-controlled code. No immutable version, commit identifier, checksum, or provenance verification is specified here. ### Attack Path 1. An attacker compromises the upstream package, its release process, or a dependency selected during the Go build. 2. The attacker publishes a malicious version that becomes the version resolved by `@latest`. 3. A user or automated environment installs the skill dependency according to `SKILL.md`. 4. The Go tooling retrieves and compiles the altered package. 5. The documented `graincrawl` commands execute the malicious binary with the invoking process's permissions. 6. The binary can attempt to access the local Granola archive and other resources available to that account. ### Impact Assessment Successful exploitation would execute code with the privileges of the account running the installation or command. The documented functionality gives the binary legitimate access to potentially sensitive local Granola notes, transcripts, panels, desktop-cache data, and private-API synchronization workflows. A malicious build could therefore read, alter, destroy, or disclose data accessible to that account, subject to operating-system permissions and any sandboxing in place. ...[truncated 303 chars]
- Remediation
- ## Remediation Suggestions - Replace `@latest` with an audited, immutable release version or commit hash. - Prefer a version whose source and transitive dependency graph have been reviewed. - Verify downloaded artifacts using trusted checksums, signed releases, or build-provenance attestations. - Record expected checksums or provenance data in a controlled manifest and fail installation when verification does not succeed. - Use reproducible builds where practical and periodically scan the pinned dependency and its transitive dependencies. - Perform dependency upgrades through an explicit review process rather than resolving a mutable version during installation. - Run the resulting binary with least privilege and restrict its filesystem, network, credential-store, and private-API access to what the documented task requires.