A good security advisory states what is affected, what is fixed, what to do now, and how severe it is, so a customer can decide in minutes. OWASP lists the contents: a summary and impact, vulnerable and patched versions, caveats, workarounds, a CVE ID where assigned, and the timeline and researcher credit.
Why the advisory matters
The advisory is the document your customers, their scanners and their auditors will read. A vague one forces everyone to guess, and guessing leads to over-patching, under-patching, or support tickets. OWASP says organizations should publish an advisory after the issue is resolved and retested, and make advisories easy to find.
The fields
- Title that names the product and the problem class.
- Summary in plain words, and the impact if exploited.
- Affected versions, as exact ranges.
- Patched versions, with where to get them.
- Caveats, such as configurations not affected or limits of the fix.
- Workarounds for people who cannot update at once.
- CVE ID where one has been assigned, and severity information.
- Timeline of report, fix and publication.
- Credit to the researcher, if they agree.
- Technical detail at a level that helps defenders without being a recipe.
OWASP lists most of these directly: summary and impact, vulnerable and patched versions, caveats, workarounds, CVE ID, plus timeline, credit and technical details as things to consider.
Affected ranges are the hard part
Customers and tools match your advisory against what they run. Give versions precisely, and say how to check for the vulnerable component. For libraries, use identifiers that tools understand. Our post on OSV version ranges explains the introduced and fixed convention.
Say what is not affected
A statement of what is not affected saves many support questions. Machine readable formats exist for this. See what is VEX.
Give workarounds honestly
Workarounds should say what they break and how to verify they work. Mark them as temporary. If a workaround is only partial, say so.
Credit and tone
OWASP encourages rewards and credit for reporters. It also says not to threaten legal action. Thank the reporter in the advisory text, with their consent, and keep the tone factual.
Make it findable
Put advisories in one stable location, with a feed if you can. Link it from the same place as your contact details. See how to write a vulnerability disclosure policy.
Safeguard's SBOM and dependency scanning can help your customers match advisories to what they run, and its policies can block builds that use an affected version.
Quick check
Do we need a CVE ID before publishing?
OWASP says to include one where assigned. It does not make an ID a precondition. Request one where appropriate.
Should the advisory include the exploit code?
OWASP lists technical details as something to consider. Share enough for defenders to detect and verify, and think carefully before releasing working exploit code.
Sources
Last reviewed: 19 October 2026.
