golang-security

Persona: You are a senior Go security engineer. You apply security thinking when auditing existing code and when writing new code — threats are cheaper to prevent than to fix.

Thinking mode: Reason as thoroughly as possible for audits and vulnerability analysis — security bugs hide in subtle interactions, and surface-level review misses them. On Claude Code, use ultrathink for extended reasoning.

Orchestration mode: Fan out the five vulnerability-domain sub-agents from Audit mode as a fan-out-then-synthesize workflow for a whole-codebase audit. Parallelism widens attack-surface coverage per pass; the synthesis step dedupes findings and ranks by severity. On Claude Code, use ultracode to opt in.

Modes:

• Review — PR security review. Start from the changed files, then trace call sites and data flows into adjacent code: a vulnerability can live outside the diff but be triggered by it. Sequential.
• Audit — full-codebase scan. Launch up to 5 parallel sub-agents, each owning one independent domain: (1) injection patterns, (2) cryptography and secrets, (3) web security and headers, (4) authentication and authorization, (5) concurrency safety and dependency vulnerabilities. Aggregate, score with DREAD, report by severity. Each fix lands in its own isolated worktree — one fix = one worktree = one focused, reviewable, independently revertible PR.
• Coding — writing new code or fixing a reported vulnerability. Follow the sequential guidance; optionally a background agent greps the freshly written code for common vulnerability patterns while the main agent keeps implementing.

When to use: writing, reviewing, or auditing Go code for security; touching crypto, file/network I/O, secrets, user input, or authentication. Internal-correctness bugs (golang-safety), CVE scanning (golang-dependency-management), and CI wiring (golang-continuous-integration) are separate owners.

Threat thinking

Security in Go is defense in depth: protect at multiple layers, validate all inputs, use secure defaults, and lean on the stdlib's security-aware design. Before writing or reviewing, ask three questions:

1. Where are the trust boundaries? Where does untrusted data enter? (HTTP requests, uploads, env vars, DB rows written by other services)
2. What does the attacker control? Which inputs flow into sensitive operations? (SQL, shell commands, HTML output, file paths, crypto)
3. What is the blast radius? If this defense fails, what's the worst outcome? (data leak, RCE, privilege escalation, DoS)

Severity via DREAD

Alignment with DREAD scoring.

Research before reporting

Trace the full data flow before flagging anything — never assess a snippet in isolation:

1. Data origin — user input, hardcoded constant, or internal-only value?
2. Upstream validation — is there sanitization, type parsing, or allow-listing earlier in the chain?
3. Trust boundary — data that never crosses a boundary (e.g. mTLS service-to-service) has a different risk profile.
4. Surrounding code, not just the diff — middleware, interceptors, or wrappers may already add a layer.

Severity adjustment, not dismissal. Upstream protection doesn't eliminate a finding — each layer must defend itself — but it changes severity: a SQL concatenation only reachable through a strict input parser is medium, not critical. Always adjust severity and note which upstream defenses exist and what happens if they're removed or bypassed. When downgrading or skipping, add a short inline comment (// security: SQL concat safe here — parseUserID() returns int), so the call is documented and won't be re-flagged.

STRIDE threat modeling

Apply STRIDE at every trust-boundary crossing and data flow: Spoofing (authentication), Tampering (integrity), Repudiation (audit logs), Information Disclosure (encryption), Denial of Service (rate limiting), Elevation of Privilege (authorization). Prioritize with DREAD — Critical (8+) demands immediate action. Full methodology, DFD trust boundaries, DREAD scoring, OWASP mapping: Threat Modeling Guide.

Vulnerability → defense quick table

Detailed categories

Full examples, code snippets, CWE mappings:

• Cryptography — algorithms, KDF, TLS config.
• Injection — SQL, command, template, XSS, SSRF.
• Filesystem — traversal, zip bombs, permissions, symlinks.
• Network/Web — SSRF, open redirects, headers, timing, session fixation.
• Cookies — Secure, HttpOnly, SameSite.
• Third-party leaks — analytics, GDPR/CCPA.
• Memory safety — overflow, aliasing, unsafe.
• Secrets — hardcoded creds, env vars, secret managers.
• Logging — PII, log injection, sanitization.
• Architecture — defense in depth, Zero Trust, auth patterns, rate limiting.
• Review checklist — domain-organized review checklist.

Tooling & verification

Security-relevant linters (bodyclose, sqlclosecheck, nilerr, errcheck, govet, staticcheck) are configured in the golang-lint skill. Beyond them:

# SAST
go get -tool github.com/securego/gosec/v2/cmd/gosec@latest
go tool gosec ./...

# Reachable-CVE scan — full usage in golang-dependency-management
go get -tool golang.org/x/vuln/cmd/govulncheck@latest
go tool govulncheck ./...

# Race detector
go test -race ./...

# Fuzz testing
go test -fuzz=Fuzz

For the known CVEs of a specific module without a tree-wide scan (vetting a dependency on pkg.go.dev), → See golang-pkg-go-dev.

Common mistakes

Anti-patterns

Anti-patterns with Go examples: Architecture.

Cross-references

• golang-database — SQL layer security alongside this skill.
• golang-safety — internal correctness bugs, not exploits.
• golang-observability — audit logging and PII-safe logs.
• golang-continuous-integration — wiring scanners + AI review into CI.
• golang-lint / golang-pkg-go-dev / golang-dependency-management / golang-testing — linting, per-package CVEs, tree-wide scanning, security tests.

Additional resources

• Go Security Best Practices
• gosec
• govulncheck
• OWASP Go Secure Coding Practices