Convert Figma logo to code with AI

securego logogosec

Go security checker

8,883
700
8,883
3

Top Related Projects

Fast linters runner for Go

Staticcheck - The advanced Go linter

3,968

[mirror] This is a linter for Go source code. (deprecated)

errcheck checks that you checked errors.

Quick Overview

Gosec is a security-focused static analysis tool for Go code. It scans Go source code to detect potential security issues and vulnerabilities. Gosec integrates with various CI/CD pipelines and can be used as part of the development process to identify security problems early.

Pros

  • Easy to integrate into existing workflows and CI/CD pipelines
  • Covers a wide range of security checks, including hardcoded credentials, SQL injection, and more
  • Regularly updated with new security rules and improvements
  • Provides clear, actionable output with explanations of detected issues

Cons

  • May produce false positives, requiring manual review of results
  • Limited to Go language, not suitable for multi-language projects
  • Some advanced security issues may require additional tools or manual analysis
  • Configuration can be complex for customizing rules or excluding false positives

Getting Started

To install and run Gosec:

# Install Gosec
go install github.com/securego/gosec/v2/cmd/gosec@latest

# Run Gosec on a Go project
gosec ./...

# Run Gosec with JSON output
gosec -fmt=json -out=results.json ./...

# Run Gosec with specific rules
gosec -include=G101,G102,G103 ./...

For more advanced usage and integration with CI/CD pipelines, refer to the official documentation on the GitHub repository.

Competitor Comparisons

Fast linters runner for Go

Pros of golangci-lint

  • Comprehensive: Integrates multiple linters (including gosec) for a more thorough code analysis
  • Customizable: Offers extensive configuration options to tailor the linting process
  • Performance: Runs linters in parallel, resulting in faster execution times

Cons of golangci-lint

  • Complexity: The wide range of options can be overwhelming for new users
  • False positives: May generate more false positives due to the inclusion of multiple linters

Code comparison

golangci-lint configuration example:

linters:
  enable:
    - gosec
    - errcheck
    - staticcheck
  disable:
    - dupl

gosec usage example:

gosec ./...

Key differences

  • Scope: golangci-lint is a meta-linter that includes gosec, while gosec focuses specifically on security-related issues
  • Usage: golangci-lint requires configuration but offers more comprehensive analysis, whereas gosec is simpler to use out-of-the-box for security checks
  • Integration: golangci-lint is often used as part of a larger CI/CD pipeline, while gosec can be used standalone or integrated into other tools

Both tools are valuable for Go developers, with golangci-lint offering a broader range of checks and gosec providing a specialized focus on security vulnerabilities.

Staticcheck - The advanced Go linter

Pros of go-tools

  • Broader scope: Includes various analysis tools beyond security, such as staticcheck and unused
  • More comprehensive: Offers a wider range of checks and linters for Go code
  • Active development: Regularly updated with new features and improvements

Cons of go-tools

  • Less focused on security: Not specifically tailored for security-related issues like gosec
  • Steeper learning curve: May require more time to understand and configure all available tools

Code Comparison

gosec example:

// gosec G104
_, err := os.Open(filename)
if err != nil {
    log.Println(err)
}

go-tools (staticcheck) example:

// staticcheck SA1006
var x int
x, err := someFunction()
if err != nil {
    return err
}

Both tools identify potential issues in Go code, but gosec focuses on security-specific concerns, while go-tools (specifically staticcheck in this example) covers a broader range of code quality and correctness issues.

gosec is more suitable for projects prioritizing security analysis, while go-tools provides a comprehensive suite of analysis tools for overall code quality improvement. The choice between them depends on the specific needs of the project and the desired balance between security focus and general code quality checks.

3,968

[mirror] This is a linter for Go source code. (deprecated)

Pros of lint

  • Focuses on general coding style and best practices
  • Integrated into the official Go toolchain
  • Widely adopted and maintained by the Go community

