Almost every modern organisation depends on a long chain of vendors, open-source libraries, managed services, and hardware suppliers. Attackers have noticed: instead of breaching a hardened target directly, they compromise something it trusts. Incidents like SolarWinds, Log4j, MOVEit, 3CX, and the wave of malicious npm and PyPI packages all show how one weak link can ripple out to thousands of downstream victims. Treating the supply chain as part of your attack surface is now essential.
What "supply chain" really means
The software supply chain is broader than just the libraries imported into your code.
- Open-source dependencies – Direct and transitive packages from npm, PyPI, Maven, NuGet, Go modules, Cargo, and similar registries.
- Commercial software and SaaS – Endpoint agents, monitoring tools, identity providers, CRMs, ticketing systems, and any vendor with access to your data or networks.
- Build and CI/CD systems – Source repos, build runners, container registries, signing keys, and the pipelines that turn code into deployable artefacts.
- Hardware and firmware – Servers, network gear, IoT devices, and the firmware/microcode running on them.
- Managed service providers – MSPs, MSSPs, cloud providers, and contractors with privileged access to your environment.
Any of these can be the entry point. A small library, a build agent, or a managed IT provider can each give an attacker a foothold inside many customers at once.
How supply chain attacks happen
Attackers use a handful of repeatable patterns.
- Compromised updates – A legitimate vendor's update mechanism is abused to push a backdoored binary to its customers, as seen with SolarWinds and 3CX.
- Malicious or hijacked packages – Typosquatting, dependency confusion, and abandoned packages taken over by new maintainers ship malicious code through trusted registries.
- Vulnerable transitive dependencies – A critical flaw in a deep, indirect dependency (e.g. Log4j) affects every application that pulls it in, often without the team realising it's even installed.
- Build pipeline compromise – Stolen CI tokens, poisoned build caches, or unsigned artefacts let attackers inject code between commit and deployment.
- Third-party access abuse – Stolen credentials or tokens from a vendor with admin access (support tools, RMM platforms, identity providers) give attackers a direct route into customer environments.
The common theme is trust: each victim already trusted the compromised component, so traditional perimeter and signature-based controls rarely catch the initial intrusion.
Building an inventory you can defend
You cannot protect what you do not know you have. A practical starting point is an accurate inventory at three layers.
- Software Bill of Materials (SBOM) – Generate SBOMs (CycloneDX or SPDX) for every application and container image during the build, not after. Store them so you can query "which products use library X version Y?" when the next Log4j drops.
- Vendor and SaaS register – Track every external service, what data it processes, who owns the relationship, what access it has, and when it was last reviewed. Tie this to your identity provider so dormant integrations are flagged.
- Asset and access map – Know which third parties (MSPs, contractors, integrators) have privileged access to your systems, and through which accounts or tokens.
Good inventories turn a future zero-day from a frantic hunt into a targeted patch list.
Controls that actually reduce risk
You will not eliminate supply chain risk, but a layered approach blunts most realistic attacks.
- Vet and tier suppliers – Risk-rank vendors by data sensitivity and access. Require security questionnaires, SOC 2 or ISO 27001 evidence, and breach-notification clauses for high-tier suppliers; keep checks proportionate for low-risk ones.
- Harden the build pipeline – Pin dependency versions and hashes, use lockfiles, prefer signed artefacts, and adopt frameworks like SLSA. Restrict who can modify CI configuration and protect signing keys with HSMs or cloud KMS.
- Scan continuously – Run SCA (Software Composition Analysis) and container scanning on every build, not just at release. Feed results into ticketing with severity-based SLAs.
- Limit blast radius – Apply least privilege to vendor accounts, scope API tokens narrowly, segment networks so a compromised agent cannot reach the crown jewels, and rotate credentials regularly.
- Monitor for anomalies – Alert on unexpected outbound connections from build agents, unusual behaviour from vendor accounts, and new processes spawned by signed binaries (a common post-compromise pattern).
Preparing for the next incident
Assume that one of your suppliers will be breached. A practised playbook turns a crisis into a manageable response: an up-to-date SBOM query lets you identify exposure in minutes; documented vendor contacts get answers faster than scraping a status page; and pre-approved isolation steps (disable integration, revoke token, block egress) buy time while you investigate. Run tabletop exercises that include third-party scenarios — "our identity provider is compromised", "our CI runner pushed a tainted build" — so the first time you do this is not during a real incident. Supply chain security is less about preventing every compromise and more about shrinking the window between "vendor X is breached" and "we know we are safe".