Course outline

01 · Getting Started6/6

02 · Variables, Types & Control Flow6/6

03 · Functions & Composite Types6/6

04 · Methods, Interfaces & Errors6/6

05 · Packages, Modules & Modern Collections6/6

06 · Your First Real Program6/6

07 · Testing & Debugging in Go6/6

08 · Productionizing & Releasing tasker7/7

09 · Generics6/6

10 · Concurrency in Practice6/6

11 · Language Depth II6/6

12 · Standard Library Toolkit6/6

13 · Building Web Services6/6

14 · Working with Databases6/6

15 · Advanced Runtime & Tooling6/6

16 · Building a Terminal Dashboard with Bubble Tea5/5

17 · Closing the Loop2/2

Stage 1 · Code

Advanced Runtime & Tooling

Dependency & Supply-Chain Security

Treat modules, build tools, and release artifacts as inputs that must be verified—not as trusted code merely because `go get` succeeded.

14 min readThe Complete Go EngineerCode

Your Dependency Graph Is a Trust Boundary

A Go binary may look self-contained, but its source can include hundreds of packages written outside your repository. A compromised module, an unreviewed upgrade, or a floating build-tool version can change the binary even when your application code did not. Supply-chain security starts by making those inputs visible and reproducible.

Checksums prove identity, not safety

go.sum helps prove that a module version matches the content previously recorded by the checksum database. It does not prove the code is bug-free, maintained, or appropriate for your threat model. Integrity verification and vulnerability analysis solve different problems.

Verify What Go Downloaded

Inspect and verify the module graph

$go mod tidy && git diff -- go.mod go.sum

// Make dependency changes explicit and review the exact manifest diff before committing.

$go mod verify

// Verify downloaded module content against checksums recorded in go.sum.

$go list -m -u all

// List available updates without changing the dependency graph.

$go mod why -m example.com/dependency

// Trace why a surprising module is present before deciding whether it belongs.

Upgrade one direct dependency at a time, read its release notes, rerun tests, and review transitive changes. go get -u ./... is intentionally not the default here because a bulk upgrade makes failures and security-impacting changes harder to attribute.

Find Reachable Vulnerabilities

Install and run Go's vulnerability scanner

$go install golang.org/x/vuln/cmd/govulncheck@latest

// Install the official scanner locally; the CI example below pins a reviewed version.

$govulncheck ./...

// Analyze call graphs so the report distinguishes imported vulnerable code from vulnerable functions your program can reach.

Finding	Meaning	Response
Module is listed	A dependency version has a known advisory	Read the advisory and affected symbols
Vulnerable symbol is reachable	Your code can call the affected path	Upgrade or mitigate before release
Vulnerable symbol is not called	Exposure is lower, not zero	Plan the upgrade and document the decision
No findings	No known reachable issue in the current database	Keep scanning; absence of evidence is not a guarantee

Pin Build Tools and Produce an SBOM

Gotools.go-keeps-tool-versions-reviewable.go

8 linesLn 1, Col 1Go

A tools file records tool modules in the dependency graph without compiling them into the application. Teams may instead pin exact versions in CI commands; the essential rule is that `latest` must not decide a production build.

Generate and inspect a software bill of materials

$go build -trimpath -o dist/tasker ./cmd/tasker

// Build the release candidate from the reviewed module graph.

$syft packages file:dist/tasker -o cyclonedx-json > dist/tasker.sbom.json

// Create a machine-readable inventory that can travel with the artifact.

$go version -m dist/tasker

// Inspect the Go version, module path, dependencies, and build settings embedded in the binary.

Enforce the Policy in CI

Create .github/workflows/security.yml before adding the code

$mkdir -p .github/workflows && touch .github/workflows/security.yml

// touch preserves an existing file, so the same command is safe when revisiting the lesson.

.github/workflows/security.yml

name: dependency-security

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: "1.26.x"
          cache: true
      - run: go mod verify
      - run: go test ./...
      - run: go install golang.org/x/vuln/cmd/govulncheck@v1.1.4
      - run: govulncheck ./...

The workflow grants read-only repository access, verifies module content, proves behavior, and scans reachable code. Pin the scanner to the version your team has reviewed, then update that pin deliberately.

Never suppress a scanner globally

If a finding cannot be fixed immediately, document the advisory, reachability, compensating control, owner, and expiry date. A broad ignore flag turns a temporary exception into invisible permanent risk.

Quiz & Practice

Question 1 / 2

What does `go mod verify` establish?

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.