Embargoed details leak from a distributor on day four. Do you publish immediately?
answer
- what was the embargo buying you?
- secrecy is gone; the reason is gone
- grade the leak before reacting
- move the date, tell everyone at once
- your distribution log is the evidence
basics
~20 sUsually yes. An embargo is only worth keeping while the details are secret; once they circulate, holding protects the attackers' head start and nobody else. Confirm what leaked, tell every embargoed party the date has moved, then publish.
solid answer
~40 sFirst establish what leaked, because the answer changes: a hint that a fix is coming is not the same as the affected function and a proof of concept, and a closed forum is not the same as a public archive. If exploitable detail is genuinely reachable, publish, because the only thing an embargo buys is the gap between attacker knowledge and defender knowledge, and that gap has closed. Do it deliberately rather than in a panic: agree the move with the reporter and the coordinator, notify every embargoed party at the same moment, and go out with whatever protects users now, which may be a mitigation rather than the complete fix. Afterwards use your distribution record to find where it escaped, privately and on evidence.
go deeper
Understand that an embargo only works while the details are secret, so a genuine leak of the technical detail normally means publishing sooner rather than sticking to the original date.
Explain how you would grade the leak: what content escaped, how reachable it is, and whether there are signs anyone is acting on it, then why exploitable detail in a public place collapses the reason to wait.
Show the execution: agree the move with the reporter and coordinator, notify all embargoed parties at one moment, publish a mitigation and partial advisory if the full fix is not ready, and use the distribution record to trace the source.
Own the pre-agreed rule. Decide in advance what triggers early publication, who is authorised to make the call at short notice, and how you handle a leaking partner without turning an operational failure into a public dispute that costs you future coordination.
## Why the answer is usually 'publish' An embargo has exactly one source of value: attackers do not know what defenders do not know. Every other benefit, coordinated releases, a tidy announcement, distributors rebuilding in step, is downstream of that secrecy. When the secret is out, continuing to hold does not restore it. It only keeps the *defenders* uninformed, since the people best placed to act, the operators who could apply a mitigation today, are the ones still in the dark. That asymmetry is why the default on a confirmed leak is to bring the date forward. ## But first, establish what actually leaked A panicked publication on a rumour is its own damage. Ask three questions: 1. **What is in the leak?** "A security release is coming Thursday" is noise. The affected component and versions is a lead. The vulnerable code path, a patch diff, or a proof of concept is the real thing. Only the last category truly collapses the gap. 2. **How reachable is it?** A message in a mailing list with a public archive, a commit pushed to a public fork, or anything on a searchable forum is public in practice even if nobody has noticed yet. A message to a closed internal list of ten people that has been contained may still be recoverable. 3. **Is there evidence of exploitation or of others acting on it?** Scanning for the affected component or chatter naming it removes any remaining argument for waiting. A leak of the *existence* of an embargo often needs no more than an acknowledgement. A leak of the mechanism needs the date moved. ## Moving the date without making it worse Bring the publication forward, but keep it a decision rather than a scramble. - **Talk to the reporter.** They agreed a date with you and are entitled to know it is moving; they may also have visibility into how far it has spread. In practice they will support publishing early, because the flaw being public without an advisory is the outcome their policy exists to prevent. - **Talk to the coordinator, if there is one.** A multi-party coordination has one authoritative timeline, and moving it is their call to make and communicate. Doing it around them produces exactly the contradictory dates coordination exists to prevent. - **Notify every embargoed party simultaneously.** Distributors who learn from the public advisory that the date moved are the ones who never trust you again. One message, one new hour, everyone at once. - **Publish what helps now.** If the full fix is not ready across all supported lines, go out with the mitigation, the affected versions and the configuration workaround, and say plainly that further releases follow. An advisory naming a workaround beats silence. ## When you might still hold Holding is defensible in narrow cases, and you should be able to name them: the leak carried no exploitable detail and has been contained; or publishing today would leave users with no action at all while the mitigation is hours away, so a short, communicated delay measured in hours materially improves what you can offer. "Our announcement is not ready" and "we have not briefed the executives" are not on that list. The test is whether waiting improves what a defender can *do*, not what your communications look like. ## The part everyone forgets: the record The asset at stake in a leak is not customer data. It is audit truth and trust, and both depend on your having kept a distribution record: who was pre-notified, what they were sent, at what time. That record turns "someone leaked" into a bounded set, and it protects the parties who did nothing wrong just as much as it narrows the ones who might have. Handle the aftermath as a private, evidence-led conversation. A named public accusation you cannot prove is a bigger reputational problem for you than the leak was, and leaks are frequently mundane, such as a shared alias that fed a wide ticket queue, an internal wiki page that was not access-controlled, or a build triggered in a public CI configuration. The remedies are structural: narrower lists, shorter holds, named individual contacts, and removing a party from future pre-notification if the same thing happens twice. ## What this teaches you for next time Every embargo you run should be designed on the assumption that this will eventually happen. That means keeping recipient counts and hold lengths small enough that a leak is survivable, keeping proof-of-concept material out of the distribution entirely, having a pre-agreed rule with the reporter for what triggers an early publication, and having a draft advisory ready by day one so bringing the date forward costs you hours rather than days.
- The leak only revealed that a security release is coming, with no technical detail. Does that change things?Yes. The exploitable gap has not closed, so the reason for the embargo survives and the date can stand. Expect and absorb the speculation, warn the embargoed parties that attention is on the release, and consider tightening the remaining window since interest now makes a second, more damaging leak likelier.
- How do you handle the party you believe leaked it?Privately and on evidence. Use the distribution record to establish what they were sent and when, ask them to investigate their own handling, and expect a mundane cause such as a shared alias or an unprotected internal page. Structural remedies come first: narrower lists, shorter holds, named contacts. Removal from future pre-notification is a repeat-offence decision, not a first-incident reflex.
- What should be ready in advance so an early publication is cheap?A draft advisory from day one, an agreed mitigation or workaround that does not depend on the release, a current contact list for every embargoed party, and a pre-agreed trigger with the reporter for what counts as a leak worth publishing over. With those, moving the date is a few hours of work rather than a scramble that produces a bad advisory.
saying these in an interview costs you the question
- Holds the date to protect the announcement plan
- Publishes on a rumour without grading the leak
- Moves the date without telling the reporter
- Lets embargoed parties learn from the public advisory
- Publicly accuses a party without evidence