Software Supply Chain Attacks and How to Defend Against Them

A software bill of materials is the foundation. Without a generated, stored inventory of every direct and transitive dependency in each release, the question "are we affected by this new vulnerability?" takes days to answer — and by then the exploit is public.

Typosquatting publishes a package one keystroke away from a popular one. Dependency confusion abuses resolvers that prefer a public package over your private one with the same name. Maintainer compromise takes over a legitimate account and pushes a malicious minor release. Build-system compromise is the most damaging: the source stays clean while the artefact is modified in transit.

Treat your CI system as production infrastructure, because it holds credentials to everything. Build agents should be ephemeral, secrets should be short-lived tokens rather than static keys, and third-party CI actions should be pinned to a commit hash rather than a mutable tag.

Signing artefacts and verifying those signatures at deployment closes the last gap: even if something is modified after the build, it will not deploy.

Automatic dependency updates are good for patch velocity and bad for supply chain safety when merged unread. A reasonable compromise is automated updates with a mandatory human review of the diff for anything that touches install scripts, network calls or credentials.