The Apache Software Foundation

ASF Project Security for Committers

Introduction

This section is intended to provide guidance to Apache committers on how
security vulnerabilities should be handled. The Apache Security
Team 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. 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.
Projects that wish to use other processes MAY do so, but MUST clearly and
publicly document their process and have security@ review it ahead of time.

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.

The person discovering the issue, the reporter, reports the
vulnerability privately to security@project.apache.org or to
security@apache.org

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.

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.

The project team sends an e-mail to the original reporter to acknowledge the report.

The project team investigates report and either rejects it or accepts
it.

If the report is rejected, the project team writes to the reporter to
explain why.

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.

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.

The project team agrees the fix on their private list.

The project team provides the reporter with a copy of the fix and a
draft vulnerability announcement for comment.

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. The level of detail
to include in the report is a metter of judgement. Generally, reports should
contain enough information to enable people to assess the risk associated with the
vulnerability for their system and no more. Steps to reproduce the vulnerability
are not normally included.

The project team commits the fix. No reference should be made to the
commit being related to a security vulnerability.

The project team creates a release that includes the fix.

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,
oss-security@lists.openwall.com 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.

The log for the svn commit that applied the fix is updated to include
the CVE number. Projects that use git as their primary source code control
system should not do this as editing a pushed commit causes all sorts of
problems.

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.

CVE names

Common Vulnerabilities and Exposures (CVE)
IDs are a unique identifiers given to security flaws. The Apache
Security Team maintain a pool of CVE names which we can allocate to
new issues affecting Apache projects.

There is no need to contact Mitre to give them any information about
the CVE, either before or after the issue is public.

Mitre monitor various public sources of vulnerability announcements
and then they create the the CVE 'description' based on their own
analysis of the issue. This means that once your project has made a
CVE name public which was given to you by the Apache Security Team, it
will take time before the details show up on the Mitre CVE site. For
issues of high severity this can happen within hours, but don't be
concerned if for lower severity/vibible issues it takes many days or
weeks.

If you believe Mitre have the details of an issue described
incorrectly, see the CVE
FAQ for how to contact
them with corrections.