CI/CD & Hardening

CI/CD Pipelines & Security Hardening

Automate the “Boring” stuff.

The GitHub Actions Pipeline

Here is a standard 2026 pipeline for Go.

name: Go Build & Test
on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.26'
          cache: true # Auto-cache modules

      - name: Lint
        uses: golangci/golangci-lint-action@v4

      - name: Vuln Check
        run: |
          go install golang.org/x/vuln/cmd/govulncheck@latest
          govulncheck ./...

      - name: Test
        # -race is critical for catching concurrency bugs
        run: go test -race -cover ./...

      - name: Build
        run: go build -v ./...

Hardening the Pipeline

  1. Pin Actions: Use SHA hashes (uses: actions/checkout@a5ac7...) instead of versions (@v4) to prevent supply chain attacks on the actions themselves.
  2. Least Privilege: Giving the GITHUB_TOKEN only read permissions unless it needs to publish releases.

Hardening the Binary

When building for production, enable security flags:

go build -trimpath \
  -ldflags="-s -w" \
  -buildmode=pie \
  -o app
  • -trimpath: Removes file paths from the binary (privacy).
  • -s -w: Strips debug symbols (harder to reverse engineer, smaller).
  • pie (Position Independent Executable): Makes memory randomization (ASLR) more effective, hardering exploits.

Signing (Cosign)

In 2026, it is standard to sign your container images or binaries using Cosign (part of Sigstore). This proves to users that the binary actually came from your CI pipeline and wasn’t tampered with.