Cons of lint

  • Limited security-specific checks
  • May miss critical security vulnerabilities
  • Less frequent updates compared to gosec

Code Comparison

lint example:

func example() {
    var x int
    x = x  // lint will flag this as ineffectual assignment
}

gosec example:

func example() {
    password := "hardcoded_password"  // gosec will flag this as a security issue
    fmt.Println(password)
}

Summary

lint is a general-purpose linter that focuses on coding style and best practices, while gosec is specifically designed for security-related checks. lint is more widely adopted and integrated into the Go toolchain, but may miss critical security vulnerabilities that gosec can detect. gosec provides more frequent updates and specialized security checks, making it a valuable tool for projects where security is a primary concern. For comprehensive code quality and security, using both tools in conjunction can provide the best coverage.

errcheck checks that you checked errors.

Pros of errcheck

  • Focused specifically on error checking, providing more in-depth analysis
  • Lightweight and fast, with minimal setup required
  • Can be easily integrated into CI/CD pipelines

Cons of errcheck

  • Limited scope compared to gosec's broader security analysis
  • May produce false positives in certain scenarios
  • Lacks some advanced features found in gosec, such as customizable rules

Code Comparison

errcheck example:

func example() {
    f, _ := os.Open("file.txt") // errcheck will flag this line
    defer f.Close()
    // ...
}

gosec example:

func example() {
    password := "hardcoded_password" // gosec will flag this line
    // ...
}

errcheck focuses on identifying unchecked errors, while gosec covers a wider range of security issues, including hardcoded credentials, SQL injection vulnerabilities, and more.

Both tools are valuable for Go developers, with errcheck being more specialized for error handling and gosec offering a comprehensive security analysis. errcheck is ideal for projects prioritizing proper error management, while gosec is better suited for overall security auditing. Developers may benefit from using both tools in conjunction to ensure both error handling and security best practices are followed.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

gosec - Go Security Checker

Inspects source code for security problems by scanning the Go AST and SSA code representation.

Quick links

Features

  • Pattern-based rules for detecting common security issues in Go code
  • SSA-based analyzers for type conversions, slice bounds, and crypto issues
  • Taint analysis for tracking data flow from user input to dangerous functions (SQL injection, command injection, path traversal, SSRF, XSS, log injection, SMTP injection, SSTI, unsafe deserialization, open redirect)

License

Licensed under the Apache License, Version 2.0 (the "License"). You may not use this file except in compliance with the License. You may obtain a copy of the License here.

Project status

CII Best Practices Build Status Coverage Status GoReport GoDoc Docs Downloads GHCR Slack go-recipes

Installation

GitHub Action

You can run gosec as a GitHub action as follows:

Use the versioned tag with @master which is pinned to the latest stable release. This will provide a stable behavior.

name: Run Gosec
on:
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
jobs:
  tests:
    runs-on: ubuntu-latest
    env:
      GO111MODULE: on
    steps:
      - name: Checkout Source
        uses: actions/checkout@v3
      - name: Run Gosec Security Scanner
        uses: securego/gosec@master
        with:
          args: ./...

Scanning Projects with Private Modules

