Security · Mixed

The code supply chain

In one line: Your code is a minority of what runs in production — most of the risk is in the packages you brought and the tools that built them.

What to do with dependencies

Version locking in a lockfile, a regular scheduled update instead of big jumps once a year, and automated vulnerability scanning in the build pipeline.

Check before adding: when it was last updated, how many maintainers, and how many dependencies it drags in. A package that pulls dozens of packages for one function isn't a saving.

The pipeline itself is a target

Build tools have access to secrets and production. Limit permissions, don't run untrusted code in a privileged context, and set that install scripts don't run on build servers without control.

Knowing what runs

An up-to-date component list per release. When a severe vulnerability is published, the first question is “is this in ours” — and whoever has no list wastes a day on the search.

Going deeper

Sign packages and images and verify the signature before deployment. And in the repository: require peer review, block direct pushes to the main branch, and verify the identity of whoever pushes. Most supply-chain incidents start with a breached developer account, not a code vulnerability.

Security Long-term maintenance Vendors & third parties

Next: Encryption: when, where and how not to get it wrong · Previous: Securing public interfaces · Back to library