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.

Write a good description

Ideally a description provides enough information for an operator to determine whether they're affected, what the impact is of a successful attack, and what mitigations or fixes they can apply. While it's OK to err on the side of transparency (after all, all the code is open anyway), we typically don't make it too easy for attackers by providing exploitation details.

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 move the CVE back to DRAFT state

Send the notification emails

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