Security
Supply-chain security: harden a release pipeline end to end
Reading about supply-chain attacks is not the same as stopping one. Take a small service, walk it through each layer of defense — lockfile, registry precedence, SBOM, provenance, signing — and prove each control actually catches a planted attack, not just that you turned it on.
Turn the unit’s layered model into a reproducible hardening loop: harden the install step, kill dependency confusion, inventory the build with an SBOM, and gate deploys on verifiable provenance — proving each control with a planted attack it must catch.
Take a small service (your own or a fresh create-next-app / NestJS scaffold) and harden its full supply chain — install step, registry precedence, SBOM, and signed provenance — then demonstrate each control by planting an attack it must block.
- A before/after table of controls: install command, version pinning, --ignore-scripts, dependency review, registry precedence, SBOM, provenance, signing, token scope — each marked present/absent with the config diff that enabled it.
- Evidence each planted attack is caught: the failing `npm ci` hash-mismatch log, the blocked confusion resolution, and the rejected cosign verify — pasted output, not described.
- A generated SBOM attached to the artifact plus a worked query showing you can answer 'is component X at version Y present?' against it.
- A one-paragraph write-up mapping each control to the documented incident it defends against (lockfile/hash → event-stream/ua-parser-js; precedence → Birsan confusion; provenance/signing → xz-utils), and why hashes alone were insufficient.
- Add a one-page release runbook: the order controls run in CI, what each gate checks, what a failure at each gate means, and the verification checklist before a release is allowed to ship.
- Raise the SLSA target to L3: build in an isolated, hardened runner with non-falsifiable provenance, and document what changed from your L2 setup.
- Add a transitive-CVE drill: subscribe the SBOM to a vulnerability feed, simulate a CVE in a deep dependency, and show you can list every affected build/service from the SBOM in under a minute.
- Repeat the signing + verify gate on a second ecosystem (e.g. container image and an npm package, or a Python wheel) and compare how provenance and verification differ across registries.
This is the loop you will run on every real service: harden the install step first (lockfile, npm ci, exact pins, —ignore-scripts), kill confusion with scoped names and registry precedence, inventory the build with an SBOM, and gate deploys on signed, verifiable provenance — with least-privilege CI tokens throughout. Each control maps to a documented incident, and the only honest proof is a planted attack the control actually blocks. Doing it once end to end on a small service makes the production version muscle memory.