脆弱性開示方針
セキュリティ上の脆弱性の取り扱いに関する調整を提供する。
脆弱性の報告
We strongly encourage the reporting of potential security vulnerabilities to us first, before disclosing them in a public forum.
脆弱性やセキュリティ問題を報告するための主なメールアドレスは [email protected]です。他の汎用の連絡先アドレスを使用しても、セキュリティ問題の適切な管理はできませんので、未公開のセキュリティ脆弱性を報告する場合は、このアドレスを使用してください。
セキュリティ連絡先は、Pandora FMS の非公開のセキュリティ脆弱性を報告し、その脆弱性を修正するプロセスを管理するためにのみ使用してください。通常のバグ報告やセキュリティアーキテクチャに関する質問は受け付けていません。これらのアドレスに送られたメールは、Pandora FMS の未公開のセキュリティ問題に関連しないものはすべて無視されます。
また、セキュリティチームは Pandora FMS の脆弱性を扱いますが、サポートやコンサルティング、デプロイ、カスタム機能の開発は行いません。脆弱性の報告はすべて [email protected] 宛にお願いします。報告する脆弱性ごとに、プレーンテキストのメールを一通送ってください。プレーンテキストで簡単に説明できるにもかかわらず、画像、動画、HTML、またはPDFの添付ファイルとしてレポートを送信した場合、再提出をお願いすることがあります。一度に複数の問題を含むメールを送信しないでください。
暗号化された送信は必須ではありませんし、好ましいことでもありません。
セキュリティ問題を報告するには?
以下の情報は、Pandora FMS セキュリティチームの参考になります：
- セキュリティ上の不具合を特定した日時。
- 影響を受ける Pandora FMS のバージョン範囲
- 報告するセキュリティ問題の種類： XSS、CSRF、SQLi、RCE。
- 影響を受けるコンポーネント コンソール、サーバ、エージェント、API….
- スクリーンショット、スクリーン録画、http(s)トランザクションログ、POC エクスプロイト（認証されていないファイル共有サービスを介して証拠を共有したり、機密情報を共有することは避けてください。
- 問題が容易に特定できない可能性があるため、問題を再現するためのステップバイステップの手順。
脆弱性情報
andora FMS の公開されている脆弱性情報は、通常リリースノートに記載されています。もし、プロジェクトのウェブサイトで探している情報が見つからない場合は、フォーラムで質問してください。セキュリティに関する問い合わせは、以下のような質問には使わないでください。
- パッケージを安全に設定する方法；
- 公開されている脆弱性が、利用している Pandora FMS パッケージの設定に適用されるかどうか；
- 公開されている脆弱性が、あなたが利用している Pandora FMS パッケージの特定のバージョンに適用されるかどうか；
- 公開されている脆弱性に関するさらなる情報の入手；
- 公開されている脆弱性に対処するためのパッチや新しいリリースの入手。
公開フォーラムは、このような質問をするための場所です。Pandora FMS セキュリティチームに送られた質問は無視されます。
脆弱性の取り扱い
新しいセキュリティ脆弱性を扱う典型的なプロセスは以下の通りである：
注：このプロセスの最後に正式に発表されるまでは、脆弱性に関する情報を公開してはいけません。つまり、例えば、その問題を追跡するために、Githubの問題を作成してはならないということです。また、コミットに関連するメッセージは、そのコミットのセキュリティ上の性質について一切言及すべきではありません。
- 問題の発見者である報告者は、[email protected] に個人的に脆弱性を報告します。
- Pandora FMS の公開されていないセキュリティ脆弱性の報告や管理に関係のないメッセージは無視され、それ以上のアクションは必要ありません。
- [email protected] に報告された場合、セキュリティチームはその報告を(確認せずに)セキュリティチームの他のメンバーに転送します。
- プロジェクトチームは、報告者に電子メールを送り、報告を確認します。
- プロジェクトチームはその報告を調査し、却下するか受理するかを決定する。
- 報告が却下された場合、プロジェクトチームはその理由を説明するために報告者に書簡を送る。
- 報告が受理された場合、プロジェクトチームは、受理されたこと、および修正に取り組んでいることを報告者に知らせるために報告書を書く。
- セキュリティチームは、社内のセキュリティケース番号と、そのセキュリティケース番号に割り当てられた 1 つ以上の開発チケットを割り当てる。
- セキュリティチームは、報告者に CVE 番号を割り当てます。Pandora FMS は現在 CVE CNA である。
- プロジェクトチームは報告者に修正内容のコピーと脆弱性アナウンスの草案を提供し、コメントを求める。
- セキュリティチームは、報告者と修正内容、アナウンス、リリーススケジュールについて合意する。報告書にどの程度の詳細情報を含めるかは、判断の問題である。一般に、報告書には、その脆弱性に関連するリスクをそのシステムで評価するのに十分な情報を含めるべきであり、それ以上は含めるべきでない。
- 通常、脆弱性を再現するためのステップは含まれない。
- プロジェクトチームが修正をコミットし、リリースに含める。
- プロジェクトチームはリリースを発表する。リリースのアナウンスは、通常のチャネル（ニュースレター、フォーラム、ウェブサイト）に送る。
- 有効なサポート契約を結んでいるクライアントには、問題が一般に知られる前にアップグレードが可能な期間をメールで知らせる。
- プロジェクトチームが脆弱性を公表する（CVEの更新を含む）。脆弱性の告知は、リリースのアナウンスの後に行う。ほとんどの場合、ユーザーや顧客がソフトウェアをアップデートするのに十分な時間を与えるため、一般への告知は修正プログラムのリリースから少なくとも1カ月後に行う。
ただし、その情報が一般に公開されるものではないこと、および、脆弱性に関するいかなる連絡にも [email protected] をコピーしなければならないことを明確にすることを条件とする。