Back to skill

Security audit

golang-code-review

Security checks for vulnerabilities and agentic risk

Overview

This Go code review skill is transparent and limited to code analysis, but some optional setup commands can install changing tool versions or rewrite local formatting.

Install only if Chinese-language documentation and output are acceptable. Prefer pinned tool versions instead of @latest, review diffs before running gofmt -w, and do not add the Git hook unless you want formatting/checks to run automatically on future commits.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T08 · Insecure Dependencies

Warning
Location
config.md:11
Finding
Unpinned Third-Party Tool Installation## Vulnerability Details **File Location**: `config.md`, lines 11–12 **Vulnerability Type**: Supply-chain risk caused by mutable dependency versions **Risk Level**: Medium **Vulnerable Code**: ```bash go install honnef.co/go/tools/cmd/staticcheck@latest go install golang.org/x/lint/golint@latest ``` ### Technical Analysis The recommended installation commands use the mutable `@latest` version selector. Consequently, users following the documentation may download and compile a different dependency version from the one reviewed during this audit. Although no malicious dependency is currently demonstrated, this installation pattern creates a supply-chain exposure because the effective code can change without any corresponding change to the Skill package. If an upstream project, release process, module distribution channel, or maintainer account is compromised, a malicious release selected by `@latest` could be compiled into a local executable. Go module checksum verification can detect inconsistent content for an already published module version, but it does not establish that a newly selected version is trustworthy. ### Attack Path 1. An attacker compromises an upstream dependency's release process or gains the ability to publish an unsafe version. 2. The unsafe release becomes the version resolved by `@latest`. 3. A user follows the installation instructions in `config.md`. 4. The Go toolchain downloads and compiles the newly selected source. 5. The user later invokes the installed analysis tool as recommended by the Skill. 6. Attacker-controlled behavior executes with the privileges and environmental access of that user. ### Impact Assessment Successful exploitation could execute arbitrary behavior under the installing user's account when the compromised tool is run. Depending on that user's privileges and environment, the malicious tool could read or alter accessible source repositories, files, credentials, and bu ...[truncated 171 chars]
Remediation
## Remediation Suggestions - Replace `@latest` with exact, reviewed versions, for example: ```bash go install honnef.co/go/tools/cmd/staticcheck@vX.Y.Z go install golang.org/x/lint/golint@vX.Y.Z ``` - Record the approved module versions and expected checksums in maintained project documentation or dependency-locking controls. - Review release notes, source changes, provenance, and maintainer authenticity before updating pinned versions. - Perform dependency updates through a controlled review process rather than resolving mutable versions during installation. - Where available, verify signed releases or trusted build provenance and install tools from a restricted, approved source. - Run analysis tools with least privilege and without unnecessary access to credentials or sensitive directories.
Vulnerability Patterns
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (4)

Natural-Language Policy Violations

Medium
Confidence
91% confidence
Finding
The skill documentation is entirely written as a Chinese-language skill description and labels the capability as a Chinese-language code review skill, but it does not state that language selection is optional or that the skill is limited to a Chinese-speaking audience for a documented reason. This can violate language/locale policy when users are not given an explicit opt-in or alternative language choice.

Natural-Language Policy Violations

Medium
Confidence
95% confidence
Finding
The rule labels and user-facing messages in this file are hard-coded in Chinese, and the CLI usage/output also assumes Chinese-only interaction. This creates a locale policy concern because the skill does not offer any language choice or document that it is intentionally limited to a Chinese-speaking context.

Intent-Code Divergence

Medium
Confidence
97% confidence
Finding
The comment at L113 states this function checks a specific rule, and the caller at L98-L99 iterates over rule IDs from rulesConfig. However, checkRule is declared as func checkRule(rule, content string, ...) at L114, so the switch at L116 actually evaluates the first parameter named rule, which the caller passes as string(content) at L99, not the rule ID. This contradicts the documented intent of rule-based checking.

Missing User Warnings

Low
Confidence
91% confidence
Finding
The markdown recommends commands that perform in-place formatting (`gofmt -w`) and even wires them into an automated Git hook without clearly warning that files will be modified. This can unexpectedly alter user files or working-tree state, which is risky in an agent/automation context because users may copy and run the commands without realizing they are destructive to local changes.

Static analysis

No suspicious patterns detected.