Eleven downstream distributors want pre-notification of an embargoed flaw. How do you decide who gets it?

## The scenario An authentication bypass is found in an ingress controller that many organisations vendor into their own platforms. Eleven parties have asked to be told before the public date. Some rebuild your code into products they ship; some run it at scale for their own customers; some just want to be in the room. Deciding who is in and who is out is the whole job, and getting it wrong in either direction hurts. ## The criterion: who has work to do before publication? Pre-notification exists for one reason, which is to remove the gap in which a fix exists upstream but not in the form a user actually installs. That gives a sharp test. **Include a party when it must produce something.** A distributor repackages, vendors or embeds the affected code and ships it onward. Without the patch in advance, its rebuild starts on publication day, and its users sit exposed while an already-public flaw is trivially findable. Hardware and appliance vendors are the extreme case, since their build and validation cycles are the longest. **Exclude a party that only consumes.** An operator running the component in production, however large, upgrades once the fixed release exists. Telling them a week early does not shorten their remediation by a minute; it just adds a week of exposure to a secret. "But they are a major customer" is an argument about relationships, not about protecting users, and it is exactly the pressure this rule exists to resist. The grey cases are real. A cloud provider that runs a managed service on top of your component *is* effectively a distributor to its own tenants, because its customers cannot patch it themselves. A firm that merely deploys it internally is not, no matter how many seats it has. ## Leak risk is roughly recipients times days Every person on the list is a place the secret can escape, and every day is another chance. That product is the number to manage, and it argues for two disciplines: - **Keep the pre-notification hold short.** Distributor lists commonly cap it at around two weeks and require public disclosure at the end, precisely because longer holds across many parties do not survive. - **Keep the content minimal.** Distributors need the affected component and versions, the patch, and enough to test it. They do not need a proof of concept, an exploitation write-up or attack telemetry. Send what enables a rebuild, not what enables an attack. ## Run it through a coordinator or an established list For anything beyond two or three parties, do not build the list yourself: - **A coordinator** such as a national CERT takes on the work of identifying affected vendors, chasing the unresponsive ones, keeping one authoritative timeline and being the neutral party when interests conflict. FIRST publishes guidance specifically on multi-party coordination, and the reason it exists is that ad hoc lists produce contradictory dates. - **An established distributor list** brings membership rules, an encryption norm and a published maximum embargo you did not have to negotiate. Using one converts "who do we trust?" into "who already qualified?", which is far easier to defend when someone is left off. ## Mechanics that matter - **Named humans, encrypted, no shared aliases.** A security alias that feeds a ticket queue read by forty support staff is not a confidential channel. Ask each party for a named contact and a key, and re-confirm annually, because these lists rot. - **Say what the recipient may do with it.** State plainly that they may build and test internally, and may not publish, brief customers, or ship the fixed build before the agreed hour. - **One clock for everybody.** Every recipient gets the same date and hour, expressed in a single timezone. Split timings are how one vendor's release accidentally becomes the disclosure. - **Log the distribution.** Who was told, what they received, when. This is the audit record that lets you narrow down a leak, and it protects the innocent recipients as much as it identifies a careless one. If you are ever asked to justify the list, this is the evidence. - **Tell the reporter who is on the list.** They agreed to an embargo with you, not with eleven strangers. Surprising them with a wide distribution is a good way to lose the window. ## The failure modes Too wide is the common one: everyone who asks gets added, the list becomes a courtesy to important customers, and by day four the details are circulating. Too narrow is quieter but real: a distributor is missed, its users are exposed for weeks after publication, and that distributor stops trusting you with anything. Both are avoided by writing the inclusion rule down before the report arrives, and applying it to relationships you would rather not annoy.