Transitive trust is automatically inheriting the risk of everything that something you trust depends on. If you trust a supplier, and that supplier relies on other building blocks, you implicitly trust those blocks too, without knowing them. This lesson explains the mechanism, shows where it hides in a project, why it is at the heart of software supply chain attacks, and how to keep it under control.
What you will learn
The word "transitive" comes from mathematics: if A is linked to B, and B to C, then A is linked to C. Applied to trust, it creates an invisible propagation few teams measure, which the software supply chain security lesson set as the module's starting point.
- Define transitive trust and the delegation chain it creates.
- Spot where it hides: software dependencies, cloud providers, certificate authorities, base images.
- Understand why it makes supply chain attacks possible, illustrated by real incidents.
- Apply three reflexes to control it: reduce, verify, monitor.
What is transitive trust?
Transitive trust is the trust you grant without meaning to, by ricochet. You trust someone, who trusts others, and step by step you depend on actors you never chose. The rule fits in one sentence: if A trusts B, and B trusts C, then A depends on C without knowing it.
You only assessed the first link, but your exposure is that of the whole chain. A direct dependency you audited pulls in twenty others never examined; a certified SaaS provider subcontracts its storage to a third party whose name you do not know. Your real risk is set by the weakest link behind what you checked.
In IT, this chain is rarely visible and often very long. Modern software assembles pieces from everywhere, and each piece assembles others. The trust placed in the final product propagates to dozens, sometimes hundreds, of unknown authors.
Where does transitive trust hide?
Transitive trust is everywhere as soon as you build a system from existing blocks. Four places concentrate it, each with its own attack vector; each term is defined at its first appearance.
Software dependencies are the most common case. A dependency is code written by others that your application reuses, for example a library to handle dates. The trap comes from transitive dependencies, the dependencies of your dependencies: you choose ten, and end up with hundreds of blocks whose very names you do not know.
Cloud providers form a second layer. By trusting a provider, you inherit its own chain: its subcontractors (data centre maintenance, network, monitoring). A flaw at one of them can hit you, even if your direct provider is beyond reproach.
Certificate authorities are more discreet but essential. A certificate authority guarantees, through a certificate, that a site is indeed the one it claims to be. Your browser trusts a list of authorities: if one of them signs a fake certificate, fraudulent sites can pass as legitimate.
Base images concern containers. A base image is the starting point you build on, for example a minimal Linux system. By starting from it, you trust whoever prepared it, the maintainers of each program it contains and the registry that distributes it.
Why is it a major risk?
Transitive trust becomes dangerous because an attacker does not need to break down your door: it is enough to compromise an upstream link, and the poison flows down to you. This is the principle of software supply chain attacks.
The best image is the Trojan horse: rather than attacking the city head-on, the attacker hides soldiers in a gift that the inhabitants bring in themselves. Here, the gift is an update of a popular library that thousands of projects install without suspicion. The malicious code uses the trust already granted to run at the heart of systems that would never have let a stranger in.
This booby-trapped code is malware. The page on malware (in French) details what it tries to do once executed: steal secrets, open a backdoor, mine cryptocurrency. The danger does not come from a badly chosen block, but from a trusted block that has been hijacked.
What do real incidents show?
Three public incidents each illustrate a way to hijack transitive trust. They are documented and serve as textbook cases in the profession; none required a mistake from the victim, only trust in a popular block.
| Incident | What happened | What it shows |
|---|---|---|
| event-stream (npm, 2018) | The maintainer hands the project over to a stranger, who adds a malicious dependency, flatmap-stream, targeting a cryptocurrency wallet | A change of maintainer is enough to poison a transitive dependency |
| ua-parser-js (npm, 2021) | The maintainer's account is hacked and booby-trapped versions are published, with a cryptocurrency miner and a password stealer | A compromised account publishes in the name of a trusted author |
| xz-utils (2024, CVE-2024-3094) | A contributor earns the project's trust for more than two years, then inserts a backdoor targeting the SSH daemon of some Linux distributions | The attack can target human trust, over years |
How do you control transitive trust?
You cannot remove transitive trust: reusing code and services is what makes modern IT possible. You control it by keeping the chain short, verified and monitored. Three reflexes cover the essentials.
The first reflex is to reduce dependencies. Fewer links mean fewer ways in. Before adding a library, ask yourself whether you really need it, and prefer those that pull few transitive dependencies: this is the principle of minimisation (in French), which also reduces the attack surface.
The second reflex is to verify each link. A digital signature proves that a block really comes from its author and has not been modified, like an intact wax seal; the lesson Sign and verify with Cosign puts it into practice. The SBOM (Software Bill of Materials, the list of ingredients) lists all blocks, direct and transitive: see the SBOM lesson.
The third reflex is to monitor over time. A block that is safe today can be compromised tomorrow: a maintainer changes, an account is hacked. Pinning versions in a lock file, filtering what comes in (lesson Controlling dependency intake) and alerting on new dependencies let you react quickly. Trust is never acquired: it is reassessed.
A concrete scenario
A small team develops a web application with fifteen direct libraries, which seems reasonable. Those fifteen blocks pull in hundreds more: over three hundred transitive dependencies, written by dozens of authors the team does not know.
An attacker spots a block buried deep in this chain. They hack the account of the person maintaining it and publish a new version containing, on top of the usual functions, a few malicious lines, exactly the ua-parser-js pattern. The block keeps working normally.
The application is configured to automatically fetch the latest versions. At the next update, the booby-trapped code flows down to it without anyone deciding so, runs during the build, steals the project's secrets and sends them to the attacker. Versions pinned in a lock file, an SBOM compared from one build to the next and an alert on any new dependency would have revealed the novelty before the damage.
Which traps should you avoid?
Some very common habits reinforce transitive trust without anyone noticing. Each rests on a reassuring intuition that is wrong, and each has its remedy.
The first trap is trust by popularity: believing that a massively used block is necessarily clean. The three incidents above involved very widespread blocks; popularity attracts attackers, it does not reassure.
The second trap is trust by certification: thinking that a security label covers a supplier's whole chain. A certification is valid for a defined scope, at a given moment, and guarantees neither the subcontractors nor the absence of a flaw that appeared since.
The third trap is frozen trust: granting it once and never questioning it again. Maintainers hand over projects, as with event-stream, and accounts get hacked: trust never reassessed ends up unjustified.
The last trap is forgetting transitive dependencies: monitoring only the blocks you chose yourself. It is in these invisible depths, far from view, that attacks most readily hide.
Key points
- Trust propagates by itself: trusting a block means trusting the whole chain hidden behind it.
- The weakest link sets your risk, not the actor you know and chose.
- Transitive dependencies are the blind spot: an ordinary application inherits hundreds of blocks it does not know exist.
- Supply chain attacks exploit this trust, through a change of maintainer (event-stream), a hacked account (ua-parser-js) or patient infiltration (xz-utils).
- Verify rather than believe: signatures and SBOMs say where each block comes from and what it contains.
- Trust is never final: reduce links, pin versions, monitor changes.
- This concept feeds a whole threat model: the SOCLE threat model (in French) links these vectors to the controls that protect your organisation.
Knowledge check
Check that you have the essentials of this guide. 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: SBOM: the inventory of what you ship, measured with Syft
A new full quiz with random questions
Work again only on the questions you missed