If your project imports private Go modules, you need to configure authentication so that gosec can fetch the dependencies. Set the following environment variables in your workflow:

  • GOPRIVATE: A comma-separated list of module path prefixes that should be considered private (e.g., github.com/your-org/*).
  • GITHUB_AUTHENTICATION_TOKEN: A GitHub token with read access to your private repositories.
name: Run Gosec
on:
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
jobs:
  tests:
    runs-on: ubuntu-latest
    env:
      GO111MODULE: on
      GOPRIVATE: github.com/your-org/*
      GITHUB_AUTHENTICATION_TOKEN: ${{ secrets.PRIVATE_REPO_TOKEN }}
    steps:
      - name: Checkout Source
        uses: actions/checkout@v3
      - name: Run Gosec Security Scanner
        uses: securego/gosec@v2
        with:
          args: ./...

Integrating with code scanning

You can integrate third-party code analysis tools with GitHub code scanning by uploading data as SARIF files.

The workflow shows an example of running the gosec as a step in a GitHub action workflow which outputs the results.sarif file. The workflow then uploads the results.sarif file to GitHub using the upload-sarif action.

name: "Security Scan"

# Run workflow each time code is pushed to your repository and on a schedule.
# The scheduled workflow runs every at 00:00 on Sunday UTC time.
on:
  push:
  schedule:
  - cron: '0 0 * * 0'

jobs:
  tests:
    runs-on: ubuntu-latest
    env:
      GO111MODULE: on
    steps:
      - name: Checkout Source
        uses: actions/checkout@v3
      - name: Run Gosec Security Scanner
        uses: securego/gosec@v2
        with:
          # we let the report trigger content trigger a failure using the GitHub Security features.
          args: '-no-fail -fmt sarif -out results.sarif ./...'
      - name: Upload SARIF file
        uses: github/codeql-action/upload-sarif@v2
        with:
          # Path to SARIF file relative to the root of the repository
          sarif_file: results.sarif

Go Analysis

The goanalysis package provides a golang.org/x/tools/go/analysis.Analyzer for integration with tools that support the standard Go analysis interface, such as Bazel's nogo framework:

nogo(
    name = "nogo",
    deps = [
        "@com_github_securego_gosec_v2//goanalysis",
        # add more analyzers as needed
    ],
    visibility = ["//visibility:public"],
)

Local Installation

gosec requires Go 1.25 or newer.

go install github.com/securego/gosec/v2/cmd/gosec@latest

Quick start

# Scan all packages in current module
gosec ./...

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

# Write SARIF report for code scanning
gosec -fmt sarif -out results.sarif ./...

Exit codes

  • 0: scan finished without unsuppressed findings/errors
  • 1: at least one unsuppressed finding or processing error
  • Use -no-fail to always return 0

Usage

Gosec can be configured to only run a subset of rules, to exclude certain file paths, and produce reports in different formats. By default all rules will be run against the supplied input files. To recursively scan from the current directory you can supply ./... as the input argument.

Available rules

gosec includes rules across these categories:

  • G1xx: general secure coding issues (for example hardcoded credentials, unsafe usage, HTTP hardening, cookie security)
  • G2xx: injection risks in query/template/command construction
  • G3xx: file and path handling risks (permissions, traversal, temp files, archive extraction)
  • G4xx: crypto and TLS weaknesses
  • G5xx: blocklisted imports
  • G6xx: Go-specific correctness/security checks (for example range aliasing and slice bounds)
  • G7xx: taint analysis rules (SQL injection, command injection, path traversal, SSRF, XSS, log, SMTP injection, SSTI, unsafe deserialization, and open redirect)

For the full list, rule descriptions, and per-rule configuration, see RULES.md.

Retired rules

  • G105: Audit the use of math/big.Int.Exp - CVE is fixed
  • G307: Deferring a method which returns an error - causing more inconvenience than fixing a security issue, despite the details from this blog post

Selecting rules

By default, gosec will run all rules against the supplied file paths. It is however possible to select a subset of rules to run via the -include= flag, or to specify a set of rules to explicitly exclude using the -exclude= flag.

# Run a specific set of rules
$ gosec -include=G101,G203,G401 ./...

# Run everything except for rule G303
$ gosec -exclude=G303 ./...

CWE Mapping

Every issue detected by gosec is mapped to a CWE (Common Weakness Enumeration) which describes in more generic terms the vulnerability. The exact mapping can be found here.

Configuration

A number of global settings can be provided in a configuration file as follows:

{
    "global": {
        "nosec": "enabled",
        "audit": "enabled"
    }
}
  • nosec: this setting will overwrite all #nosec directives defined throughout the code base
  • audit: runs in audit mode which enables addition checks that for normal code analysis might be too nosy
# Run with a global configuration file
$ gosec -conf config.json .

Path-Based Rule Exclusions

Large repositories with multiple components may need different security rules for different paths. Use exclude-rules to suppress specific rules for specific paths.

Configuration File:

{
  "exclude-rules": [
    {
      "path": "cmd/.*",
      "rules": ["G204", "G304"]
    },
    {
      "path": "scripts/.*",
      "rules": ["*"]
    }
  ]
}

CLI Flag:

# Exclude G204 and G304 from cmd/ directory
gosec --exclude-rules="cmd/.*:G204,G304" ./...

# Exclude all rules from scripts/ directory  
gosec --exclude-rules="scripts/.*:*" ./...

# Multiple exclusions
gosec --exclude-rules="cmd/.*:G204,G304;test/.*:G101" ./...
FieldTypeDescription
pathstring (regex)Regex matched against file paths
rules[]stringRule IDs to exclude. * for all

Rule Configuration

Some rules accept configuration flags as well; these flags are documented in RULES.md.

Go version

Some rules require a specific Go version which is retrieved from the Go module file present in the project. If this version cannot be found, it will fallback to Go runtime version.

The Go module version is parsed using the go list command which in some cases might lead to performance degradation. In this situation, the go module version can be easily provided by setting the environment variable GOSECGOVERSION=go1.21.1.

Dependencies

gosec loads packages using Go modules. In most projects, dependencies are resolved automatically during scanning.

If dependencies are missing, run:

go mod tidy
go mod download

Excluding test files and folders

gosec will ignore test files across all packages and any dependencies in your vendor directory.

The scanning of test files can be enabled with the following flag:

gosec -tests ./...

Also additional folders can be excluded as follows:

 gosec -exclude-dir=rules -exclude-dir=cmd ./...

Excluding generated files

gosec can ignore generated go files with default generated code comment.

// Code generated by some generator DO NOT EDIT.
gosec -exclude-generated ./...

Auto fixing vulnerabilities

gosec can suggest fixes based on AI recommendation. It will call an AI API to receive a suggestion for a security finding.

You can enable this feature by providing the following command line arguments:

  • ai-api-provider: the name of the AI API provider. Supported providers:
    • Gemini: gemini-3-pro-preview (default), gemini-2.5-pro, gemini-2.5-flash, gemini-2.5-flash-lite
    • Claude: claude-sonnet-4-6 (default), claude-opus-4-7, claude-opus-4-6, claude-sonnet-4-5, claude-opus-4-5, claude-haiku-4-5
    • OpenAI: gpt-5.4 (default), gpt-5.4-mini, gpt-5.4-nano
    • Custom OpenAI-compatible: Any custom model name (requires ai-base-url)
  • ai-api-key or set the environment variable GOSEC_AI_API_KEY: the key to access the AI API
  • ai-base-url: (optional) custom base URL for OpenAI-compatible APIs (e.g., Azure OpenAI, LocalAI, Ollama)
  • ai-skip-ssl: (optional) skip SSL certificate verification for AI API (useful for self-signed certificates)

Examples:

# Using Gemini
gosec -ai-api-provider="gemini-3-pro-preview" \
  -ai-api-key="your_key" ./...

# Using Claude
gosec -ai-api-provider="claude-sonnet-4-6" \
  -ai-api-key="your_key" ./...

# Using OpenAI
gosec -ai-api-provider="gpt-5.4" \
  -ai-api-key="your_key" ./...

# Using Azure OpenAI
gosec -ai-api-provider="gpt-5.4" \
  -ai-api-key="your_azure_key" \
  -ai-base-url="https://your-resource.openai.azure.com/openai/deployments/your-deployment" \
  ./...

# Using local Ollama with custom model
gosec -ai-api-provider="llama3.2" \
  -ai-base-url="http://localhost:11434/v1" \
  ./...

# Using self-signed certificate API
gosec -ai-api-provider="custom-model" \
  -ai-api-key="your_key" \
  -ai-base-url="https://internal-api.company.com/v1" \
  -ai-skip-ssl \
  ./...

Annotating code

As with all automated detection tools, there will be cases of false positives. In cases where gosec reports a failure that has been manually verified as being safe, it is possible to annotate the code with a comment that starts with #nosec.

The #nosec comment should have the format #nosec [RuleList] [-- Justification].

The #nosec comment needs to be placed on the line where the warning is reported.

func main() {
	tr := &http.Transport{
		TLSClientConfig: &tls.Config{
			InsecureSkipVerify: true, // #nosec G402
		},
	}

	client := &http.Client{Transport: tr}
	_, err := client.Get("https://go.dev/")
	if err != nil {
		fmt.Println(err)
	}
}

When a specific false positive has been identified and verified as safe, you may wish to suppress only that single rule (or a specific set of rules) within a section of code, while continuing to scan for other problems. To do this, you can list the rule(s) to be suppressed within the #nosec annotation, e.g: /* #nosec G401 */ or //#nosec G201 G202 G203

You could put the description or justification text for the annotation. The justification should be after the rule(s) to suppress and start with two or more dashes, e.g: //#nosec G101 G102 -- This is a false positive

Alternatively, gosec also supports the //gosec:disable directive, which functions similar to #nosec:

//gosec:disable G101 -- This is a false positive

In some cases you may also want to revisit places where #nosec or //gosec:disable annotations have been used. To run the scanner and ignore any #nosec annotations you can do the following:

gosec -nosec=true ./...

Tracking suppressions

As described above, we could suppress violations externally (using -include/-exclude) or inline (using #nosec annotations). Suppression metadata can be emitted for auditing.

Enable suppression tracking with -track-suppressions:

gosec -track-suppressions -exclude=G101 \
  -fmt=sarif -out=results.sarif ./...
  • For external suppressions, gosec records suppression info where kind is external and justification is Globally suppressed..
  • For inline suppressions, gosec records suppression info where kind is inSource and justification is the text after two or more dashes in the comment.

Note: Only SARIF and JSON formats support tracking suppressions.

Build tags

gosec is able to pass your Go build tags to the analyzer. They can be provided as a comma separated list as follows:

gosec -tags debug,ignore ./...

Output formats

gosec supports text, json, yaml, csv, junit-xml, html, sonarqube, golint, and sarif. By default, results will be reported to stdout, but can also be written to an output file. The output format is controlled by the -fmt flag, and the output file is controlled by the -out flag as follows:

# Write output in json format to results.json
$ gosec -fmt=json -out=results.json *.go

Use -stdout to print results while also writing -out. Use -verbose to override stdout format while preserving the file format.

# Write output in json format to results.json as well as stdout
$ gosec -fmt=json -out=results.json -stdout *.go

# Overrides the output format to 'text' when stdout the results,
# while writing it to results.json
$ gosec -fmt=json -out=results.json -stdout -verbose=text *.go

Note: gosec generates the generic issue import format for SonarQube, and a report has to be imported into SonarQube using sonar.externalIssuesReportPaths=path/to/gosec-report.json.

Common usage patterns

# Fail only on medium+ severity findings
gosec -severity medium ./...

# Fail only on medium+ confidence findings
gosec -confidence medium ./...

# Exclude specific rules for specific paths
gosec --exclude-rules="cmd/.*:G204,G304;scripts/.*:*" ./...

# Exclude generated files in scan
gosec -exclude-generated ./...

# Include test files in scan
gosec -tests ./...

Development

Development documentation was moved to DEVELOPMENT.md.

Who is using gosec?

This is a list with some of the gosec's users.

Sponsors

Support this project by becoming a sponsor. Your logo will show up here with a link to your website