Reproducibility, Security, and Supply Chain
Build and release systems depend on source control, dependencies, package registries, compilers, CI runners, credentials, artifact stores, and signing keys.
What this module covers
Reproducible versus repeatable builds Hermeticity and environmental inputs
Pinning tools, dependencies, and container images Build provenance and attestations
Checksums, signatures, and artifact verification Software Bill of Materials (SBOM) Dependency confusion and typosquatting Secret scanning and credential rotation
Build isolation and untrusted pull requests Secure release signing and key management License and policy checks
Incident response for compromised dependencies
15.1 Supply-chain threat model
Build and release systems depend on source control, dependencies, package registries, compilers, CI runners, credentials, artifact stores, and signing keys. A compromise at any point can affect the final artifact.
15.2 Checksums and signatures
A checksum detects whether bytes match an expected digest when the expected digest is trusted. A digital signature can bind an artifact to a signing key. Neither mechanism alone proves the source was benign; trust depends on key management, provenance, and pipeline integrity.
Example checksum verification (command availability varies):
Terminal session (coreutils 8.32, Ubuntu 22.04 on WSL2) on 4 KiB of random test data, then with one byte overwritten:
Only trust a checksum file when its origin and integrity are verified.
The last check above failed after a single byte of firmware.bin was overwritten — a checksum detects any change, but only if the expected digest itself comes from a trusted, integrity-protected source.
sha256sum firmware.bin
sha256sum -c SHA256SUMS$ head -c 4096 /dev/urandom > firmware.bin
$ sha256sum firmware.bin
87e985e115a78ea4cdfeb6e284bac3703d466141e479cd9041b5196039e30973 firmware.bin
$ sha256sum firmware.bin > SHA256SUMS
$ sha256sum -c SHA256SUMS
firmware.bin: OK
$ printf 'X' | dd of=firmware.bin bs=1 seek=100 conv=notrunc status=none
$ sha256sum -c SHA256SUMS
firmware.bin: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
[exit status 1]15.3 SBOM
A Software Bill of Materials lists components included in a software product, often including package names, versions, licenses, and relationships. SBOM formats and depth vary. Generate it for the actual release artifact and keep it associated with release metadata.
15.4 Provenance and attestations
Provenance records how an artifact was produced: source revision, build process, builder identity, dependencies, and output digest. Attestations can be signed or otherwise protected. Verify provenance according to a defined policy rather than accepting any attached metadata.
15.5 Dependency attacks
Typosquatted package names.
Dependency confusion between public and private registries.
Compromised maintainer accounts.
Malicious install scripts.
Unreviewed dependency updates.
Unpinned tools downloaded at build time.
Mitigations include registry controls, lockfiles, scoped package names, review, scanning, provenance, least privilege, and rapid incident response.
15.6 Secure build isolation
Untrusted contributions should not have access to signing keys, deployment credentials, private cache namespaces, or production permissions. Use isolated runners and explicit permission boundaries. Treat build scripts as executable code; dependency installation itself can run scripts.
15.7 Release signing and key management
Document who can sign releases, where keys live, how they are rotated, how revocation works, and how consumers verify signatures. Prefer protected signing services or hardware-backed key storage where appropriate. Never commit private signing keys to source control.
Quiz
? Why is a checksum not the same as a signature?
+ Anyone can compute a checksum; a signature binds the artifact to a private key. :: An attacker who replaces the file can replace a plain checksum too.
- Checksums are less accurate. :: SHA-256 detects any change.
- Signatures are faster. :: Speed is irrelevant.
- They are the same. :: They protect against different threats.
? What is dependency confusion?
+ A build resolves a public package with the same name as an internal one. :: Scope names and pin registries.
- Two packages with similar features. :: Not a security issue.
- A lockfile merge conflict. :: Unrelated.
- A missing transitive dependency. :: That is a build error.
? Which belong in provenance? (select all that apply)
+ Source revision :: Which commit was built.
+ Builder identity :: Which system built it.
+ Output digest :: Which bytes were produced.
- The developer's password :: Never.