# Supplier risk > Supplier risk is the practice of treating every dependency — a vendor, a component, a counterparty — as inherited risk that must be identified, versioned, monitored, and provable, rather than trusted because it is already in use. Category: Applied domains Also searched as: third-party risk, vendor risk, supply-chain risk management Source: Mediator Solutions — https://mediatorsolutions.io/learn/#supplier-risk License: free to read, learn, cite, and apply, with attribution to Mediator Solutions. ## What it is What a supplier brings in becomes yours: their defects, their outages, their compromises. Supplier risk applies verification over trust to the supply chain — you keep a live inventory of what you depend on, know the provenance of each piece, and can prove the state of a supplier relationship rather than assuming it. A dependency you cannot account for is a risk you have already accepted without deciding to. ## Why it matters Every dependency imports someone else’s defects, outages and compromises into your blast radius, and the ones that hurt are the ones no one was tracking. The discipline is to treat the supply chain the way you treat your own code: inventory it, know its provenance, monitor it, and be able to prove the state of a relationship rather than assuming it holds. The quiet failure is the dependency you accepted without deciding to — the library pulled in transitively, the vendor whose terms changed, the abandoned component still running in a live system — each an accepted risk that was never an explicit decision. ## When to use it - Taking on any dependency — a library, a vendor, a service, a model provider. - A dependency entered the system transitively, without anyone deciding to accept it. - A vendor’s terms, ownership, or security posture changed and no one tracked it. ## Principles - Dependencies are inherited risk: identified, versioned, monitored, updated, replaced if abandoned, removed if unnecessary. - The system must know what it runs — source, version, provenance, and current state for every component. - A supplier claim is verified, not trusted: resolve it to a receipt, an audit, or an observed outcome. - An unaccountable dependency is an accepted risk; make the acceptance an explicit decision. ## Practice 1. Inventory every supplier and component you depend on, with version and provenance. 2. For each, record where it came from, who owns it, and what would signal it is failing. 3. Monitor the inventory for drift — new dependencies, abandoned ones, changed terms. 4. Resolve each consequential supplier claim to evidence before you rely on it. ## Where it fails - **Unaccepted dependency** — A risk is imported without a decision — a transitive library, an abandoned component, a vendor whose terms shifted — so no one owns it. - **Trust-by-assumption** — A relationship is assumed to hold rather than proven to hold, so its failure is discovered only when it fails. - **Invisible blast radius** — The supply chain is not inventoried, so when a dependency is compromised, no one can say what it reaches. ## In practice A payments feature pulls in a small library that itself pulls in forty more. Months later one of the forty is compromised. The undisciplined team cannot even enumerate what is affected. The disciplined team inventoried the chain, recorded the provenance and the decision to accept each dependency, and monitors them — so the compromise is a scoped, answerable event: here is what it reaches, here is who accepted it, here is the containment. The dependency was a decision, not an accident. ## Verification An independent reviewer can list every dependency, its provenance, and its current state from the record, and each consequential supplier claim resolves to evidence rather than assurance. --- Previous: https://mediatorsolutions.io/learn/#secure-by-design Next: https://mediatorsolutions.io/learn/#deal-governance-in-practice