これは、セキュリティの脆弱性をどのように処理するかについての、Apacheコミッター向けのガイダンスです。 Apacheセキュリティチームは、必要とするApacheプロジェクトに支援と助言を提供するために利用できます。
既知の公開された脆弱性を持つプロジェクトは、httpdセキュリティページのようなページでそれらの脆弱性に関する情報を提供する必要があります。プロジェクトのホームページにセキュリティ情報への明確なリンクを提供してください。
問題へのアクセスを報告者とプロジェクトチームのみに制限するための必要な設定が整っていない限り、プロジェクトの公開バグトラッカーにセキュリティ脆弱性の詳細を入力しないでください。
プロジェクトは、プロジェクト固有のセキュリティメーリングリストを作成したい場合があります。これらは、security@tomcat.apache.orgのように、security@project.apache.orgの形式で名前を付けます。
インフラストラクチャチームがプロジェクト固有のセキュリティメーリングリストを作成するとき、すべてのメッセージを自動的にsecurity@apache.orgにコピーするように構成するため、そのようなリストにメールを送信するときにsecurity@apache.orgをccする必要はありません。
プロジェクトのPMCメンバーとコミッターのサブセットが、プロジェクト固有のセキュリティメーリングリストを購読することが期待されます。このリストをサードパーティの通知システムとして使用しないでください。コミッターでない人はリストを購読しないでください。
以下は、可能性のあるセキュリティ脆弱性を処理するためのデフォルトのプロセスです。異なるプロセスが必要なプロジェクトは、アドバイスのためにsecurity@apache.orgに必ず連絡する必要があり、そのプロセスを明確かつ公に文書化する必要があります。
このプロセスの最後に正式に発表されるまで、脆弱性に関する情報を公開しないでください。つまり、たとえば、問題を追跡するための公開Jiraチケットや、公開GitHubイシューを作成しないでください。これらは問題を公開することになります。コミットに関連付けられたメッセージは、コミットのセキュリティの性質に言及しないでください。
問題を発見した人、つまり報告者は、報告するメーリングリストを特定します。問題が関連するプロジェクトに、セキュリティプロジェクトリストに記載されているsecurity@[project].apache.orgメーリングリストがある場合は、そのメーリングリストを使用してください。それ以外の場合は、security@apache.orgを使用してください。
セキュリティチームは、Apacheソフトウェアで未公開のセキュリティ脆弱性の報告または管理に関係のないすべてのメッセージを無視することに注意してください。
レポートがsecurity@apache.orgに届いた場合、セキュリティチームはそれをプロジェクトのセキュリティリストに転送するか、プロジェクトにセキュリティリストがない場合は、プロジェクトのプライベート（PMC）メーリングリストに転送します。セキュリティチームは、これを行ったことを元の報告者に返信します。
プロジェクトに専用のsecurity@project.apache.orgメーリングリストがない場合、脆弱性に関するその後のすべての通信はsecurity@apache.orgにコピーする必要があります。security@project.apache.orgに送信されたメッセージについては、これを行う必要はありません。これらは自動的にsecurity@apache.orgにコピーされるためです。
プロジェクトチームは、レポートを承認するために、元の報告者にメールを送信し、関連するセキュリティメーリングリストにコピーします。
プロジェクトチームはレポートを調査し、却下または受け入れます。プロジェクトチームのメンバーは、情報が公開されないことを明確にするという条件で、プロジェクトのセキュリティチームの裁量により、ドメインの専門家（雇用先の同僚を含む）と脆弱性に関する情報を共有できます。
プロジェクトチームがレポートを却下した場合、チームは理由を説明するために、関連するセキュリティメーリングリストにコピーして報告者に書き込みます。
プロジェクトチームがレポートを受け入れた場合、チームはレポートを受け入れ、修正に取り組んでいることを報告者に知らせるために書き込みます。
プロジェクトチームは、内部ポータルhttps://cveprocess.apache.orgから、または件名「...のCVEリクエスト」のメールをsecurity@apache.orgに送信することにより、脆弱性の簡単な（1行の）説明を提供して、CVE（共通脆弱性識別子）IDを要求します。security@apache.orgは、レポートに複数のCVE IDが必要か、複数のレポートを1つのCVE IDにまとめる必要があるかを判断するのに役立ちます。
ASFセキュリティチームはCVE IDを割り当て、プロジェクトチームに脆弱性の詳細を入力できる内部ポータルへのリンクを送信します。
プロジェクトチームは、プライベートリストで修正に合意します。
プロジェクトチームは、内部ポータルで脆弱性の詳細と修正を文書化します。ポータルは、発表テキストの草案を生成します。発表の例については、TomcatのCVE-2008-2370の発表を参照してください。レポートに含める詳細のレベルは、判断の問題です。一般に、レポートには、人々が自分のシステムに対する脆弱性のリスクを評価するのに十分な情報が含まれている必要があり、それ以上含まれている必要はありません。発表には通常、脆弱性を再現するための手順は含まれていません。
オプションで、CVEをREVIEW状態にして、セキュリティチームからのレビューをリクエストできます。「コメント」機能を使用して開示について話し合うことができます。これにより、コメントが関連するプライベートメーリングリストにも送信されます。
プロジェクトチームは、コメントのために修正と脆弱性発表の草案のコピーを報告者に提供します。
プロジェクトチームは、修正、発表、およびリリーススケジュールについて報告者と合意します。報告者が妥当な時間内に応答しない場合、特に問題が重大度または影響が高い場合は、プロジェクトチームが次のステップに進むことを妨げるべきではありません。
プロジェクトチームは修正をコミットします。コミットがセキュリティ脆弱性に関連していることを言及しないでください。
プロジェクトチームは、修正を含むリリースを作成します。
リリース発表後（または同時）、プロジェクトチームは脆弱性と修正を発表します。内部ポータルでCVEステータスをREADYに設定します。その後、ポータルを使用してメールを送信できます。脆弱性の発表は、次の宛先に送信する必要があります。
a. リリース発表と同じ宛先
b. 脆弱性の報告者
c. プロジェクトのセキュリティリスト（または、プロジェクトに専用のセキュリティリストがない場合はsecurity@apache.org）
d. oss-security@lists.openwall.com（サブスクリプションは不要）。
これは、脆弱性に関する情報が公開される最初の時点です。
プロジェクトチームは、プロジェクトのセキュリティページを更新します。
メーリングリストでの公開発表へのリンクをCVEの「参照」として追加します。これにより、セキュリティチームに通知され、セキュリティチームがCVEプロジェクトに情報を送信します。
プロジェクトリポジトリがSubversionにある場合は、修正を適用したコミットのログにCVE IDを追加します。プロジェクトがGitリポジトリを使用している場合は、この操作を試みないでください。プッシュされたコミットを編集すると、あらゆる種類の問題が発生するためです。
CVE IDは、セキュリティの脆弱性に付与される一意の識別子です。Apacheセキュリティチームは、すべてのApacheプロジェクトを対象とするCVE番号付与機関（CNA）であり、Apache Software Foundationプロジェクトの問題にIDを割り当てることができる唯一のグループです。
問題の詳細が誤って記述されていると思われる場合は、security@apache.orgにお問い合わせください。