Supply Chain

Most of the code you ship, you didn't write. Four labs on securing everything between the package registry and the image your cluster runs.

A typical Node service has hundreds of transitive dependencies, a base image with hundreds of OS packages, and a pipeline full of third-party tools. This chapter finds known-vulnerable libraries, stops install-time scripts from running code you never reviewed, answers 'are we affected?' from an SBOM in minutes, and makes a tampered image impossible to deploy.

1. LAB 1.1CRITICALCWE-1321 · Prototype pollution · CVE-2018-3721

   A four-year-old lodash in the lockfile

   package-lock.json pins a lodash version with a published prototype-pollution vulnerability, used on a code path that deep-merges request bodies.

2. LAB 1.2CRITICALCWE-506 · Embedded malicious code · CICD-SEC-3

   Code that runs when you type npm install

   Packages can run arbitrary scripts at install time — on developer laptops and CI runners full of tokens — before a single test runs.

3. LAB 1.3HIGHExecutive Order 14028 / NTIA SBOM minimum elements

   'Are we affected?' in five minutes, not five days

   A critical vulnerability in a widely used library is announced on a Friday evening. Leadership asks which of our images contain it. Nobody knows.

4. LAB 1.4HIGHSLSA · Build integrity · CICD-SEC-9 (improper artifact integrity validation)

   The image your cluster runs — is it the one CI built?

   Anyone who can push to the registry can replace shoplite:1.4.0 with something else, and every node that pulls that tag will run it.