Publish a new revision, say what changed and why, bump the version and date, and keep the earlier text available or summarized. Do not silently edit. Standards back this: OpenVEX says the document version must be incremented when any content changes, and CSAF includes a revision history.
Why open corrections protect trust
Advisories get things wrong. A version range is too narrow, a workaround does not work on one platform, or exploitation status changes. Customers forgive an error that is fixed in the open. They do not forgive a page that quietly changed after they acted on it.
A visible change record also helps customers' auditors, who may ask what you knew on a given date.
What the standards say
OpenVEX requires a document version, and says it must be incremented when any content within the document changes. It also requires a timestamp for when the document was issued, and statements can carry their own timestamps that override the document's.
CSAF tracks the same ideas in its tracking section, which lists fields for ID, initial release date, current release date, revision history, status and version. The specification says a CSAF document must use only one versioning system.
You do not need either format to follow the principle. The principle is: every change gets a new version number, a date and a reason.
Steps for a correction
- Confirm the error and its scope. Which customers could have acted on the wrong information?
- Decide the corrected content and check it with engineering.
- Increase the version number and update the date.
- Add a revision note at the top or in a change log: what changed, in plain words.
- Notify the people who received the original, using the same channel.
- If you publish machine readable files, update them in the same release as the page.
- Record the correction in your internal incident or advisory tracker.
Example change log wording
| Version | Date | Change |
|---|---|---|
| 1.0 | Initial date | First publication |
| 1.1 | Later date | Added version 3.2 to the affected range. Earlier text listed 3.3 and above only. |
| 1.2 | Later date | Exploitation status changed after a public report. Source linked. |
Say what the earlier text said when the difference matters to a decision. Customers who patched on the old range need to know they are not finished.
What to avoid
- Deleting the earlier version with no trace.
- Reusing the same version number for different content.
- Correcting the page but not the notification email or the machine readable copy.
- Blaming a customer or researcher for the original mistake.
Quick check
Is it ever fine to edit an advisory without a version change?
Typos that change no meaning can be fixed quietly, but anything a customer might act on deserves a new version and a note.
Do I need CSAF or OpenVEX to version advisories?
No. Both formalize version and date tracking, but the same discipline works on a plain web page.
Safeguard's compliance and evidence automation helps teams keep dated evidence for their security processes. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
