gosec

Gosec is the go-to security linter for Go applications. The SecureGo community maintains it, and with over 8,700 GitHub stars, it has become the most adopted SAST scanner in the Go ecosystem. It scans Go source code using AST and SSA analysis to find security vulnerabilities before they ship.

The project has CII Best Practices certification and ships with 50+ rules that cover the OWASP Top 10, each mapped to CWE identifiers. It also has AI-powered fix suggestions through Gemini, Claude, and OpenAI-compatible APIs, so you get remediation guidance right in your terminal.

It runs through the Go module system. No external dependencies, no build server. Install via go install, Homebrew, or Docker and point it at your codebase.

What is Gosec?

Gosec inspects Go source code for security problems by analyzing both structure and data flow. According to the OWASP Go Security Cheat Sheet, Go’s standard library provides strong defaults, but developers still introduce vulnerabilities through improper use of SQL, crypto, and HTTP packages — exactly the patterns gosec targets. Unlike generic linters, it focuses on security patterns that lead to exploitable vulnerabilities.

Key features

Static analysis engine

Gosec parses Go source code into an Abstract Syntax Tree, then performs Static Single Assignment analysis to track how data flows through your program. This two-pass approach catches security issues that pattern matching alone would miss. Tainted user input reaching a SQL query through several function calls triggers G201 or G202. A direct fmt.Sprintf piped into an exec.Command triggers G204.

SSA represents each variable assignment exactly once, letting gosec trace values across function boundaries. That’s what separates it from syntactic linters like go vet.

Security rules

The 50+ rules break down into seven categories:

Each rule maps to one or more CWE identifiers. When gosec flags G402 (bad TLS settings), the output includes CWE-295, so your compliance team can cross-reference against their standards without manual mapping.

Output formats

Gosec produces reports in JSON, SARIF, SonarQube, JUnit XML, CSV, YAML, HTML, golint, and plain text. The SARIF output feeds directly into GitHub’s Security tab, surfacing findings in pull request annotations.

# JSON report
gosec -fmt=json -out=results.json ./...

# SARIF for GitHub Code Scanning
gosec -fmt=sarif -out=results.sarif ./...

# SonarQube
gosec -fmt=sonarqube -out=results.json ./...

# HTML report
gosec -fmt=html -out=report.html ./...

AI-powered fix suggestions

Gosec can send findings to an LLM and get fix suggestions back in your terminal output. Three provider families are supported:

Custom OpenAI-compatible APIs work too, using the -ai-base-url flag for self-hosted or alternative endpoints.

# Claude fix suggestions
export GOSEC_AI_API_KEY="your-api-key"
gosec -ai-api-provider="claude-sonnet-4-0" ./...

# Gemini
gosec -ai-api-provider="gemini-2.5-pro" -ai-api-key="key" ./...

# Custom endpoint
gosec -ai-api-provider="custom-model" -ai-base-url="https://your-api.com/v1" -ai-api-key="key" ./...

Code annotations

Suppress individual findings with #nosec comments when you’ve verified a false positive:

// Suppress a specific rule with justification
InsecureSkipVerify: true, // #nosec G402 -- Internal CA, verified safe

// Alternative syntax
//gosec:disable G101 -- Test fixture, not real credentials

// Suppress multiple rules
cmd := exec.Command(input) // #nosec G204 G304 -- Validated input from allowlist

The -track-suppressions flag records all suppressed findings in SARIF and JSON output, so you maintain an audit trail even for silenced rules.

Getting started

Integration

GitHub Actions

name: Security Scan
on: [push, pull_request]

jobs:
  gosec:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: securego/gosec@master
        with:
          args: '-fmt sarif -out results.sarif ./...'
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: results.sarif

Bazel nogo

Gosec’s analyzers are compatible with golang.org/x/tools/go/analysis.Analyzer, so they plug into the Bazel nogo framework for build-time checking.

Configuration

Gosec supports JSON configuration files for persistent settings:

{
  "global": {
    "nosec": "enabled",
    "audit": "enabled"
  },
  "exclude-rules": [
    {
      "path": "cmd/.*",
      "rules": ["G204", "G304"]
    },
    {
      "path": "test/.*",
      "rules": ["G101", "G404"]
    }
  ]
}

Run with a config file:

gosec -conf config.json ./...

Path-based exclusions also work from the command line:

gosec --exclude-rules="cmd/.*:G204,G304" --exclude-rules="test/.*:G101" ./...

When to use Gosec

Gosec fits into any Go development workflow. Use it as a pre-commit hook to catch issues before they enter your repository, in CI pipelines to block merges on security findings, or during audits to produce compliance reports.

It pairs well with go vet and staticcheck. Those tools catch general code quality issues; gosec adds the security-specific layer they don’t cover.

For teams building APIs, microservices, or CLI tools in Go, gosec targets the vulnerabilities most common in server-side Go code: SQL injection, command injection, weak crypto, and hardcoded secrets.

The zero-configuration approach means you can add gosec to an existing project in under a minute. Install, run gosec ./..., review the output. No config files needed unless you want to customize rule selection or exclusion paths. For a broader look at static analysis options, see our open-source SAST tools guide.

Frequently Asked Questions