When shipping an embargoed security fix, how do you sequence release and advisory?
answer
- remedy first, notice second
- both halves are useless alone
- confirm an outsider can fetch it
- who else listens for the tag
- rehearse on a throwaway version
basics
~20 sPublish the fixed artifact first, confirm consumers can actually fetch it, then make the fix public: advisory, commits, tag and notes together. Audit everything the release automation triggers, because a docs or notes job can announce the fix hours early.
solid answer
~50 sThe order that protects users is: build and publish the fixed artifact, verify from an outside position that it is genuinely downloadable — including through mirrors and caches — and only then publish the advisory, the public commits and the tag, as close together as you can manage. Publishing the advisory first leaves consumers alarmed with no remedy; publishing the code days before the advisory hands attackers the diff. The failure that actually bites teams is automation: a job fired by the tag renders release notes to the public documentation site, carrying the fix commit message and its issue link into the open long before you intended. So enumerate every consumer of the tag and publish events, gate the ones that talk to the public behind a manual step, and rehearse the whole sequence on a throwaway tag first.
go deeper
Remember the basic ordering rule: consumers need something to install before they are told they are vulnerable, so the fixed version goes out first and the notice follows closely.
Explain why each half is useless alone, and why publishing the code days before the notice is as bad as the reverse. Know that indexes, caches and mirrors propagate asynchronously.
Show the operational habits: verifying availability from an outside position, inventorying every subscriber to the tag and publish events, gating the public-facing ones, and rehearsing the whole sequence on a throwaway version.
Be ready to own a disclosure date that a third party effectively controls — an app-store queue, a distribution partner, a certification body — and to explain how you keep the reporter and downstream consumers aligned when the date moves.
## What "landing together" means A security release has two halves: the **remedy** (an installable fixed artifact) and the **notice** (the advisory that tells consumers they need it, and implicitly, that the previous version is vulnerable). Each half is dangerous without the other. - **Notice without remedy** — the advisory is public, the fixed version is not yet installable. You have told the whole world including attackers that a flaw exists, and given defenders nothing to do about it. - **Remedy without notice** — the fixed artifact and its public commits exist, but nothing says why it matters. Attackers diff releases as routine work and will find the fix within hours; consumers see an ordinary patch release and leave it in the backlog. So the aim is a tight sequence, in this order, with the gaps as small as you can make them. ## The order of operations 1. **Build and sign the release** from the private branch, on infrastructure that does not publish logs or artifacts publicly. 2. **Publish the artifact** to the distribution channel consumers actually use. 3. **Verify it is fetchable from the outside.** This step gets skipped and it is the one that most often invalidates the plan. 4. **Publish the disclosure set together**: the advisory, the now-public commits, the tag, and the release notes. 5. **Announce** through your normal channels once the above is live. Step 3 deserves emphasis. A registry API returning success is not proof that a consumer can install the version. Indexes update asynchronously, caches and mirrors lag, content-delivery layers serve stale metadata, and geographically distant mirrors can be minutes to hours behind. If you flip the advisory while a large slice of your users still resolve to a mirror that has not caught up, you have created exactly the notice-without-remedy state you were trying to avoid. Check as an unauthenticated outsider, from more than one path, before proceeding. ## The automation that betrays you The subtle failure is not the order you intended; it is everything else your release event triggers. A representative incident: a project pushes the release tag, and a job that nobody had thought about in this context renders the changelog into the public documentation site immediately. The rendered notes include the fix commit's message and a link to the tracking issue — and the advisory was not due for another day and a half. The embargo ended when a docs pipeline ran. The control is a written inventory of every subscriber to the tag and publish events, with an explicit decision for each: | Trigger | Typical leak | Handling | |---|---|---| | Docs/site rebuild | Renders changelog and commit messages | Gate behind manual approval | | Release-notes generation | Publishes messages and issue links | Generate privately, publish at disclosure | | Issue auto-closing | "Closed by <commit>" on a public tracker | Keep tracking private | | Chat, mail, social bots | Announces the version before the advisory | Disable for this release | | Repository mirror sync | Pushes the fix commits early | Confirm timing or suspend | | Package index/CDN | Version visible before advisory — intended | Keep the gap to minutes | Rehearse it. A dry run on a throwaway pre-release version, watched end to end, reveals the subscribers nobody remembered — and it is a great deal cheaper to discover them on a dummy tag than on the real one. ## When a third party owns your date Sometimes the remedy cannot be made available on a schedule you control. A vendor shipping a mobile SDK, for example, may need customers' applications to clear an app-store review queue before an updated build is in users' hands; the effective disclosure date is then set by a reviewer nobody in the conversation employs. The same shape appears with distribution partners, appliance vendors, and any consumer whose deployment requires certification or a change-control board. What you can do about it: learn the third party's realistic turnaround before committing to a date rather than after; get the fixed build into that queue early so the wait runs in parallel with the rest of the preparation; separate *availability* from *announcement* so an artifact can sit approved but unannounced; and keep whoever reported the flaw informed, because a date that slips without explanation is how coordinated disclosure breaks down. What you cannot do is assume the queue will be fast because the fix is urgent — the reviewer does not know that, and telling them why would itself be a disclosure. ## Afterwards Once the fix is public, the material you kept back becomes useful: the honest commit message, the detailed test, the explanation of what went wrong. Publishing those *after* release costs nothing and helps downstream consumers judge whether they were affected — the opposite of the silent fix, which leaves everyone guessing.
- Your package index reports the release as published, but a widely used mirror is twenty minutes behind. Does that block the advisory?Yes, in practice. Consumers resolving through that mirror would read the advisory with no installable fix, which is the state you are trying to prevent. Verify availability from an outsider's position across the paths your users actually use, and hold the advisory until the remedy has propagated — twenty minutes of waiting is cheap compared with a window of public notice and no fix.
- A vendor's fix cannot reach users until customer apps clear an app-store review queue. How do you handle a date you do not control?Find out the realistic turnaround before you commit to a date, submit early so the queue runs in parallel with the rest of the preparation, and decouple availability from announcement so an approved build can wait unannounced. Keep the reporter informed as the picture changes. Never assume the queue moves faster because your fix is urgent — the reviewer has no idea, and explaining would itself disclose.
- Should the fix commits become public before or after the advisory?Together, or with the commits marginally after. Once the artifact is installable the diff is derivable anyway, so there is little to gain from holding the commits — but there is nothing to gain from pushing them early either. Treat commits, tag, notes and advisory as one publish step so no one of them can announce the flaw on its own.
saying these in an interview costs you the question
- Publishes the advisory before the artifact is installable
- Treats a registry success response as proof of availability
- Assumes the docs pipeline is unrelated to the release
- Never inventories what the release tag triggers
- Runs the real release as the first rehearsal