If you have fixed a security vulnerability, it is ASF Policy to also publish an advisory and include it in the CVE database.

If you're unsure if an issue is a security vulnerability, see For what issues to create advisories.

We have some tooling to make it easier to create advisories in a structured way: as PMC, you can self-allocate a CVE Id at https://cveprocess.apache.org/allocatecve and collaborate on the advisory there.

The CVE record lifecycle

A CVE record in the ASF CVE tool moves through four states:

State	What it means	Who/what advances into it
DRAFT	ID reserved, content still being filled in. Not on cve.org.	Set at allocation.
REVIEW	Content complete; ready for ASF Security Team / CNA review. Reviewers may leave comments. Not on cve.org.	Advanced when the record body is complete and the fix is about to ship (see Timing below).
READY	Content final, review feedback addressed, staged for the advisory email send. Not on cve.org.	A human (release manager) clicks this once reviewer comments are closed.
PUBLIC	Pushed to the global CVE database via the CNA feed. World-readable.	Advanced after the advisory email has been sent and archived on the project's public lists — that archive is the signal the advisory actually shipped.

Timing relative to the release

Advance a record to REVIEW only when the fix is about to ship — e.g. while the release candidate is being voted. Advancing populated records to REVIEW well ahead of the release forces reviewers to keep pushing them back.
Send the advisory emails only after the fixed release is public.
Move to PUBLIC only after the advisory email is archived on the project's public announce/users lists - make sure to add public mailing list url with the advisor as "vendor-advisory" link before moving to PUBLIC.

Description quality checklist

The published description is what operators read to answer "does this affect us, and what do we do?" A complete description satisfies all of:

Names the concrete upgrade target — the actual fixed version (e.g. "upgrade to X.Y.Z or later"), not "upgrade to the version with the fix".
States the trigger — WHO / WHEN / ACTION — the attacker role or capability required (WHO), the deployment shape / config / feature that must be active (WHEN), and the step taken against which surface (ACTION).
CWE in long form — CWE-NNN: <Canonical Title> (e.g. CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')), not a bare CWE-NNN.
Cross-references incomplete/split fixes — if this CVE follows a previously-published one (same root cause across multiple products/packages), name the prior CVE, state it did not cover this product, and tell users who applied the prior fix to apply this one too.
States attack requirements, helps operators assess exposure, explains impact, recommends mitigation — without handing attackers an exploit recipe.

Get a review

The Apache Security Team is happy to review your advisories! Change the CVE to the 'REVIEW' state to request a review. After the review the Security Team might move the CVE back to DRAFT state, but it is not necesary for you to act on the reivew comments.

Send the notification emails

Always preview before sending. Use the #email tab to preview the advisory exactly as it will be sent — same subject, body, and recipient list — before pressing Send these Emails. The preview catches formatting defects (truncation, broken markdown, missing patch links).

Once the fixes are released and you're happy with the advisory, you can send the notification emails with the 'Send these Emails' button on the 'OSS/ASF Emails' page.

After this, the Security Team will make sure the advisory is uploaded to the global CVE database in the JSON format described at https://github.com/CVEProject/cve-schema/

Publishing as OSV

A more modern file format to publish advisories is OSV. While it'd be great to be able to publish machine-readable advisories on our own infrastructure (as well as through CVE), this ecosystem is still in its early days. If you want to experiment, feel free to email security@apache.org for assistance or discuss your plans on the public security-discuss list.

You can find the schema for OSV at https://ossf.github.io/osv-schema/

We currently automatically convert public CVEs to OSV and publish them on experimental project pages, for example https://security.apache.org/projects/commons/.

Publishing as VDR

If your project already publishes an SBOM as part of your release, you might be interested in publishing your advisories in a VDR format at well. While it'd be great to be able to publish machine-readable advisories on our own infrastructure (as well as through CVE), this ecosystem is still in its early days. If you want to experiment, feel free to email security@apache.org for assistance or discuss your plans on the public security-discuss list.

The format for publishing a VDR in the CycloneDX family of formats is https://cyclonedx.org/capabilities/vdr/.

While SBOMs are static documents published with your release, VDRs are necessarily dynamic: vulnerabilities will typically be found after the software has been released.

A possibility is to create or find tooling to pick up CVE JSON files and get them into VDR documents that can be published and referenced from the SBOMs.

Apache Logging publishes VDR as an external BOM: see https://www.sonatype.com/blog/sbom-vdr-and-maven-transforming-the-apache-logging-experience-to-a-common-pattern for details on the pattern

Publishing updates to advisories

Updates to already-published advisories are allowed, but limited: we want to avoid situations where downstream users have already 'dismissed' the advisory based on the 'old' information, and may miss the 'new' information. For that reason, you cannot:

Widen affected version ranges
Increase severity ratings
Add additional necessary mitigation steps

If you discover such information after publication, you publish a follow-up advisory to make sure downstream users see it.

For other changes, such as clarifications to the description or refining weakness type classifications, you can make updates in the cveprocess tool and ping security@apache.org to get your change published.