Skip to content
skillsafebeta
← Report library
Purpose / Other

Golang Dependency Management Skill Security Audit

What the author says it does (original text)

Dependency management for Golang projects — go.mod and go.sum, `go get` install and upgrade flows, Minimal Version Selection, conflict resolution with replace/exclude/retract, `govulncheck` scanning of the module tree, outdated dependency and binary size auditing, vendoring, `tool` directives, and go.work workspaces. Use when adding, removing, or upgrading Go dependencies, deciding whether to take

Independent security check

Security risks found

Files checked
8
Risks found
5
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.Risks found: 1
Medium risk

Installing and running unpinned latest tools creates mutable supply-chain execution risk

Source references: 4
What we found

The installation metadata and project-tool examples use `@latest`, then instruct the agent to execute the downloaded programs through `go tool` or PATH. The same command can retrieve different code over time and cannot be predicted from a reviewed fixed version.

Why this matters

If an upstream release, account, or module delivery path is compromised or defective at installation time, code may run with the agent's file and environment access.

The skill actively installs `govulncheck@latest` and permits the agent to execute it. Its tool-pinning flow likewise resolves `@latest` before running the result with `go tool`. The initially selected code can therefore change over time and may be downloaded and executed before the user reviews a concrete version. Users can require an explicit version and review its source plus go.mod/go.sum changes before execution.

SKILL.md:17In the instructionsOpen original file
        - govulncheck    install:      - kind: go        package: golang.org/x/vuln/cmd/govulncheck@latest        bins: [govulncheck]allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent Bash(govulncheck:*) AskUserQuestion
Show 3 other places
SKILL.md:114In the instructionsOpen original file
```bash# Add tools to the current module.go get -tool github.com/golangci/golangci-lint/v2/cmd/golangci-lint@latestgo get -tool golang.org/x/vuln/cmd/govulncheck@latestgo get -tool golang.org/x/perf/cmd/benchstat@latest# Run pinned tools reproducibly.go tool golangci-lint run ./...go tool govulncheck ./...go tool benchstat old.txt new.txt
SKILL.md:21In the instructionsOpen original file
        bins: [govulncheck]allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent Bash(govulncheck:*) AskUserQuestion---
SKILL.md:115In the instructionsOpen original file
```bash# Add tools to the current module.go get -tool github.com/golangci/golangci-lint/v2/cmd/golangci-lint@latestgo get -tool golang.org/x/vuln/cmd/govulncheck@latestgo get -tool golang.org/x/perf/cmd/benchstat@latest# Run pinned tools reproducibly.go tool golangci-lint run ./...go tool govulncheck ./...go tool benchstat old.txt new.txt
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.No risks found
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.Risks found: 2
Medium risk

Existing dependency upgrades are labeled safe, allowing broad dependency rewrites without per-change approval

Source references: 4
What we found

The Skill calls `go get -u` upgrades safe and documents a command that upgrades every direct and indirect dependency. Although it later recommends patch-only updates and tests, the earlier rule can authorize a broad mutation first.

Why this matters

go.mod, go.sum, and build behavior may change widely. Behavioral changes in minor or indirect dependencies can reach untested product paths.

The risk comes from calling `go get -u` for existing dependencies “safe” while an example explicitly upgrades all direct and indirect dependencies. Later guidance mitigates this by preferring patch-only updates and requiring review, tests, and scanning, but the earlier wording could still be read as permission for broad unconfirmed changes. Users can restrict upgrades to patch releases and require a proposed version list and diff first.

SKILL.md:34In the instructionsOpen original file
**Before running `go get` to add any new dependency, AI agents MUST ask the user for confirmation.** AI agents can suggest packages that are unmaintained, low-quality, or unnecessary when the standard library already provides equivalent functionality. Using `go get -u` to upgrade an existing dependency is safe.
Show 3 other places
SKILL.md:83In the instructionsOpen original file
### Upgrading```bashgo get -u ./...            # Upgrade ALL direct+indirect deps to latest minor/patchgo get -u=patch ./...      # Upgrade to latest patch only (safer)go get github.com/pkg@v1.5 # Upgrade specific package```
SKILL.md:32In the instructionsOpen original file
## AI Agent Rule: Ask Before Adding Dependencies**Before running `go get` to add any new dependency, AI agents MUST ask the user for confirmation.** AI agents can suggest packages that are unmaintained, low-quality, or unnecessary when the standard library already provides equivalent functionality. Using `go get -u` to upgrade an existing dependency is safe.
SKILL.md:91In the instructionsOpen original file
**Prefer `go get -u=patch`** for routine updates. Patch and minor updates are usually lower risk than major upgrades, but still require review. For dependency updates, run:```bashgo get -u=patch ./...go mod tidygo test ./...go vet ./...govulncheck ./...   # or: go tool govulncheck ./...```
Medium risk

