Prepare the fix privately, build and test the release before announcing anything, then publish the release and the advisory together so users can act the moment they learn of the problem. Keep a short checklist and one owner for each step.
Why coordination matters
If the advisory goes out before the release exists, attackers get a head start on users who cannot yet update. If the release goes out first with a clear fix in a public commit, the same happens in reverse. The goal is a short window in which the fix and the explanation become public together.
GitHub documents one way to do this for repository security advisories. You can create a temporary private fork, collaborate there on the patch, and then merge the pull request from the advisory. GitHub's documentation notes that integrations, including CI, cannot access temporary private forks, and that merging from the advisory does not enforce your branch protection rules, so do your own testing and review before you merge.
A plan for the day
| Step | Owner | Done when |
|---|---|---|
| Fix reviewed and tested privately | Maintainer plus reviewer | Two approvals recorded |
| Release candidate built from the fix | Release owner | Artifacts built and scanned |
| Advisory text drafted | Security lead | Affected, fixed and workaround stated |
| Reporter and key downstream parties told | Security lead | Confirmation received |
| Publish release and advisory together | Release owner | Both live, links tested |
| Verify package registries and docs | Release owner | New version resolves for users |
| Monitor for exploitation and questions | Security lead | Named person on call |
Steps in more detail
- Agree the date with the reporter. Give yourself a buffer.
- Because CI may not run in a private fork, run your tests locally or in a private environment before the merge, and run the full pipeline again right after.
- Pre-write the advisory with the affected versions, fixed versions, a workaround if any, and credit if the reporter wants it.
- Prepare the package publishing steps in advance, including the signing keys and tokens, so nothing is missing at release time.
- Publish in a fixed order: release artifacts, then registry, then advisory, then announcement. Check each before the next.
- After publishing, install the release from the registry on a clean machine.
After the announcement
Watch for questions and reports of exploitation. Keep a place where you note what you were asked, since the answers belong in your follow-up and in the retrospective.
What to avoid
- Pushing the fix to a public branch before the release is ready.
- Writing an advisory that does not name the fixed version.
- Forgetting older supported lines, which then stay exposed.
- Leaving the release owner alone with no second person to check the steps.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a newly disclosed issue reaches the components you use, which is what your downstream users will do the moment your advisory lands.
Safeguard performs zero-day discovery and monitors disclosures against your inventory, so you can see which of your own dependencies are affected when others publish. Try a free scan at gold.safeguard.sh/scan.
Quick check
Should the release or the advisory go first?
Publish them together, with the release artifacts available before the advisory is visible, so users can act immediately.
Does a private fork run my CI?
GitHub's documentation says CI and other integrations cannot access temporary private forks, so test separately before merging.
Sources
Last reviewed: 19 October 2026.
