T08 · Insecure Dependencies
- Location
SKILL.md:74- Finding
Unpinned Third-Party Executable Installation
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:74(also reiterated atSKILL.md:260)
Vulnerability Type: Unpinned executable dependency
Risk Level: MediumVulnerable Code
bash go install golangci-lint/cmd/golangci-lint@latestThe dependency table reiterates the unsafe installation pattern:
markdown | golangci-lint | Command-line tool | Required | `go install ...@latest` |Technical Analysis
The skill instructs users or an executing agent to download, compile, and install the version currently resolved by the mutable
@latestselector. Because no immutable version is specified, the installed source can change without any modification to the reviewed skill.This prevents reproducible installation and makes it impossible to determine in advance which exact dependency revision will execute. The instruction also does not require checksum, signature, provenance, or release verification. If an upstream release, source repository, module-resolution path, or maintainer account is compromised, following this instruction could introduce attacker-controlled executable code.
The documented module path should additionally be replaced with the verified canonical module path published by the project.
Attack Path
- An attacker compromises the upstream package, release process, module-resolution path, or a maintainer account.
- A malicious release becomes the version resolved by
@latest. - A user or AI agent follows the installation instruction in
SKILL.md. - The Go toolchain downloads and compiles the uncontrolled dependency revision.
- The resulting executable is installed in the user's Go binary directory.
- When the linter is subsequently invoked, the malicious binary executes with the privileges and environment access of the invoking user or agent.
Impact Assessment
Successful exploitation could provide arbitrary code execution with the privileges of the user ...[truncated 584 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace
@latestwith a reviewed, immutable release version. - Use the project's verified canonical Go module path and confirm it against official project documentation.
- Document the expected checksum, signature, or provenance-verification process for downloaded releases.
- Prefer a trusted package manager or official release artifact with integrity verification where appropriate.
- Update the pinned version only through a reviewed dependency-update process.
- Keep the installation command and dependency table consistent.
Example hardened pattern:
bash go install <verified-canonical-module-path>@vX.Y.ZReplace
vX.Y.Zwith a specifically reviewed release rather than a mutable selector.- Replace
