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.	Set at allocation.
REVIEW	Content complete; requesting a review from the rest of the team and from the ASF Security Team. Reviewers may leave comments.	Advanced when the record body is complete. The Apache Security Team is happy to review your advisories!
READY	Content final, review feedback addressed, staged for the advisory email send.	A human (release manager) clicks this once reviewer comments are closed. Once the fixed release is public, send the notification emails (for example using the 'Send these Emails' button on the 'OSS/ASF Emails' tab) and add the public url with the advisory (for example the notification in the https://lists.apache.org/ archive) as reference of type "vendor-advisory".
PUBLIC	Pushed to the global CVE database. World-readable.	Advanced by the ASF Security Team after the advisory email has been sent by the project and archived on the project's public lists.

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), but without handing attackers an exploit recipe.
Problem type from the autocomplete — CWE-NNN: <Canonical Title> (e.g. CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'))
Cross-references incomplete/split fixes — if this CVE follows a previously-published one (e.g. same root cause across multiple products/packages), name the prior CVE, explain the relationship.

Credit

Credit the original reporter of the issue. If multiple reporters independently reported the same issue, you may credit them all. If additional duplicate reports come in after the fix has already been committed publicly, you don't need to credit such reporters.

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.

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.

Page tree

How to publish an advisory