$npx -y skills add samber/cc-skills-golang --skill golang-securitySecurity best practices and vulnerability prevention for Golang. Covers injection (SQL, command, XSS), cryptography, filesystem safety, network security, cookies, secrets management, memory safety, and logging. Apply when writing, reviewing, or auditing Go code for security, or w
| 1 | **Persona:** You are a senior Go security engineer. You apply security thinking both when auditing existing code and when writing new code — threats are easier to prevent than to fix. |
| 2 | |
| 3 | **Thinking mode:** Use `ultrathink` for security audits and vulnerability analysis. Security bugs hide in subtle interactions — deep reasoning catches what surface-level review misses. |
| 4 | |
| 5 | **Orchestration mode:** Use `ultracode` for a full-codebase security audit — orchestrate the five vulnerability-domain sub-agents described in Audit mode as a fan-out-then-synthesize workflow. Parallelism covers more attack surface per pass; the synthesis step deduplicates findings and ranks them by severity. |
| 6 | |
| 7 | **Modes:** |
| 8 | |
| 9 | - **Review mode** — reviewing a PR for security issues. Start from the changed files, then trace call sites and data flows into adjacent code — a vulnerability may live outside the diff but be triggered by it. Sequential. |
| 10 | - **Audit mode** — full codebase security scan. Launch up to 5 parallel sub-agents (via the Agent tool), each covering an independent vulnerability domain: (1) injection patterns, (2) cryptography and secrets, (3) web security and headers, (4) authentication and authorization, (5) concurrency safety and dependency vulnerabilities. Aggregate findings, score with DREAD, and report by severity. A large audit produces many independent findings — apply each fix/improvement in its own worktree (`EnterWorktree`), so one fix = one worktree = one focused, reviewable, independently revertible PR, instead of one large mixed-concern change. |
| 11 | - **Coding mode** — use when writing new code or fixing a reported vulnerability. Follow the skill's sequential guidance. Optionally launch a background agent to grep for common vulnerability patterns in newly written code while the main agent continues implementing the feature. |
| 12 | |
| 13 | **Dependencies:** |
| 14 | |
| 15 | - govulncheck: `go install golang.org/x/vuln/cmd/govulncheck@latest` |
| 16 | |
| 17 | # Go Security |
| 18 | |
| 19 | ## Overview |
| 20 | |
| 21 | Security in Go follows the principle of **defense in depth**: protect at multiple layers, validate all inputs, use secure defaults, and leverage the standard library's security-aware design. Go's type system and concurrency model provide some inherent protections, but vigilance is still required. |
| 22 | |
| 23 | ## Security Thinking Model |
| 24 | |
| 25 | Before writing or reviewing code, ask three questions: |
| 26 | |
| 27 | 1. **What are the trust boundaries?** — Where does untrusted data enter the system? (HTTP requests, file uploads, environment variables, database rows written by other services) |
| 28 | 2. **What can an attacker control?** — Which inputs flow into sensitive operations? (SQL queries, shell commands, HTML output, file paths, cryptographic operations) |
| 29 | 3. **What is the blast radius?** — If this defense fails, what's the worst outcome? (Data leak, RCE, privilege escalation, denial of service) |
| 30 | |
| 31 | ## Severity Levels |
| 32 | |
| 33 | | Level | DREAD | Meaning | |
| 34 | | --- | --- | --- | |
| 35 | | Critical | 8-10 | RCE, full data breach, credential theft — fix immediately | |
| 36 | | High | 6-7.9 | Auth bypass, significant data exposure, broken crypto — fix in current sprint | |
| 37 | | Medium | 4-5.9 | Limited exposure, session issues, defense weakening — fix in next sprint | |
| 38 | | Low | 1-3.9 | Minor info disclosure, best-practice deviations — fix opportunistically | |
| 39 | |
| 40 | Levels align with [DREAD scoring](./references/threat-modeling.md). |
| 41 | |
| 42 | ## Research Before Reporting |
| 43 | |
| 44 | Before flagging a security issue, trace the full data flow through the codebase — don't assess a code snippet in isolation. |
| 45 | |
| 46 | 1. **Trace the data origin** — follow the variable back to where it enters the system. Is it user input, a hardcoded constant, or an internal-only value? |
| 47 | 2. **Check for upstream validation** — look for input validation, sanitization, type parsing, or allow-listing earlier in the call chain. |
| 48 | 3. **Examine the trust boundary** — if the data never crosses a trust boundary (e.g., internal service-to-service with mTLS), the risk |