A good advisory has six must-haves: a short summary with impact, the vulnerable versions, the patched versions, any conditions that limit exposure, workarounds, and a CVE ID if one exists. Add a timeline and researcher credit where you can. Publish it only after the fix is released and retested.
The minimum, from OWASP
OWASP's vulnerability disclosure guidance says that once a vulnerability is resolved and retested, details should be published in a security advisory. At a minimum it should contain:
- a high level summary of the vulnerability, including its impact
- a clear list of vulnerable versions
- a clear list of patched versions
- caveats on when the software is vulnerable, such as specific configurations
- workarounds or mitigations usable as a temporary fix
- a CVE ID if one has been assigned
Where possible, add the disclosure timeline, credit for the researcher, technical details, and any detection signatures or indicators of compromise.
A template you can copy
| Section | What to write |
|---|---|
| Title | Product, component and weakness in plain words |
| Summary | Two or three sentences on what an attacker can do |
| Affected versions | Exact ranges, not "older versions" |
| Fixed versions | Exact release numbers and where to get them |
| Severity | Score and vector, with your assumptions |
| Conditions | Configurations or features that must be on |
| Workarounds | Temporary steps if upgrading is not yet possible |
| How to check | A command or setting that tells a user if they are exposed |
| Timeline | Report date, fix date, publish date |
| Credit | Name or handle the researcher chose |
| References | CVE ID, release notes, related issues |
Writing tips
Be exact about versions. A reader should be able to compare their version with your list in ten seconds. If you maintain several release lines, list the fixed version for each one.
Say what you do not know. If you are unsure whether an older branch is affected, say it was not tested. That is better than silence.
Keep technical depth proportional. OWASP notes that once a patch is out, attackers can reverse engineer the vulnerability, so delaying full details has limited value. But you do not have to publish a working exploit in the advisory. A description of the weakness and the fix is enough for most readers.
Make it findable. OWASP suggests a dedicated security page, a mailing list or forum, and links from changelogs and release notes. Publishing an advisory also does not make a vendor look bad. A clear process builds more confidence than hiding issues.
Order of operations on release day
- Release the fix.
- Confirm the researcher has retested, if they agreed to.
- Publish the advisory and update the CVE record.
- Notify customers through the channels you promised.
- Tell the researcher it is live, and thank them. See how to thank and credit researchers.
For a deeper release plan, read a coordinated release day plan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a fixed version is matched to an affected component, because your advisory's version lists feed that match for your customers.
Safeguard's SBOM and dependency scanning helps your customers see which releases they run, and you can try a free scan.
Quick check
Do I need an advisory for a low severity bug?
Not always. Many vendors list low severity fixes in release notes. Publish a full advisory when users must act or when a CVE ID exists.
Should I publish before every customer has upgraded?
Publishing usually follows the release of a fix. Give customers the fixed version and workarounds in the same notice so they can act at once.
Sources
Last reviewed: 19 October 2026.
