You ship far more code than you write. Learn what the software supply chain is, the attack classes that target it — dependency confusion, typosquatting, build-system compromise — and the frame for defending it.
Your build output is assembled from many inputs you did not write: open-source dependencies and their transitive dependencies, base container images, build tools, CI/CD plugins, and the infrastructure that assembles them. The software supply chain is that entire graph. Securing it means every link — source, dependencies, build, and distribution — is trustworthy, because an attacker only needs to poison one.
Everything between "developer intent" and "running in prod":
source code -> dependencies -> build system -> artifact -> registry -> deploy
| | | | | |
commit npm/pip/etc CI/CD + image/ registry admission
integrity + transitive plugins binary trust control
An attacker poisons ANY link and your users run their code with
your reputation. Defense must cover the whole chain, not just
"scan my dependencies".Supply chain attacks are attractive because one compromise reaches thousands of downstream victims. Knowing the specific attack classes tells you what to defend. These are not hypothetical — each maps to a well-known real-world incident that cost the industry dearly.
Attack class How it works Real example
Build compromise attacker owns the CI/CD, injects SolarWinds (2020)
malware into a signed release
Malicious maintainer / attacker gains commit access to xz-utils backdoor
account takeover a trusted package, adds a backdoor (2024)
Dependency confusion publish a public package with many F500 (2021)
an internal name; the resolver
pulls the attacker's version
Typosquatting publish 'reqeusts' hoping for a ongoing on npm/PyPI
typo of 'requests'
Compromised dependency a legit package's release is event-stream (2018)
hijacked to add malicious codeTwo frameworks organize supply chain defense: NIST's Secure Software Development Framework (SSDF) describes practices, and SLSA (Supply-chain Levels for Software Artifacts) gives a ladder of integrity guarantees for the build. You do not need to memorize them — use them as a checklist mapping each link in the chain to a concrete control you will build in this course.
Link in the chain Threat Control (this course)
dependencies known CVEs SCA scanning (lesson 2)
dependencies "what's even in here?" SBOM (lesson 3)
artifact tampering / fakes signing - cosign (lesson 4)
build "was it built like provenance / SLSA
we think?" (lesson 5)
resolution confusion/typosquat pinning, private registry,
verification (lesson 6)
SLSA levels (build integrity ladder):
L1 scripted build L2 signed provenance
L3 hardened, non-falsifiable build L4 hermetic, reproducible