A customer security bulletin should say, in the first lines, which products and versions are affected, what an attacker could do, and what to do now. Then add the fix, a workaround, severity, dates and a contact. Keep it factual, dated and versioned, and link to a machine readable record.
Why use a template
Under pressure, people write long bulletins that bury the action. A template forces the same order every time, which helps readers and speeds review. It also makes gaps visible: an empty "workaround" field is information in itself.
The template
| Section | Content | Tip |
|---|---|---|
| Title | Product, short issue name, identifier | Put the CVE ID in text, not only in the title |
| Status | Under investigation, affected, fixed or not affected | Use the same four words as your VEX |
| Summary | Two sentences: what and so what | Lead with the action |
| Affected | Product names and version ranges | Include unaffected versions explicitly |
| Impact | What an attacker could do | Avoid exploit steps |
| Severity | Score, version of the scoring system, vector | Say who scored it |
| Fix | Fixed version and where to get it | One link |
| Workaround | Steps if the customer cannot upgrade | Say what it costs them |
| Exploitation | Whether you know of attacks | Say "not known to us" only if you checked |
| Dates | First published, last updated | Add a revision note |
| Contact | Name or role, channel | Same as your security contact page |
| References | Upstream advisory, VEX link | Stable URLs |
Writing it
- Draft the status line first. If you cannot choose one of the four words, you are not ready.
- Write the summary last, when you know the answer.
- State the severity source. CVSS version 4.0 separates Base, Threat, Environmental and Supplemental metrics, and says Base is typically supplied by the vendor or bulletin analyst while consumers add threat and environmental context. A bulletin score is a Base view, so say that customers may rescore for their setup.
- List fixed and unaffected versions, not only affected ones. Customers search for their own version.
- Add a revision history. Every change gets a date and a one line reason.
Words to avoid
- "Some customers may be affected." Say which.
- "There is no evidence of exploitation." Say what you checked.
- "Critical" with no score or source.
- Blame for a supplier. State the component and move on.
Make it findable
Publish at a stable address, link it from your security contact page, and give it the identifier in the file name. See where to publish VEX and advisories.
Quick check
Should a bulletin name the vulnerable function?
Only if it helps customers decide, and not if it gives attackers a head start before a fix is available.
How often should we update a bulletin?
Whenever a fact changes, and on the next update time you promised. Add a dated revision note each time.
Safeguard's autonomous remediation with fix pull requests is off by default and every category starts on Manual, so a human decides what ships. A free scan can show affected dependencies in your own projects.
Sources
Last reviewed: 19 October 2026.
