golang-modernize

• Outcome: Pass
• Latest audit: Sep 15, 2026 · 12:07 AM UTC
• Version: 1.3.0

Overview

This skill is a disclosed Go modernization helper with broad but purpose-aligned code review, editing, tooling, and worktree capabilities.

Install this if you want an agent to suggest or apply Go modernization changes. Use explicit full-scan mode for repository-wide work, review any generated worktree before merging, and approve toolchain or dependency updates only after checking the resolved versions and changelogs.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T08 · Insecure Dependencies

Warning

• Location: references/tooling.md:17

Finding

Unpinned Remote Retrieval of Executable Go Tooling

Content

View full analysis

Vulnerability Details

File Location: references/tooling.md:17, references/tooling.md:32, references/versions.md:454-455, and references/versions.md:473
Vulnerability Type: Unpinned executable dependency and toolchain retrieval
Risk Level: Medium

Vulnerable Code

From references/tooling.md:

bash

# Update toolchain
go get toolchain@latest

bash

# Pin in the module (Go 1.24+)
go get -tool golang.org/x/vuln/cmd/govulncheck@latest

From references/versions.md:

bash

go get -tool golang.org/x/tools/cmd/stringer@latest
go get -tool github.com/golangci/golangci-lint/v2/cmd/golangci-lint@latest

The same file also recommends:

text

Use `go install tool` to install all module-pinned tools when needed and `go get -u tool` to update them deliberately.

Technical Analysis

The Skill recommends retrieving compiler and developer-tool executables using mutable selectors such as @latest and the broad update command go get -u tool. These selectors do not identify an immutable, previously reviewed release. Consequently, the effective executable payload may change after the Skill itself has been audited.

The referenced package namespaces appear legitimate, and the audit found no evidence that the listed upstream projects are malicious. Nevertheless, relying on mutable upstream content creates a supply-chain trust boundary. A compromised upstream account, malicious release, compromised module proxy, or unexpectedly breaking update could cause attacker-controlled or unsafe code to enter the target project's tool dependency graph.

These installation and update operations are not required merely to inspect a project or recommend modernization. Automatically applying them would therefore exceed the minimum privileges needed for read-only analysis. They also modify go.mod, go.sum, or the selected Go toolchain and may later result in downloaded code being executed by go tool, lint, test, or build commands.

...[truncated 1775 chars]

Remediation

View remediation

Remediation Suggestions

1. Replace every @latest selector with an explicitly reviewed version, for example:

   bash

   go get toolchain@go1.26.1
   go get -tool golang.org/x/vuln/cmd/govulncheck@v1.1.4
   go get -tool golang.org/x/tools/cmd/stringer@v0.38.0
   go get -tool github.com/golangci/golangci-lint/v2/cmd/golangci-lint@v2.6.2
   

   The versions above are illustrative; maintainers should select releases that they have actually reviewed and tested.

2. Preserve resolved module checksums in go.sum and review all changes to go.mod and go.sum before executing newly added tools.

3. Do not automatically run installation or update commands during a read-only modernization scan. Present proposed changes and require explicit user approval before modifying the toolchain or dependency graph.

4. Replace broad updates such as go get -u tool with individual, version-specific updates. Review release notes, provenance, checksums, and transitive dependency changes for each update.

5. Run newly retrieved tools in a restricted environment with:

   • Minimal filesystem access.
   • No unnecessary credentials or secrets.
   • Restricted outbound network access.
   • No elevated operating-system privileges.
   • An isolated worktree or disposable container.

6. Separate update discovery from installation. A check may report that a newer version exists, but installation should occur only after review and approval.

7. Prefer trusted Go module proxies and configure checksum database verification where organizational policy permits. Avoid untrusted custom proxies or disabled checksum validation.

8. Document rollback procedures and run the complete test suite after approved toolchain or tooling changes.

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Vague Triggers

Medium

• Category: Not specified by scanner
• Confidence: 93% confidence

Finding

The trigger description says the skill should activate proactively during normal Go coding, code review, deprecation warnings, version upgrades, and CI/tooling refreshes. That broad scope can cause the skill to run outside explicit user intent, increasing the chance of unsolicited repo-wide scans, lint/test execution, web lookups, or follow-on edits in unrelated work. In this skill, that risk is amplified because it explicitly allows Bash, Agent orchestration, worktree operations, and codebase-wide modernization flows.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium

• Category: Not specified by scanner
• Confidence: 87% confidence

Finding

The inline-mode behavior is contextually triggered 'while the developer is working on something else' and only asks once whether to suggest modernization opportunities. This is insufficiently scoped because the skill still invites unsolicited intervention and includes language encouraging persuasion ('TRY TO CONVINCE your human'), which can pressure users into unrelated changes and expand activity beyond the active task. Given the allowed tools and full-scan/worktree capabilities elsewhere in the skill, ambiguous inline activation raises the risk of task hijacking and unnecessary codebase churn.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.