Here is guidance for Apache committers on how to handle security vulnerabilities. The Apache Security Team is available to provide help and advice to Apache projects that require it.
Projects with known, published vulnerabilities should provide information about those vulnerabilities on pages such as the httpd security pages. Provide a clear link on the project's home page to the security information.
Do not enter details of security vulnerabilities in a project's public bug tracker unless the necessary configuration is in place to limit access to the issue to only the reporter and the project team.
Projects may wish to create a project-specific security mailing list.
These take the name in the form security@project.apache.org, like
security@tomcat.apache.org.
When the infrastructure team creates project-specific security mailing lists, they configure them to copy
all messages to security@apache.org automatically, so you do not have to
cc security@apache.org when sending mail to such a list.
We expect that a subset of project PMC members and committers will subscribe to the project-specific security mailing list. Do not use the list as a third-party notification system; non-committers should not be subscribed to the list.
Here is the default process for handling a possible security vulnerability. Projects that need a different process must contact security@apache.org for advice, and should expect to clearly and publicly document their process.
Do not make information about the vulnerability public until it is formally announced at the end of this process. That means, for example, that you should not create a public Jira ticket to track the issue, or a public GitHub issue, since those would make the issue public. Messages associated with any commits should not make any reference to the security nature of the commit.
The person discovering the issue, the reporter, identifies the mailing list to report to.
If the project the issue relates to has a security@[project].apache.org mailing list listed on
security projects list, use that mailing list. Otherwise, use security@apache.org.
Note that the Security teams will ignore all messages that do not relate to reporting or managing an undisclosed security vulnerability in Apache software.
If the report comes to security@apache.org, the security team forwards
it to the project's security list or, if the project does not
have a security list, to the project's private (PMC) mailing list.
The Security Team responds to the original reporter that they have done this.
If the project does not have a dedicated security@project.apache.org
mailing list, all further communication regarding the vulnerability should be copied to security@apache.org.
There is no need to do this for messages sent to security@project.apache.org since these are automatically copied to security@apache.org.
The project team sends an e-mail to the original reporter to acknowledge the report, with a copy to the relevant security mailing list.
The project team investigates the report and either rejects or accepts it. Project team members may share information about the vulnerability with domain experts (including colleagues at their employer) at the discretion of the project's security team, providing that they make clear that the information is not for public disclosure.
If the project team rejects the report, the team writes to the reporter to explain why, with a copy to the relevant security mailing list.
If the project team accepts the report, the team writes to the reporter to let them know that they have accepted the report and that they are working on a fix.
The project team requests a CVE (Common Vulnerabilities and Exposures) ID from the internal portal, https://cveprocess.apache.org; or by
sending an e-mail with the subject "CVE request for..." to security@apache.org, providing a
short (one-line) description of the vulnerability. security@apache.org can
help determine if a report requires multiple CVE IDs or if multiple reports
should be merged under a single CVE ID.
The ASF security team allocates a CVE ID and sends to the project team a link to the internal portal where it can enter details of the vulnerability.
The project team agrees on a fix on their private list.
The project team documents the details of the vulnerability and the fix on the internal portal. The portal generates draft announcement texts. For an example of an announcement see Tomcat's announcement of CVE-2008-2370. The level of detail to include in the report is a matter of judgement. Generally, reports should contain enough information to enable people to assess the risk the vulnerability poses for their own system, and no more. Announcements do not normally include steps to reproduce the vulnerability.
Optionally, you can put the CVE into the REVIEW state to request a
review from the Security team. You can discuss the disclosure
using the 'comment' feature, which also sends the comments to the
relevant private mailing list(s).
The project team provides the reporter with a copy of the fix and the draft vulnerability announcement for comment.
The project team agrees on the fix, the announcement, and the release schedule with the reporter. If the reporter is unresponsive in a reasonable timeframe this should not block the project team from moving to the next steps, particularly if an issue is of high severity or impact.
The project team commits the fix. Do not make any reference that the commit relates to a security vulnerability.
The project team creates a release that includes the fix.
After (or at the same time as) the release announcement, the project team announces the vulnerability and the fix.
Set the CVE status to READY in the internal portal. You can then use the portal to send the emails.
The vulnerability announcement should be sent to the following destinations:
a. the same destinations as the release announcement
b. the vulnerability reporter
c. the project's security list (or security@apache.org if the project does
not have a dedicated security list)
d. oss-security@lists.openwall.com (subscription not required).
This is the first point that any information regarding the vulnerability is made public.
The project team updates the project's security pages.
Add the link to the public announcement on the mailinglist as a 'reference' in the CVE. This notifies the security team, which will submit the information to the CVE project.
If the project repository is in Subversion, add the CVE ID to the log for the commit that applied the fix. Do not try to do this if your project uses a Git repository, as editing a pushed commit causes all sorts of problems.
CVE IDs are unique identifiers given to security vulnerabilities. The Apache Security Team is a CVE Numbering Authority (CNA) covering all Apache projects and is the only group able to allocate IDs to Apache Software Foundation project issues.
If you believe the details of an issue are described
incorrectly, contact security@apache.org.