Title: ASF Project Security for Committers Notice: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at . http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. # Introduction # This section is intended to provide guidance to Apache committers on how security vulnerabilities should be handled. The [Apache Security Team](mailto:security@apache.org) is available to provide help and advice to Apache projects should it be required. # Publishing information # Projects with known, published vulnerabilities should provide information about those vulnerabilities as part of the project web pages e.g. the [httpd security pages](http://httpd.apache.org/security_report.html). The security information should be clearly linked from the project's homepage. Projects may also wish to create a project specific security mailing list. These take the form of security@project.apache.org, e.g. security@tomcat.apache.org Security vulnerabilities should not be entered 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. # Vulnerability handling # A typical process for handling a new security vulnerability is as follows: Note: No information should be made public about the vulnerability until it is formally announced at the end of this process. That means, for example that a Jira issue must NOT be created to track the issue since that will make the issue public. Also the messages associated with any commits should not make ANY reference to the security nature of the commit. 1. The person discovering the issue, the reporter, reports the vulnerability privately to security@project.apache.org or to security@apache.org 1. Messages that do not relate to the reporting or managing of an undisclosed security vulnerability in Apache software are ignored and no further action is required. 1. If reported to security@apache.org, the security team will forward the report (without acknowledging it) to the project's security list or, of the project does not have a security list, to the project's private (PMC) mailing list. 1. The project team sends an e-mail to the original reporter to acknowledge the report. 1. The project team investigates report and either rejects it or accepts it. 1. If the report is rejected, the project team writes to the reporter to explain why. 1. If the report is accepted, the project team writes to report to let them know it is accepted and that they are working on a fix. 1. The project team requests a CVE number from security@apache.org by sending an e-mail with the subject "CVE request for..." and providing a short (one line) description of the vulnerability. 1. The project team agrees the fix on their private list. 1. The project team provides the reporter with a copy of the fix and a draft vulnerability announcement for comment. 1. The project team agrees the fix, the announcement and the release schedule with the reporter. For an example of an announcement see [Tomcat's announcement of CVE-2008-2370](http://markmail.org/message/w7mdjdxeqius7d6l) 1. The project team commits the fix. No reference should be make to the commit being related to a security vulnerability. 1. The project team creates a release that includes the fix. 1. The project team announces the release and the vulnerability. Typically this will be sent to the reporter, the project's users list, the project's dev list, the project's announce list, security@apache.org, full-disclosure@lists.grok.org.uk and bugtraq@securityfocus.com. The project's security pages should also be updated. This is the first point that any information regarding the vulnerability is made public. 1. The log for the svn commit that applied the fix is updated to include the CVE number. If the project does not have a dedicated security@project.apache.org mailing list, all 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. Information may be shared with domain experts (eg colleagues at your employer) at the discretion of the project's security team providing that it is made clear that the information is not for public disclosure and that security@apache.org or the project's security mailing list must be copied on any communication regarding the vulnerability.