Updated: 2026-07-07

2023 has been a particularly illustrative year for software supply-chain attacks. MOVEit[1] in May-June affected hundreds of organisations. 3CX[2] in April exposed millions to a compromised binary. Incidents in npm[3], PyPI[4], and similar registries remain constant. The patterns are clear enough to define effective defensive practices.

Key takeaways

  • Three patterns dominate incidents: zero-day exploitation in trusted products, build/release pipeline compromise, and typosquatting/dependency confusion in public registries.

  • The four most effective defensive layers are SBOM, artefact signing with Sigstore, SLSA for pipeline integrity, and continuous scanning.

  • Verifying that source code matches the binary (SLSA L3) is the hardest area: few open projects achieve it.

  • Automated scanners are necessary but not sufficient: they don’t detect zero-day malware or pipeline-side compromises.

  • Waiting until something happens before investing always costs more, in reputation and, sometimes, legally too.

Attack patterns

From 2023’s public incidents, three dominant patterns emerge:

Zero-day exploitation in enterprise products

MOVEit Transfer[5] is the canonical case: the attacker (Cl0p ransomware group) exploited a zero-day SQL injection vulnerability, accessing data from hundreds of organisations using the product for secure file exchange. It wasn’t injected malware; it was a critical vulnerability in a trusted product.

Lesson: depending on third parties means treating their security as part of yours. Audit, monitor, and have response capability independent of the vendor.

Build/release pipeline compromise

3CX (April) was victim of another supply-chain attack: one of their suppliers (Trading Technologies) had a malicious installer; that binary was used in 3CX’s development environment, compromising their own builds. 3CX customers received official updates with correctly signed malware.

This is the most feared attack: the attacker compromises neither your code nor your servers, but your development-tool supplier.

Typosquatting and dependency confusion

Malicious packages in npm, PyPI, and similar registries with names similar to popular ones (e.g., python-sqlite3 vs sqlite3-python). Throughout 2023, security research teams report dozens of new malicious packages weekly.

A more elaborate variant is dependency confusion: an attacker uploads a package to a public registry using the same name as a private internal one, and some package-manager configurations end up preferring the newer version from the public registry over the internal one.

Practical defences: four layers

These four layers complement each other and cover most practical cases at reasonable cost:

SBOM (Software Bill of Materials)

Complete inventory of software components, including versions, sources, and hashes. Standard formats: SPDX[6] and CycloneDX[7]. Generated automatically in the build pipeline with tools like Syft[8].

Value: when a vulnerability in a library is announced, you immediately know which of your products contain it.

Artefact signing with Sigstore

Sigstore[9] is open-source infrastructure for signing software artefacts. With cosign[10], signing a container image is a one-liner. The signature is anchored in Rekor[11], a public transparency log.

Value: consumers of your software can verify the binary comes from you, not from an attacker impersonating your CI.

SLSA for pipeline integrity

SLSA[12] (Supply-chain Levels for Software Artifacts) defines four maturity levels, from L1 (build with basic provenance) to L4 (hermetic and reproducible build on isolated hardware). Aiming at L2 or L3 is feasible for most teams with moderate investment.

For JavaScript/Node: npm provenance[13] since April allows publishing packages with verifiable provenance linked to GitHub Actions.

Continuous scanning

Tools like Trivy[14], Grype[15], and Snyk[16] continuously scan dependencies and images. Integrated in CI + production runtime, they catch known vulnerabilities.

Not a silver bullet: they don’t detect zero-day malware or pipeline-side compromises, but they cover the bulk of risks at low operational cost.

It’s worth remembering where this defensive machinery came from. The 2020 SolarWinds Orion hack was the precedent that set off the alarm: SolarWinds acknowledged at the time that as many as 18,000 customers had installed the Orion update carrying the injected malware[17], though the company later estimated the number of organisations actually compromised was far smaller, under 100.

Diagram of the 2020 SolarWinds Orion hack process, the precedent that put software supply-chain attacks on everyone's radarDiagram of the 2020 SolarWinds Orion hack process, the precedent that put software supply-chain attacks on everyone’s radar

What’s harder

Three areas where defences remain immature:

  • Verifying source code matches the binary. SLSA L3 requires it but few open projects achieve it.

  • Auditing transitive dependencies. With tens of thousands of transitive packages, manually auditing each is impossible. Automated scanners help but aren’t exhaustive.

  • Trust in individual open-source developers. Faker.js and similar cases have shown the risk of sole maintainers sabotaging their own packages.

Generic diagram of the initial security-incident management process, the kind of playbook triggered by any supply-chain compromise alertGeneric diagram of the initial security-incident management process, the kind of playbook triggered by any supply-chain compromise alert

Also see the NIS2 directive, which includes supply-chain security as an explicit obligation among its ten minimum categories, and secrets management with Vault, where leaked credentials are a common entry point into the supply chain.

Conclusion

Supply-chain attacks aren’t going away: they’re too attractive a surface with too many weak entry points. The combination of SBOM, artefact signing, SLSA, and scanning covers most practical cases at reasonable cost. Teams that wait until something happens before investing end up paying the reputational and legal price when it does.

Spanish version: Ataques a la cadena de suministro: lecciones de 2023.

Sources

  1. MOVEit
  2. 3CX
  3. npm
  4. PyPI
  5. MOVEit Transfer
  6. SPDX
  7. CycloneDX
  8. Syft
  9. Sigstore
  10. cosign
  11. Rekor
  12. SLSA
  13. npm provenance
  14. Trivy
  15. Grype
  16. Snyk
  17. 18,000 customers had installed the Orion update carrying the injected malware