When a project pre-announces a security release, use the days before it lands to list where you run the software, pick who upgrades, and book test time. You usually will not know the details yet, so prepare the process, not the patch.
What a pre-announcement is
Some projects warn users before a fix is public. The Go security policy says that for issues on its PRIVATE track, a pre-announcement goes to golang-announce three to seven days before the release. It states that one or more security fixes are coming, whether they affect the standard library, the toolchain or both, and it lists reserved CVE IDs. The same policy says its most urgent track may trigger an immediate release with possibly no pre-announcement.
Django describes a similar step. About a week before disclosure it notifies django-announce of the date, approximate time and severity of the upcoming security release, so organisations can make sure staff are available. A second, private notice goes to operating system vendors and other distributors.
The pattern is the same: you get a date and a size of problem, not the vulnerability details.
A five day plan
| Day | Action |
|---|---|
| Day 1 | Search your inventory for every service that uses the project and note the version in each |
| Day 2 | Check which versions the project supports, since only those get fixes |
| Day 3 | Pick an owner per service and agree the upgrade order |
| Day 4 | Prepare build and test pipelines so a version bump is a one line change |
| Release day | Read the advisory, confirm affected components, upgrade, record the result |
Treat the table as a template, not a promise. A shorter window means compressing the days.
Questions to answer before release day
- Which of our services are internet facing, and which are internal only?
- Where is the language runtime or framework baked into a container image, so a rebuild is needed?
- Who has authority to approve an out of hours deploy?
- Do we have a tested rollback?
The runtime question is the one teams forget. If the fix is in a language toolchain or standard library, rebuilding an application may be required even though no dependency file changed. Check what the release announcement says about scope when it arrives.
What not to do
Do not guess at the vulnerability from the severity word or the package area and start workarounds. Do not post speculation in public channels. Do not skip the inventory step because you assume you know your estate; the surprises are always the old service nobody owns.
Also resist rushing a half tested upgrade the moment the release appears. Attackers study fresh patches, so speed matters, but a broken rollout is also an incident. The notice window exists to let you do both.
After the release
Read the advisory, check the affected version range against what you found, upgrade, and write down the date and ticket. Our post on recording evidence when you act on an advisory shows a short template.
Where Safeguard fits
Safeguard's SBOM and dependency scanning gives you the version inventory that Day 1 depends on, and reachability analysis helps show whether the affected code path is called. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click an incoming advisory and see which inventory items it touches.
Quick check
Will the pre-announcement tell me what the bug is?
Not necessarily. Go's policy describes it as announcing the presence of fixes, the area affected and reserved CVE IDs. Details come with the release.
Do all projects pre-announce?
No. Go says its urgent track may have no pre-announcement, and its public track has none. Do not rely on a warning.
Sources
Last reviewed: 19 October 2026.
