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.
Ideally a description has 4 components:
While it is 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.
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
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/
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/.
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
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:
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.