Supply chain attack

What it means

A supply chain attack reaches you through something you depend on rather than through your own code. A library you install, a tool in your build, an extension in your editor, or a vendor with access to your systems.

It works because you trust these things by default. You install a package and it runs on your machines and in your releases without anybody reviewing what changed.

Why it matters

You inherit the security of everything you install, so what you ship matters as much as what you write. Attackers prefer one compromised package used by thousands of companies to attacking those companies one at a time.

It reaches your customers too. If something malicious lands in your release, you become part of their supply chain. The conversation that follows is about your process rather than the attacker's. The window tends to be short, so what separates teams is how fast they can tell whether they pulled the bad version.

How it shows up

The practical questions are about your build. Do you know everything that goes into a release? Do you pin versions, so a package cannot change under you overnight? Who can publish, and do they use multi-factor? Can a build script reach the internet freely?

A maintained inventory of components, plus alerts when somebody reports one of them, is the baseline. Most of the damage in real cases came from things nobody had written down. Review who can reach your build as well. A pipeline that deploys to production is as sensitive as production, and usually has looser access. An SBOM answers the first question.