A good advisory tells customers what happened, who is affected, what to do and where to get the fix. It includes a summary and impact, vulnerable and patched versions, caveats, workarounds, the CVE ID if one exists, and credit for the researcher. Publish it somewhere easy to find.
The fields
The OWASP cheat sheet lists what an advisory should hold:
- A short summary and the impact
- The vulnerable versions and the patched versions
- Caveats, such as configurations that are or are not affected
- Workarounds, for customers who cannot upgrade at once
- The CVE ID, if assigned
- Credit for the researcher
Add the date, a contact for questions, and a revision history so changes are visible.
Write the summary for the customer
Customers want to know three things: am I affected, how bad is it, what do I do now? Put those in the first paragraph. Technical depth can follow for those who need it. Avoid minimizing language. If exploitation needs authentication, say that, and also say what an authenticated attacker gains.
Be exact on versions
Say "versions 2.1.0 through 2.4.3 are affected, fixed in 2.4.4" rather than "older versions". Customers match your text against their inventory, and ambiguity wastes their time. If you do not know whether an old branch is affected, say you do not know and what you are doing about it.
Workarounds
A workaround is not a fix, so label it. Describe the setting or control, the trade-off, and how to verify it took effect. If there is no workaround, say so. That is useful information.
Where to publish
Make advisories easy to find: a security page, a mailing list, or release notes that link to it, as OWASP suggests. Keep old advisories online. Customers and auditors will look for them years later.
Credit and timing
Agree credit wording with the researcher before publishing, and let them see the draft. Match publication to your agreed timeline; our post on coordinated disclosure covers how to agree one. If a CVE is available, request it early so the ID is in the advisory on day one.
Quick check
Should every bug get an advisory?
Not necessarily. Publish when customers need to act, such as upgrading or changing a setting. Internal hardening with no customer impact can go in release notes.
Do we need a machine readable format?
It helps customers who scan automatically, but a clear human readable advisory comes first.
Sources
Last reviewed: 19 October 2026.
