Go 1.26 changed how we think about static analysis. The rewritten go fix command proved that Go's analysis.Analyzer framework is not just for finding problems but for fixing them too, with dozens of modernizers that safely rewrite code at scale. Meanwhile, gopls brings these same analyzers into your editor in real time. The Go ecosystem is clearly moving toward a world where tools don't just detect issues but remediate them.

Security tooling hasn't kept up. gosec, the most widely adopted Go security scanner with over 8,700 GitHub stars, has long relied on pattern-based rules that inspect the AST for suspicious function calls. These rules are effective at catching common mistakes like hardcoded credentials or weak crypto, but they have a fundamental limitation: they cannot track data flow. When a user's HTTP query parameter passes through three helper functions and a struct field before landing inside a SQL query, pattern matching either misses it entirely or flags every call to db.Query regardless of whether the data is actually tainted. The result is either false negatives that leave real vulnerabilities undetected, or false positives that train developers to ignore security warnings.

This talk presents a taint analysis engine contributed to gosec that closes this gap. Built on golang.org/x/tools/go/ssa for Static Single Assignment representation and golang.org/x/tools/go/callgraph/cha for Class Hierarchy Analysis call graphs, the engine tracks data flow from untrusted sources (http.Request, os.Args, os.Getenv) through the entire program to dangerous sinks (db.Query, exec.Command, os.Open, http.Get, fmt.Fprintf on a ResponseWriter, log.Printf). Because SSA assigns every variable exactly once, every value can be traced deterministically to its origin. CHA resolves interface method calls conservatively, so taint is tracked even when data flows through interface boundaries.

The engine adds six new detection rules to gosec: G701 for SQL injection (CWE-89), G702 for command injection (CWE-78), G703 for path traversal (CWE-22), G704 for SSRF (CWE-918), G705 for XSS (CWE-79), and G706 for log injection (CWE-117). Each rule is purely configuration-driven, defined as a Go struct of Sources and Sinks with no engine changes required. A notable design feature is CheckArgs, which specifies exactly which function arguments to inspect. For db.Query(queryString, param1, param2), only the query string (argument index 1) is checked because prepared statement parameters are inherently safe. This eliminates an entire category of false positives that plague pattern-based scanners.

But detection alone is only half the story, and this is where the talk looks forward. Go 1.26's go fix demonstrated that the analysis.Analyzer framework supports not just diagnostics but SuggestedFixes, machine-applicable patches that tools can apply automatically. The taint engine's architecture is designed with this trajectory in mind. Because each finding carries the full taint flow path from source to sink, including every intermediate step, it provides exactly the context needed for automated remediation. For deterministic fixes like replacing string concatenation with parameterized queries, the engine can propose concrete SuggestedFixes in the go fix style. For more complex remediations, like input validation, encoding strategies, or architectural refactoring, the structured taint flow data becomes a rich prompt context for LLM-assisted remediation. Imagine running gosec and getting not just "G701: SQL injection at line 42" but a generated fix that rewrites your string concatenation to a prepared statement, or a context-aware suggestion to add path sanitization, powered by an LLM that understands exactly how the tainted data reached the sink. The talk will demonstrate this pluggable remediation architecture and discuss the design considerations for making LLM-assisted fixes reliable enough to trust.

The entire implementation uses zero external dependencies beyond golang.org/x/tools, integrates with the standard analysis.Analyzer framework, and runs alongside gosec's existing 30+ rules. It produces diagnostics in the standard format consumed by go vet, gopls, and golangci-lint.

Attendees will leave with three things: a deep understanding of how SSA and CHA make data flow analysis tractable in Go, practical knowledge of building analyzers that not only detect but suggest fixes using the same framework powering go fix, and a concrete look at where Go security tooling is headed - a world where vulnerabilities are not just flagged but understood, traced, and resolved before they ever reach production.