Supply-Chain Security

Your dependencies are your attack surface

A modern Go service imports dozens — sometimes hundreds — of modules transitively. Every one runs with your privileges, and recent history (the xz backdoor, npm’s event-stream, countless typosquats) shows attackers increasingly target the supply chain rather than your code directly.

graph TD
YOU["your code"] --> D1["direct dep"]
D1 --> T1["transitive dep"]
D1 --> T2["transitive dep"]
T2 --> T3["transitive dep<br/>(who reviewed this?)"]
YOU --> GOSUM["go.sum<br/>(integrity)"]
YOU --> GVC["govulncheck<br/>(known CVEs)"]
GOSUM --> SAFE["verified, vuln-scanned build"]
GVC --> SAFE

Go gives you strong built-in defenses; the job is to use them.

Integrity: go.sum and the checksum database

go.sum records a cryptographic hash of every module version (and its go.mod). On download, the toolchain verifies the content matches — a tampered or swapped module fails the build. The public checksum database (sum.golang.org) is a transparency log of those hashes, so even a malicious proxy can’t serve you a different module than everyone else got.

This runs here: a tiny model of what go.sum does — hash the module content, compare to the expected hash, and reject a tampered dependency:

package main

import (
"crypto/sha256"
"encoding/hex"
"fmt"
)

// hash models the go.sum content hash of a module version.
func hash(content string) string {
h := sha256.Sum256([]byte(content))
return "h1:" + hex.EncodeToString(h[:])[:16] // shortened for display
}

func main() {
// The hash recorded in go.sum when the dep was first added.
expected := hash("package mathutil; func Add(a,b int) int { return a+b }")

// What the proxy actually served on this build:
good := "package mathutil; func Add(a,b int) int { return a+b }"
evil := "package mathutil; func Add(a,b int) int { exfiltrate(); return a+b }"

for name, served := range map[string]string{"genuine": good, "tampered": evil} {
	if hash(served) == expected {
		fmt.Printf("%-9s -> hash OK, build proceeds\n", name)
	} else {
		fmt.Printf("%-9s -> HASH MISMATCH, build ABORTS\n", name)
	}
}
}

The tampered module — with an added exfiltrate() call — produces a different hash and is rejected, exactly as the real toolchain aborts on a go.sum mismatch. Commit your go.sum; it’s how everyone who builds your code gets byte-identical dependencies.

Known vulnerabilities: govulncheck

Integrity ensures you got the intended dependency — but the intended version may have a disclosed CVE. govulncheck cross-references your modules against the official Go vulnerability database and uses call-graph analysis to report only the vulnerabilities your code actually reaches:

go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...   # run in CI on every PR and on a schedule

Because it reports reachable vulns, you triage real exposure instead of every CVE in a transitive dependency you never call. Run it on a schedule too — a vuln disclosed today may be in code you shipped last month.

The habits that close the gaps

• Minimize dependencies. Prefer the stdlib; vet anything you add; prune what you don’t use. Less third-party code is less that can betray you.
• Pin and review. go.mod pins versions; review the diff on upgrades, and be wary of a sudden maintainer change or a version that adds network/exec calls.
• Guard internal modules. Set GOPRIVATE/a private proxy so internal module names can’t be hijacked by a public dependency-confusion package.
• Watch the names. Typosquats (githib.com, one-letter-off package names) rely on a careless import. Read import paths.
• Produce an SBOM and automate updates (Dependabot/Renovate) so patches land fast.

See also

• Secrets management — protecting the CI tokens and keys the pipeline uses.
• Building security tools — reproducible, static, signed binaries.
• Attacking weak crypto — govulncheck for vulnerable crypto libraries.
• The go toolchain (stdlib) — modules, go.sum, and minimal version selection.

That completes the Security track — from the hacker mindset through recon, cryptography, and defensive engineering. Next, take these practices into production with the Cloud-native track.

Related topics