A defunct vendor's component is vulnerable on 200,000 customer machines with no update channel. What do you do?

## Why this is a leadership question and not a patching question Everything in this scenario that makes it hard is outside the code. The flaw is in a component nobody will ever fix. You cannot reach the affected systems, because they belong to your customers and you never built a way to push anything to them. And the party who wrote the vulnerable code no longer exists, so there is no one to escalate to. What is left is a decision about money, obligation and customer trust, which is why it lands on a lead. ## Step one: separate two populations They have completely different economics and should never be discussed as one problem. **Future installs.** Anything you ship from now on can be clean. Remove the component, replace it with a maintained equivalent, or reimplement the narrow slice you use. This is bounded engineering work, and it should start immediately regardless of what you decide about the installed base, because every day it is not done adds to the population you cannot reach. **The existing installed base.** This is the actual risk and no release fixes it. Adoption of a voluntary update has a long tail measured in years, and a meaningful fraction of those machines will never run anything new at all. ## Step two: establish what the exposure actually is The correct response depends entirely on how the component runs on a customer machine, and this is the analysis weak answers skip: - Does it run as a privileged service that starts automatically, or only when a user performs an action? - Does it listen on a network socket, a local socket, or nothing? - Does it process untrusted input, and from where: files the user opens, data from your servers, traffic from the local network? - What does a successful exploit gain: user-level code execution, full control of the endpoint, or credentials to your service? An always-on privileged service reachable from the local network is close to an emergency. A library exercised only when the user opens a file they were tricked into obtaining is a real but much slower problem, and the difference is worth six figures in what you decide to spend. ## Step three: price the three honest options **Publish a customer advisory with self-service steps.** Cheapest and fastest. Tell customers what is affected, what the risk is, and exactly what to do: uninstall a feature, disable a service, remove a file, apply an operating-system-level restriction. Its weakness is adoption, which is low and unmeasurable, and its strength is that it is the only option that reaches machines today. **Build an update channel.** Expensive and slow, and it fixes this problem and every future one. Delivering software updates safely is itself a supply-chain problem: the channel needs authenticated, integrity-checked updates, or you have built the attacker a distribution system for 200,000 endpoints. If the product has a long life ahead, this is usually the right investment, and this incident is the business case that finally justifies it. **Declare end of support and accept the residual risk.** Legitimate only if it is explicit: a written end-of-support statement for the affected version, communicated to customers, with a named owner and a documented residual risk. "We quietly did nothing" is not this option; it is the absence of a decision. These are not exclusive. A common real answer is: advisory now, clean release in weeks, update channel funded for the next major version, end-of-support date announced for the old one. ## Step four: know where the obligation sits Candidates often assume that an unsupported third-party component makes the risk somebody else's. It does not. Your customer bought your product; the component's provenance is an implementation detail of your build. Regulation has been moving firmly in this direction: the EU Cyber Resilience Act places obligations on the manufacturer who places a product with digital elements on the market, including handling vulnerabilities across a defined support period, and "our supplier dissolved" does not transfer that. The same asymmetry is worth noticing internally: your organisation almost certainly demands security fixes from its own vendors, and you are now the vendor. ## Step five: fix the class, not just the instance The real defect was accepting a closed-source component from a single small vendor into a shipped product with no exit plan and no way to update it. The durable outputs of this incident are the ability to update what you ship, treated as a product requirement rather than a nice-to-have; a rule that shipped third-party components need either source availability or a plausible replacement path; and an inventory of what is in your shipped product that is good enough to answer "where else is this vendor" in minutes rather than weeks. ## What a strong answer sounds like It separates new installs from the installed base, refuses to answer before establishing how the component actually runs, prices more than one option, names who has to be in the room (support, legal, product, finance, not just engineering), and ends with a written sunset date and an owner. A weak answer says "we will fix it in the next release", which protects only the machines that install it.