Security updates are proposed for auto-merge regardless of version, potentially committing breaking major changes

Source references: 1
What we found

The document says major updates need manual review, then says security updates should auto-merge regardless of version-bump type. A security fix that also carries major API or behavior changes falls into both rules.

Why this matters

Even with passing CI, uncovered interfaces, configuration, or runtime behavior may break deployments or alter security boundaries.

This is active strategy guidance, not a test or warning. It requires manual review for major updates but then says every security update should auto-merge regardless of version-bump type. If a security fix is available only through a breaking major release, these rules conflict and could change APIs or behavior without human review. Passing CI only partly mitigates that risk; users can require manual approval for every major update.

references/automated-updates.md:18In the instructionsOpen original file
## Auto-Merge Strategy- **Minor and patch updates**: Auto-merge only after CI passes (tests + lint + govulncheck) and the package is low-risk for the project- **Major updates**: Create PR for manual review (may contain breaking changes)- **Security updates**: Auto-merge regardless of version bump type
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.Risks found: 2
Medium risk

Unrestricted git command permission exceeds what dependency management requires

Source references: 2
What we found

`Bash(git:*)` can cover much more than inspecting dependency diffs, including committing, rewriting history, deleting branches, changing remotes, or pushing. The live instructions do not establish approval boundaries for those high-impact operations.

Why this matters

If the host enforces this declaration as a grant, a mistaken instruction or injected content could cause lasting repository changes or send local content to a configured remote.

`allowed-tools` is the skill’s requested live capability scope, and `Bash(git:*)` covers every git invocation rather than only read-only inspection. Although the text discusses committing dependency files, it sets no confirmation boundary for pushes, history rewrites, remote changes, or deletion commands. This grants broader capability than dependency auditing requires, though it does not prove misuse. Users can restrict access to read-only git subcommands and necessary diff inspection.

SKILL.md:21In the instructionsOpen original file
        bins: [govulncheck]allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent Bash(govulncheck:*) AskUserQuestion---
Show 1 other places
SKILL.md:45In the instructionsOpen original file
## Key Rules- `go.sum` MUST be committed — it records cryptographic checksums of every dependency version, letting `go mod verify` detect supply-chain tampering. Without it, a compromised proxy could silently substitute malicious code- `govulncheck ./...` or `go tool govulncheck ./...` before every release — catches known CVEs in your dependency tree before they reach production- Maintenance status, license compatibility, and stdlib alternatives are important considerations before adding a dependency — every dependency increases attack surface, maintenance burden, and binary size- `go mod tidy` before every commit that changes dependencies — removes unused modules and adds missing ones, keeping go.mod honest
Medium risk

Always ignoring go.work.sum can remove reviewable checksums for workspace-only dependencies

Source references: 3
What we found

The Skill categorically says not to commit go.work.sum. That file can contain checksums needed by the workspace but absent from individual module go.sum files; always ignoring it prevents the team from fixing and reviewing those records in version control.

Why this matters

Developers or CI may generate different checksum records when first resolving workspace dependencies, reducing auditability and anomaly detection for workspace builds.

The skill gives an unconditional rule not to commit `go.work.sum`, while describing workspaces that combine multiple local modules and synchronize module changes. Workspace resolution can require checksums not yet present in each module’s go.sum; always ignoring the file prevents those records from being reviewed alongside a shared workspace configuration and can reduce consistency across team environments. The impact depends on whether the team commits and relies on go.work. Users can require a policy conditional on whether go.work is shared, with the integrity tradeoff explained.

references/workspaces.md:22In the instructionsOpen original file
## Key Points- Workspaces eliminate the need for `replace` directives during local development — the workspace automatically resolves local modules- **Do not commit `go.work.sum`** to version control (add to `.gitignore`)- `go.work` is for development only — it does not affect how consumers of your published modules resolve dependencies- For workspace directory structure examples, see the `samber/cc-skills-golang@golang-project-layout` skill
Show 2 other places
references/workspaces.md:5In the instructionsOpen original file
| Scenario                                       | Use       || ---------------------------------------------- | --------- || Single module project                          | `go.mod`  || Developing multiple related local modules      | `go.work` || Monorepo with separate Go modules              | `go.work` || Testing local changes across module boundaries | `go.work` || Published library consumed by others           | `go.mod`  |
references/workspaces.md:15In the instructionsOpen original file
```bashgo work init                    # Initialize workspacego work use ./services/auth     # Add module to workspacego work use -rm ./old-module    # Remove module from workspacego work sync                    # Sync workspace with module changes```
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

