What the software supply chain is

Your software supply chain is everything that influences the code you run in production, beyond the lines your team writes:

• Source: your repositories, their branches and who can push to them.
• Dependencies: open source and commercial packages, and their own dependencies, often hundreds deep.
• Build: compilers, package managers, CI runners, build scripts and the actions or plugins they use.
• Artifacts: packages, container images and binaries, and the registries that store them.
• Deployment: the systems that pull artifacts and run them.

Each link can be attacked, and an attack on one widely used link reaches many victims at once. That is why supply chain attacks are attractive.

Real patterns of attack

• Malicious packages published with names close to popular ones, hoping for typing mistakes, or with names that match internal package names, hoping a build tool picks the public one (dependency confusion).
• Compromised maintainers: stolen credentials used to publish a malicious version of a legitimate package.
• Long term social engineering: the xz utilities case in 2024, where a contributor built trust over a long period before inserting a backdoor into release tarballs. It was caught by an engineer who noticed unusual performance in SSH logins.
• Compromised CI components: in 2025 a popular GitHub Action was modified so that workflows using it printed secrets into build logs. Repositories that referenced the action by a mutable tag picked up the change automatically.
• Tampered builds: an attacker with access to the build system alters the artifact after tests pass.

The defender's questions

A useful programme answers four questions:

1. What is in our software? A complete and current inventory of dependencies, captured as SBOMs.
2. Is each component trustworthy and up to date? Hygiene, vetting and fast updates.
3. Was the artifact built from the source we reviewed, by the system we trust? Provenance and signing.
4. Can we respond quickly when something upstream goes wrong? Visibility, process and practice.

Proportionate effort

Not every team needs the most advanced controls. Start with the steps that block the most common attacks: lock files, pinned CI actions, automated updates and secret hygiene. Then add SBOMs, signing and provenance as your release process matures. This course follows that order.