Supply-Chain Attacks: Lessons from 2023
Table of contents
- Key takeaways
- Attack patterns
- Zero-day exploitation in enterprise products
- Build/release pipeline compromise
- Typosquatting and dependency confusion
- Practical defences: four layers
- SBOM (Software Bill of Materials)
- Artefact signing with Sigstore
- SLSA for pipeline integrity
- Continuous scanning
- What’s harder
- Conclusion
Actualizado: 2026-05-03
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 legally — than preventing it.
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 sophisticated variant: dependency confusion — an attacker uploads a package to a public registry with the same name as a private internal one, and certain package-manager configurations prefer the latest version from the public registry.
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.
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.
Also see the NIS2 directive — which includes supply-chain security as an explicit obligation in its 10 minimum categories — and secrets management with Vault, where credentials compromised in the supply chain are a frequent entry vector.
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 + scanning covers most practical cases at reasonable cost. Teams waiting “until something happens” end up paying the reputational and legal price when it does.