7 instruction sections

The Skill audits, adds, upgrades, removes, and visualizes Go dependencies. Its workflows can modify go.mod and go.sum and may also generate vendor directories or report files.

View source
SKILL.md:58In the instructionsOpen original file
| ----------------- | -------------------------------------------- || `go mod tidy`     | Add missing deps, remove unused ones         || `go mod download` | Download modules to local cache              || `go mod verify`   | Verify cached modules match go.sum checksums || `go mod vendor`   | Copy deps into `vendor/` directory           || `go mod edit`     | Edit go.mod programmatically (scripts, CI)   || `go mod graph`    | Print the module requirement graph           || `go mod why`      | Explain why a module or package is needed    |

It requires confirmation before adding a dependency and asks the agent to consider the standard library, licensing, and alternatives. The confirmation rule explicitly does not cover upgrades of existing dependencies.

View source
SKILL.md:34In the instructionsOpen original file
**Before running `go get` to add any new dependency, AI agents MUST ask the user for confirmation.** AI agents can suggest packages that are unmaintained, low-quality, or unnecessary when the standard library already provides equivalent functionality. Using `go get -u` to upgrade an existing dependency is safe.Before proposing a dependency, evaluate:- Does the standard library already cover the use case?- Is the license compatible?- Are there well-known alternatives?- What it does and why it's needed?

The dependency-update workflow includes module cleanup, tests, static checks, and vulnerability scanning, which can identify some compatibility or security problems after an update.

View source
SKILL.md:91In the instructionsOpen original file
**Prefer `go get -u=patch`** for routine updates. Patch and minor updates are usually lower risk than major upgrades, but still require review. For dependency updates, run:```bashgo get -u=patch ./...go mod tidygo test ./...go vet ./...govulncheck ./...   # or: go tool govulncheck ./...```

The Skill declares project file read/write access and permission to run all matching go, git, golangci-lint, and govulncheck commands. The actual impact depends on whether the host treats this field as an enforceable permission grant.

View source
SKILL.md:21In the instructionsOpen original file
        bins: [govulncheck]allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent Bash(govulncheck:*) AskUserQuestion---
Start here · InstructionsSKILL.md
golang-dependency-management
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.

File reference map

References: 6
Files making referencesReferenced content
Lines show actual file references, not execution order. Select a node to highlight its connections and inspect the files and source locations. Dashed lines include files that still need locating.
Files and check records8 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included
  • references/auditing.mdFull text included
  • references/automated-updates.mdFull text included
  • references/conflicts.mdFull text included
  • references/versioning.mdFull text included
  • references/visualization.mdFull text included
  • references/workspaces.mdFull text included
  • evals/evals.jsonFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions
  • evals/evals.jsonSupporting file
  • references/auditing.mdSupporting file
  • references/automated-updates.mdSupporting file
  • references/conflicts.mdSupporting file
  • references/versioning.mdSupporting file
  • references/visualization.mdSupporting file
  • references/workspaces.mdSupporting file

Operations mentioned in code and instructions

Connect to websites
SKILL.md:12In the instructionsOpen original file
    emoji: "📦"    homepage: https://github.com/samber/cc-skills-golang    requires:
references/auditing.md:78In the instructionsOpen original file
**Modern alternative**: [go-size-analyzer](https://github.com/Zxilly/go-size-analyzer) (`gsa`) supports ELF, Mach-O, PE, and WebAssembly formats with interactive HTML/SVG visualization:
Run commands
SKILL.md:21In the instructionsOpen original file
        bins: [govulncheck]allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent Bash(govulncheck:*) AskUserQuestion---
SKILL.md:74In the instructionsOpen original file
```bashgo get github.com/google/uuid          # Latest version
SKILL.md:85In the instructionsOpen original file
```bashgo get -u ./...            # Upgrade ALL direct+indirect deps to latest minor/patch
Change files
references/workspaces.md:18In the instructionsOpen original file
go work use ./services/auth     # Add module to workspacego work use -rm ./old-module    # Remove module from workspacego work sync                    # Sync workspace with module changes
Lines read
714
File checksum (to compare versions)
56d2a12109fc417ecd25b4cf71f10c4571897593be3a4805c988fd1e95137238