Supply Chain Threats

A software supply chain attack compromises an organization not by breaching it directly, but by corrupting something it trusts and consumes: a library, a build tool, a container base image, or an update server.

Because modern software is assembled from hundreds of third-party components, a single poisoned link is inherited by every downstream consumer. The attacker invests once and reaches many victims.

• Trust inversion — the security boundary moves outside your own code
• Transitive blast radius — one bad package flows to thousands of builds

When you add one direct dependency, you often pull in dozens of transitive ones you never chose. A typical Node or Python app declares a handful of packages but resolves to hundreds.

List the full resolved tree, not just the manifest, to see what you actually ship:

Attackers publish malicious packages with names that resemble popular ones, betting on a fatal typo.

• Typosquatting — reqeusts instead of requests
• Combosquatting — python-requests mimicking the real name
• Dependency confusion — publishing a public package with the same name as your internal private one, so a misconfigured resolver fetches the attacker version

Defend by pinning a trusted internal registry and using scoped or namespaced private packages.

A legitimate, widely trusted package can turn hostile if its maintainer account is compromised or a malicious contributor gains publish rights.

Recent real-world incidents show attackers phishing maintainer credentials, then pushing a poisoned patch release that exfiltrates tokens during install.

• Require 2FA on all publishing accounts
• Prefer packages with scoped publish tokens and protected releases
• Watch for unexpected new maintainers on critical dependencies

Many ecosystems run code at install time, before your app ever runs. An npm install can execute a postinstall hook that steals environment variables or SSH keys.

Disable arbitrary install scripts in CI and audit any package that needs them:

The build environment itself is a high-value target. If an attacker poisons a compiler, CI runner image, or a build plugin, every artifact it produces is backdoored even when your source code is clean.

The classic example is a trojanized update mechanism that signs malware with a legitimate code-signing key, so victims accept it as authentic.

• Treat build infrastructure as production with full hardening
• Use ephemeral, reproducible build runners
• Separate signing keys from the build host

A lockfile pins exact versions and content hashes, so a re-resolve cannot silently swap in a different artifact. Always commit it and let CI verify it rather than re-resolving freely.

The integrity field stores a hash; if the downloaded tarball does not match, the install fails.

Known-vulnerable versions (tracked as CVEs) are the most common supply chain weakness. Software Composition Analysis (SCA) tools cross-reference your resolved dependencies against vulnerability databases.

Run scans in CI and fail builds on critical findings:

Floating version ranges (^1.2.0) let new releases flow in automatically, which is convenient but exposes you to a malicious patch.

• Pin to exact versions and review upgrades deliberately
• Pin by digest for container images, not by mutable tags like latest
• Vendor critical dependencies into your own repo or mirror so an upstream deletion cannot break or poison you

Securing the supply chain is ongoing, not a one-time scan. You need to know what you ship, where it came from, and when it becomes vulnerable.

• Generate an SBOM for every release (next lesson)
• Capture build provenance so you can prove how an artifact was produced
• Subscribe to advisories so a newly disclosed CVE triggers re-evaluation of already-shipped builds

Map every stage where untrusted input enters: developer machines, source control, dependency registries, the build system, artifact storage, and the update channel. Each is a potential injection point.

For each stage ask: who can write here, what would a compromise let them do, and how would I detect it? This produces a prioritized list of controls rather than a generic checklist.

Test your understanding of a common supply chain attack class.

You learned why dependencies are attack vectors and how to reduce that exposure.

• Trust inversion means your security depends on third parties you do not control
• Key threats: typosquatting, dependency confusion, maintainer takeover, malicious install scripts, and compromised build tooling
• Core defenses: lockfiles with integrity hashes, SCA scanning, exact pinning by digest, 2FA on publishers, and continuous monitoring

Next, you will inventory exactly what your software contains with an SBOM.