A useful security advisory tells a reader whether they are affected, how bad it is, how to fix it and what to do if they cannot fix it yet. Include affected and fixed versions, a plain description, severity with your reasoning, workarounds, credit and dates. Keep it factual and avoid exploit steps.
Fields to include
| Field | What to write |
|---|---|
| Title | What and where, in plain words |
| Identifier | Your advisory ID, plus a CVE ID if assigned |
| Published and updated dates | True dates, with a change log |
| Affected products and versions | Exact ranges, including how to check the installed version |
| Fixed versions | Exact versions, with links |
| Severity | A score and the vector, plus a sentence on real world impact |
| Description | What the weakness allows, without a recipe |
| Workarounds | Settings or controls that reduce risk before patching |
| Detection | Log lines or checks that indicate attempts, if you have them |
| Exploitation status | Whether you know of exploitation, stated carefully |
| Credit | Who reported it, if they agreed |
| Contact | How to ask questions |
Write for the person patching
Lead with an action line: "Upgrade to 2.4.1 or later." Readers skim. Put the affected range before the story.
Severity honesty
A base score measures technical severity, not your customers' risk. Add a sentence about conditions, such as whether the issue needs authentication or a non default feature. Do not downplay with wording and do not inflate for attention.
Machine readable too
Many teams also publish the same facts in a machine readable format, so scanners and customers can ingest them. Keep the human and machine versions in sync, and treat the machine version as part of your release checklist.
Timing
Publish when a fix is available, unless active exploitation forces earlier warning with mitigations. Coordinate dates with the reporter. Your disclosure policy should already say how this works.
Update, do not rewrite
If scope changes, add a dated entry and keep the earlier text. Silent rewrites erode trust.
Where Safeguard fits
On the customer side, Safeguard SBOM and dependency scanning plus reachability analysis help readers decide whether an advisory about a library affects them. For your own releases, the same SBOM data helps you state affected versions accurately.
Quick check
Do we need a CVE for every advisory?
No, but one helps customers and tools match the issue. Decide using your policy.
Should the advisory name the reporter?
Only with their consent.
Last reviewed: 19 October 2026.
