...

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.

Write a good description

...

The CVE record lifecycle

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

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 will 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.

...

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.