Skip to content

[go-fan] Go Module Review: gosec #48829

Description

@github-actions

🐹 Go Fan Report: gosec (github.com/securego/gosec/v2)

Module Overview

gosec is the standard Go security static analyzer (Apache-2.0, ~8.9k stars, maintained by securego). It combines pattern-based rules, SSA-based analyzers, and taint analysis (SQLi, command injection, SSRF, XSS, path traversal, and more) by walking the Go AST/SSA.

It rose to the top of today's round-robin because it's the most recently pushed direct dependency in go.mod — securego/gosec was pushed just hours ago (2026-07-29), and it hadn't been reviewed here since 2026-07-20 (9 days, outside the 7-day cooldown).

Current Usage in gh-aw

gosec is a build-time CLI tool only — never imported as a library:

  • Files: 1 (tools.go:11, blank import under //go:build tools)
  • Invocation sites: Makefile (security-gosec, tools targets) and .github/workflows/security-scan.yml (daily scheduled SARIF scan → code scanning)
  • Key flags used: -exclude-generated -track-suppressions -nosec-require-rules -nosec-require-justification -exclude=G602
  • Suppression style: 48 inline #nosec Gxxx -- justification comments across 31 files (enforced via -nosec-require-justification)

Version is v2.28.0 in all four places it's referenced (go.mod, 2× Makefile, workflow YAML) — currently in sync, which is good, but fragile (see Quick Wins).

Research Findings

Recent Updates (v2.28.0, released 2026-07-14 — the version already in use)

  • feat(G101): now detects AWS temporary access keys — a new credential pattern gh-aw already benefits from automatically
  • fix: reduced G115 (integer overflow) false positives on min/max expressions
  • fix(G404): catches previously-missed weak math/rand usages
  • Go toolchain bumped to 1.26.5/1.25.12 internally, matching gh-aw's own go 1.26.5

Best Practices (from gosec docs)

  • Recommended CI pattern: SARIF output + github/codeql-action/upload-sarifgh-aw already does this
  • gosec ships native path-based rule exclusions (-exclude-rules="path-regex:G1,G2" or an exclude-rules array in a JSON -conf file) specifically for large repos needing different rules per directory — this is newer functionality gh-aw isn't using yet (see below).

Improvement Opportunities

🏃 Quick Wins

  1. Dead gosec config in .golangci.yml. gosec is explicitly disabled as a golangci-lint linter ("configuration bugs in v2"), yet the file still carries a full settings.gosec block plus ~20 per-path issues.exclude-rules entries with linters: - gosec. None of this ever executes — golangci-lint never runs gosec, so these entries are inert. Recommend deleting them (or, if kept for documentation purposes, adding a clear "NOT ACTIVE" banner — the current comment undersells how much is dead).
  2. Version pin duplicated 4×. v2.28.0 is hardcoded independently in go.mod, Makefile:227, Makefile:640, and security-scan.yml. Nothing ties these together, so a future bump can easily update 3 of 4 and silently drift. Consider deriving the install version at scan time: go install github.com/securego/gosec/v2/cmd/gosec@$(go list -m -f '{{.Version}}' github.com/securego/gosec/v2).

✨ Feature Opportunities

  1. Migrate to Go 1.24+ tool directives in go.mod. gh-aw is on go 1.26.5, well past the Go 1.24 minimum for native build-tool tracking. Replacing the tools.go blank-import shim with go get -tool entries + go tool gosec ... invocations would make go.mod the single source of truth for the version — eliminating the 4-way pin duplication above in one move, and applying equally well to actionlint and govulncheck, gosec's neighbors in tools.go.
  2. Adopt gosec's native path-based exclude-rules. This is exactly the mechanism the dead .golangci.yml comments were reaching for ("Path-Based Rule Exclusions... Large repositories with multiple components may need different security rules for different paths") but couldn't get working through golangci-lint's broken gosec integration. gosec now supports this natively via -conf gosec.json in the standalone binary gh-aw already runs — no golangci-lint involvement needed. Could replace some of the file-scattered #nosec comments for path-wide patterns (e.g., "allow G204 across all of pkg/cli/mcp_inspect*.go") with one config entry.

📐 Best Practice Alignment

  • Running the full G7xx taint-analysis suite unrestricted (only G602 excluded globally) is exactly right for a project that ingests untrusted workflow YAML, issue/PR content, and logs — no changes recommended here.
  • -track-suppressions + -nosec-require-justification are already enabled, which is the stricter, more auditable configuration gosec recommends for teams with many #nosec annotations.

🔧 General Improvements

  • gosec-report.json is already generated locally by make security-gosec but isn't summarized anywhere in the make target's output beyond "results in gosec-report.json". A one-line severity/count summary (e.g., via jq) would give contributors faster local feedback without needing to open the JSON or wait for the scheduled Actions SARIF run.

Recommendations

  1. Clean up the dead gosec block in .golangci.yml (quick, no behavior change, removes confusion).
  2. Evaluate migrating tools.go → Go 1.24 tool directives for gosec/actionlint/govulncheck to remove version-pin duplication.
  3. If path-specific gosec suppressions grow further, switch to a gosec.json config with exclude-rules instead of more scattered inline comments.

Next Steps

  • File a small housekeeping PR to strip the dead .golangci.yml gosec config.
  • Prototype the go tool migration in a branch and confirm make security-gosec/CI still resolve the pinned version correctly.

Generated by Go Fan
Module summary saved to: scratchpad/mods/gosec.md

Generated by 🐹 Go Fan · age00 · 100.2 AIC · ⌖ 5.89 AIC · ⊞ 5.3K ·

  • expires on Jul 30, 2026, 1:03 AM UTC-08:00

Metadata

Metadata

Labels

automationcookieIssue Monster Loves Cookies!dependenciesPull requests that update a dependency filego

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions