In March 2024, a curious developer noticed that his SSH connection (the protocol used to log in to servers remotely) took 500 ms longer than usual. Digging into it, he found a backdoor (a hidden way in, planted on purpose) inside XZ Utils, a compression utility present on nearly every Linux server. The malicious code allowed remote code execution through SSH. This sophisticated attack had been prepared for two years by a contributor who had become a maintainer of the project.
Welcome to the world of supply chain attacks: the attacker no longer aims at your application directly: they compromise an upstream component to reach everyone who depends on it. The software supply chain is everything that sits between a line of code and the application running in production: the libraries you import, the tools that build it, the registries that store it, the suppliers that host it.
What you will learn
- Recognize the six entry points of a supply chain attack and the real scope to protect.
- Place the four layers of responsibility and the R1, R2, R3 progression.
- Explain why these attacks work and who carries them out.
- Remember the landmark attacks of 2024-2025 and the mistakes they reveal.
- Find which lesson of the module covers which link of the chain.
What is a supply chain attack?
A supply chain attack targets the components used to build a piece of software rather than the software itself. The idea is simple: compromising a component used by 10,000 projects potentially compromises 10,000 projects at once.
The 6 attack vectors
The diagram gathers the six entry points that all lead to your application: none of them goes through your own code, all of them go through what you consume.
Attackers use six main entry points:
-
Typosquatting: the attacker publishes a package with an almost identical name (
lodahsinstead oflodash). A typo at install time is enough to compromise your project. -
Dependency confusion: your organization uses a private package named
auth-utilson its internal registry. The attacker publishesauth-utilson the public npm registry as version 99.0.0. Some package managers prefer the public registry. -
Compromised maintainer: an exhausted maintainer abandons their project. The attacker takes it over, earns the trust of the community, then injects malicious code into an innocuous update. This is the XZ Utils scenario (2024).
-
Compromised CI/CD: pipelines (CI/CD means continuous integration and delivery, the automation that builds and ships your code) have access to secrets and can change the deployed code. A modified GitHub Action can exfiltrate your tokens or inject code into your artifacts.
-
Known vulnerabilities: unpatched CVEs (public identifiers of known flaws) in your dependencies (Log4Shell, Apache Struts) leave doors open to attackers.
-
Unsigned images: without a signature, there is no way to detect whether a Docker image was modified between its creation and its deployment.
The real scope: much more than artifacts
The 6 vectors above mainly target components and pipelines. But securing the supply chain means covering the whole path from code to production: the developer workstation, the source, the build, the runners (the machines that execute pipeline jobs), the release, the deployment, the runtime, the secrets, the suppliers, AI and the cloud. This is the scope structured by the SOCLE approach (in French), this site's open framework of supply chain requirements, organized in domains grouped into five zones.
Signing and tracing artifacts (SLSA, a framework of build security levels, SBOM, the list of the components you ship, and signing) remains essential, but covers only part of this scope: a malicious maintainer, a compromised workstation or a leaked secret go under the radar of provenance. The SOCLE framework (in French) details the requirements of each domain, and the threat model by families shows where the attacker strikes at each step.
The 4 layers of the supply chain
A complementary reading, by responsibility, helps share the effort between teams:
| Layer | What it contains | Example risks | Who owns it |
|---|---|---|---|
| 1. OSS components | npm, PyPI, Maven dependencies, base images | Typosquatting, maintainer takeover, CVE | Developers |
| 2. Pipeline/Build | CI/CD, runners, build scripts, caches | Exfiltrated secrets, compromised actions | DevOps/SRE |
| 3. Artifacts/Runtime | Deployed images, binaries, registries | Post-build tampering, compromised registry | Ops/Security |
| 4. Third parties/Suppliers | SaaS, managed service providers, external APIs | Compromised supplier, exposed data | CISO/Procurement |
Building maturity: R1, R2, R3
Nobody secures every domain at once. The approach prioritizes effort in three robustness levels: aim for R1 everywhere (achievable hygiene), R2 in production, R3 on the sensitive parts. This progression, not a race to exhaustiveness, guides the rise in maturity.
Each level applies to each domain: one domain can sit at R1 while another aims for R3. The exact levels per requirement are in the SOCLE framework (in French).
The cycle of evidence: SLSA, SBOM, signing
Within this scope, a tooled cycle structures the generation and verification of evidence about artifacts. It is the heart of the SLSA world, and an excellent practical entry point, provided you remember that it covers only part of the scope.
| Step | Key question | Tools/standards | Learn more |
|---|---|---|---|
| Inventory | What am I using? | SBOM, OBOM, Syft | SBOM, XBOM |
| Sign | Where does it come from? | Sigstore, Cosign, Gitsign | Sigstore, Cosign |
| Verify | Is it compliant? | SLSA, Kyverno, Kusari | SLSA (in French), Kusari (in French) |
| Govern | Who validates, reviews, keeps? | VEX, GUAC, workflows | VEX, GUAC (in French) |
| Contract | Do my third parties respect this? | CRA, NIS2, TPRM, clauses | CRA (in French), TPRM |
Why these attacks work
Supply chain attacks exploit structural weaknesses of our software ecosystem.
Implicit trust is the heart of the problem. When you type npm install,
you trust hundreds of maintainers you do not know. Nobody reads the code of
the 500 transitive dependencies (the dependencies of your dependencies) before
installing them.
The leverage is considerable. Compromising a single popular package such as
lodash potentially hits millions of projects. It is far more profitable than
attacking one company at a time.
Detection is a nightmare. The malicious code comes from a "legitimate" source: a trusted maintainer, an official registry. It passes code reviews because nobody suspects a minor update.
The attack surface is immense. A modern project embeds hundreds of third-party components. Each one is a potential entry point. And dependencies have dependencies of their own.
Attackers play the long game. The XZ Utils attacker contributed for two years before injecting his backdoor. This patience makes the threat very hard to detect.
Who attacks and why
Attacker profiles
Supply chain attacks attract a wide range of actors, from opportunists to intelligence services.
Nation-states often carry out the most sophisticated attacks. The XZ Utils attack shows the characteristics that many analysts associate with a state-sponsored operation (two years of preparation, obfuscated code, targeting of the SSH infrastructure), with no official attribution. The goal? Espionage, sabotage, or creating persistent access for future operations.
Criminal groups look for direct profit. A worm like Shai-Hulud (a malware that spreads by itself) collects secrets (npm and GitHub tokens, cloud keys) that can be resold or reused. Others deploy cryptomining (using your machines to mine cryptocurrency) or prepare ransomware (malware that encrypts data and demands a ransom).
Hacktivists use "protestware" to pass political messages. In 2022, the
maintainer of node-ipc sabotaged his own package to protest against the
invasion of Ukraine, wiping files on Russian machines.
Opportunists exploit typosquatting at scale. They publish thousands of packages with names similar to popular packages, hoping to capture authentication tokens or environment variables.
What they are after
Whatever the attacker, the goals overlap: credentials (API tokens, SSH keys), persistent access (backdoors to come back), sensitive data (source code, business secrets), compute resources (cryptomining), and pivot points to attack other targets from your infrastructure.
How they attack
1. Dependency poisoning
The attacker publishes a malicious package that looks like a legitimate one.
Typosquatting: a name close to the real one that traps typos.
npm install lodahs # ❌ Malicious (typo)npm install lodash # LegitimateDependency confusion: a public package with the name of an internal private
package. Package managers often prefer the public registry. Reserving your
scope (@company/) on the public registry closes this door for scoped
packages; names without a scope remain exposed.
# Your internal private package (internal registry, name without scope)auth-utils
# The attacker publishes the same name on public npmauth-utils # Version 99.0.0, can be installed insteadMaintainer takeover: taking over an abandoned package, then injecting malicious code in an innocuous update. The original maintainer has often disappeared, nobody checks.
2. Compromising CI/CD pipelines
Pipelines have access to secrets and can modify the deployed code.
Compromised GitHub Actions: a modified action exfiltrates secrets or
injects code into artifacts. This is what happened with
tj-actions/changed-files in March 2025.
Secrets in logs: a malicious script prints sensitive variables in public logs. In the tj-actions case (see below), the injected code read the secrets from the memory of the runner and printed them in the workflow logs, encoded twice in base64, which is enough to defeat GitHub's automatic masking of secrets.
Shared runners: on shared runners, a malicious job can access data from previous jobs (artifacts, cache, temp files).
3. Attacks on registries
Compromised maintainer accounts: without 2FA (two-factor authentication), a simple phishing message is enough to publish a malicious version of a popular package.
Registry flaws: vulnerabilities that allow modifying packages without authentication. Rare but devastating.
4. Compromising third-party infrastructure
Domain takeover: a legitimate domain or service is bought by a malicious entity. This is what happened with Polyfill.io, bought in early 2024 and accused in June 2024 of serving malicious code to more than 100,000 sites according to Sansec, a figure whose real extent remains debated.
Compromised CDN: code injection into all the distributed files (a CDN, content delivery network, is a service that serves files to websites from servers around the world). A change on the CDN instantly hits every consumer.
Who is concerned in your organization
Supply chain security is not only a technical problem, it involves the whole organization.
Developers are on the front line. Every npm install, every new dependency
added to the project is a security decision. postinstall scripts (scripts a
package runs automatically right after installation) execute on their machine
with their rights.
DevOps and SRE control one of the most exposed vectors: CI/CD pipelines. They manage secrets, runners and registry access. A configuration mistake can expose all the organization's tokens.
Architects define the rules: which dependencies to allow, which registries to use, which attack surface to accept. Their decisions shape the security posture for years.
The CISO (chief information security officer) carries the responsibility for governance. With the CRA (the EU Cyber Resilience Act), whose reporting obligations have applied since 11 September 2026, they must make sure the processes are in place: SBOM, supplier risk assessment, incident notification.
Legal enters the loop with the new regulations. Customer contracts demand SBOMs, the CRA imposes compliance obligations. The CRA provides for fines of up to €15 million (see below).
Landmark attacks of 2024-2025
XZ Utils Backdoor (March 2024)
CVE-2024-3094: one of the most sophisticated supply chain attacks ever documented.
A contributor named "Jia Tan" earned the maintainer's trust over two
years. He introduced malicious code in versions 5.6.0 and 5.6.1 of
liblzma. The backdoor modified sshd (the SSH server) to allow
remote code execution.
Potential impact: remote code execution on systems that embedded these
versions of liblzma, where sshd was indirectly linked to it through
systemd (the case on some distributions). The stable releases of the
major distributions had, for the most part, not yet received these versions.
Polyfill.io CDN (June 2024)
The polyfill.io domain, used by 100,000+ websites according to Sansec
(the alert dates from 25 June 2024), had been bought in early 2024 by a
Chinese company, later identified by third-party analyses as Funnull. The
served code was then modified to redirect part of the visitors to scam
and online betting sites. Other estimates are much higher.
tj-actions/changed-files (March 2025)
CVE-2025-30066: cascading compromise of GitHub Actions.
The attack started with reviewdog/action-setup@v1, then spread to
tj-actions/changed-files. The attackers redirected most of the version
tags to a malicious commit, to exfiltrate CI/CD secrets into the logs.
The fix is version 46.0.1.
Impact: the action was used by more than 23,000 repositories, and several leaked secrets into their public logs.
Shai-Hulud npm Worm (September-November 2025)
A self-replicating malware infected popular npm packages. Launched by a
postinstall script, it collected credentials (npm and GitHub tokens,
cloud keys). With a maintainer token, it self-propagated by republishing
the other packages of the account.
Impact: more than 500 packages were affected in the first wave of
September 2025 according to CISA, then a second wave in November 2025
(Shai-Hulud 2.0, executed as early as preinstall). Counts vary depending on
the vendors.
The regulatory context
Faced with the multiplication of attacks, regulators are taking action.
The European Cyber Resilience Act (2026-2027)
The CRA is the major change to anticipate. Its reporting obligations have applied since 11 September 2026, and full application arrives on 11 December 2027. Every digital product sold in the EU will have to:
- Establish an SBOM (inventory of components) in its technical documentation, kept available for the market surveillance authorities
- Be designed "secure by design" with documentation of the security choices
- Provide security updates during the support period (five years at minimum, unless the expected period of use is shorter)
- Notify actively exploited vulnerabilities: early warning within 24 hours, then notification within 72 hours
CRA penalties: up to €15 million or 2.5% of total worldwide annual turnover (whichever is higher), for breaches of the essential cybersecurity requirements and of the obligations of Articles 13 and 14 of the regulation (Article 64). Other breaches fall under lower ceilings (€10 million or 2%, then €5 million or 1%).
NIS2: already in force
The NIS2 directive has been in force since January 2023, and Member States had to transpose it before 17 October 2024: the actual calendar depends on national law. Entities in critical sectors (energy, health, transport, finance...) must manage the risks of their supply chain and notify significant incidents: early warning within 24 h, then notification within 72 h. Executives bear responsibility for approving the measures. NIS2 penalties are separate from the CRA's: at least €10 million or 2% of worldwide turnover for an essential entity, €7 million or 1.4% for an important entity (Article 34; these are minimum ceilings that each Member State sets in its own law).
In the United States
Executive Order 14028 requires suppliers of the federal government to produce SBOMs and to attest their compliance with the NIST SSDF (Secure Software Development Framework). No compliance, no public contract.
Voluntary frameworks
Several frameworks guide good practice: SLSA (levels for the provenance of the build and of the source, through its Build and Source Tracks), NIST SSDF (secure development practices) and OpenSSF Scorecard (a 0-10 score to evaluate open source projects before adoption). The SOCLE approach (in French) assembles these frameworks into a single profile, ranked by R1-R3 levels.
Recurring mistakes
| Mistake | Consequence | Incident |
|---|---|---|
Mutable tags (@v1) | Silent compromise | tj-actions 2025 |
| Ignored transitive dependencies | Hidden vulnerability | Log4Shell |
Unaudited postinstall scripts | Arbitrary code executed | Shai-Hulud |
| Third-party CDN for scripts | Code injection | Polyfill.io |
| A single maintainer | Takeover | XZ Utils |
| Secrets in CI variables | Exfiltration through logs | tj-actions |
Operationalizing: the 3 execution pillars
Beyond understanding the threats, three areas structure your supply chain operational posture. These pillars turn concepts (SLSA, SBOM, Sigstore) into blocking controls and executable processes.
The first pillar is enforcement: making signatures and attestations mandatory in CI/CD and at Kubernetes admission (the moment the cluster accepts or rejects a workload). It relies on Kyverno for admission and on the artifact firewall for the entry of dependencies. The second is the hardening of the artifact registry: immutability, RBAC (role-based access control), OCI attachments (extra metadata stored next to an image in the registry) and retention. It does not yet have a dedicated guide, only the basics in Container registries and Harbor (in French). The third, incident response, has its own: Responding to a supply chain incident covers scope, containment and the CRA and NIS2 notification obligations.
The SOCLE approach: a framework for the whole scope
Everything above (threats, layers, levels, evidence) comes together in the SOCLE approach (in French), the open standard covering all the domains under a single threat, requirement, evidence axis, ranked by R1-R3 levels. Rather than piling up tools, it starts from enforceable, anchored requirements, and each tool or standard (SLSA, Cosign, SBOM, OSV-Scanner) answers one of them.
- The requirements framework (in French) lists the requirements by domain and by family, with their level.
- The threat model by families maps the attacks, from the producer to the cloud.
What does each lesson of the module cover?
This module follows the journey of a piece of software, from the threat to the incident response, and each lesson takes charge of one link. The overview you are reading is the first: it gives the vocabulary and the big attacks, and the other lessons cover them one by one.
The threat panorama (threats by family) classifies the attacks from the producer to the cloud, and the lesson on the malicious producer details the case where the source itself is hostile. Where to start then offers a diagnosis in six questions and a prioritized checklist, and the supply chain security lesson covers, from the DevOps side, the real attacks and the basic measures (SBOM, SLSA, Sigstore, dependency installation): it relies on the same attacks as this page, but without its framing by layers and SOCLE levels, and this page is the one that tells you which lesson of the module covers which link. The transitive trust lesson shows how trust propagates from dependency to dependency.
The inventory part starts with the SBOM, the list of the components you ship. The xBOM extends the idea to other inventories, the OBOM observes what really runs in production, and the VEX says whether a listed vulnerability is exploitable.
The evidence part relies on signing: the Sigstore ecosystem presents keyless signing, Fulcio issues the short-lived certificates, Rekor keeps the public log that makes these signatures verifiable after the certificate expires, and Cosign signs and verifies images by orchestrating all of it. in-toto adds build attestations, which environment variable poisoning puts to the test: a signed pipeline can still be hijacked from the inside. The lesson on SLSA provenance then helps you choose a realistic level.
The end of the module widens the defense. The attacks on package managers show how a booby-trapped dependency runs in CI/CD, the artifact firewall filters incoming packages, the technical TPRM assesses suppliers, and the incident response lesson walks through the steps the day a compromise is confirmed. The guided "verifiable build" lab closes the module with guided practice.
Key points
- A supply chain attack targets what you consume, not your code: a compromised upstream component hits all its users.
- The scope goes beyond artifacts: workstation, source, build, release, runtime, secrets and suppliers matter as much as the signature.
- You build maturity by levels: R1 everywhere, R2 in production, R3 on the sensitive parts.
- Attackers play the long game and exploit implicit trust (XZ Utils, Polyfill.io, tj-actions, Shai-Hulud).
- Pin by SHA or digest: a mutable tag lets a silent compromise through.
- Regulation applies (NIS2 in force, CRA: reporting since 11 September 2026, full application on 11 December 2027) and demands SBOMs, supplier assessment and incident notification.
- Each lesson of the module equips one link: inventory, evidence, attacks and defenses, incident response.
Knowledge check
Check that the essentials of this lesson are in place. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Software supply chain threats: the model by families
A new full quiz with random questions
Work again only on the questions you missed