一般的なバグやセキュリティバグのレポート方法に関する FAQ

Q: どのようにしてバグをレポートしたらよいですか?

まずはじめに、 課題トラッカーでその問題がすでにレポートされていないかを検索します。 誰でもデータベースを検索することができます。しかし、もし問題に該当するバグレポートが見つからずに、自分でバグをレポートする場合には、「User」ロールが必要となるため、OpenSSO のプロジェクトメンバーになる必要があります。 詳細については、 Governance のページを参照するか、 ナビゲーションバーで Join をクリックしてください。

Q: セキュリティバグをレポートする方法は異なりますか?

はい、セキュリティバグは緊急の問題として扱うため、セキュリティの脆弱性については、他の種類のバグとは異なる形で扱います。 バグを秘密に解析して修正し、バグの存在とその修正について同時にアナウンスするようにするために、セキュリティバグは通常の課題トラッカー経由ではレポートできないようになってます。

Q: どのようにしてセキュリティバグをレポートしたらよいですか?

java.net のメーリングリストアーカイブは、一部のメンバーに限定して公開するという機能がないため、 セキュリティバグは、 java.net のインフラとは別の、非公開なセキュリティチームのメールエイリアスに送る必要があります。 セキュリティチームのメールアドレスは:

opensso-sec-bugs-ext@sun.com

セキュリティバグのエイリアスへの加入やメールアーカイブの参照は少数のメンバーからなるセキュリティチームに限定されます。 プロジェクトの開始時点で、セキュリティチームのメンバーは「Module Owners」ロールを持つユーザーのみです。

注意：セキュリティチームのエイリアスにはセキュリティバグのみを送るようにしてください。

Q: セキュリティバグかどうかはどのようにしたら判断できますか?

判断は難しいかもしれません。 私たちは、セキュリティバグ以外のバグがエイリアスに送られること - それは正規のプロセスに反して意図的に行われることもあれば、本当にセキュリティバグだと思って誤って送られることもあると思いますが、そういったことがあることは想定しています。 セキュリティチームでは、送られてきたバグについてチームのエイリアス (opensso-sec-bugs-ext@sun.com)内でそれがセキュリティバグであるかの妥当性を議論します。 チーム内での意見がまとまった時点で、セキュリティチームのメンバーからバグをレポートした人にメールが送られ、そのバグはセキュリティバグではないので、通常のプロセスで課題トラッカーからバグをレポートしてください、という指示を受け取る場合もあります。

Q: セキュリティバグを評価する際の基準は何ですか?

セキュリティチームはそのバグがセキュリティバグであると判断したら、次にそのバグの重要度(severity)についての評価を行います。

1. その脆弱性はどれほど重大なものか？
   • Critical: そのバグにより任意のコードが実行される可能性がある。
   • Severe: そのバグがリソースの機密性や完全性、あるいは有用性を危うくする可能性がある。
   • Moderate: それ以外 - 例えば、そのバグがアクティブなセッション数など操作情報を暴露するなど。
2. どれほど容易にその脆弱性が利用されるか? スクリプトによる攻撃が可能か? 攻撃者は攻撃をしかける前に通常のユーザーとして認証に成功する必要があるか?
3. 誰がその問題をレポートしたか? プロジェクト外の人からのレポートはプロジェクト内のエンジニアからレポートされたものよりもより緊急な問題として扱われます。

Q: CVE(Common Vulnerabilities and Exposures) リストとは何ですか?

CVE は脆弱性やセキュリティ暴露のリストを標準化した名前で提供します。 すべての公開されている脆弱性やセキュリティ暴露について名前を標準化することが目的です。 CVE 名 (または CVE 番号、 CVE-ID) はユニークなもので、公開されている既知のセキュリティ脆弱性の共通の識別子となります。 CVE 名には entry と candidate の 2 つの状態があります。 Entry 状態は CVE 名が CVE リストに加えられたことを意味します。 Candidate 状態は (または candidate 番号、CAN) はその名前をリストに加えるかどうか検討中であることを意味します。

Q: どのようなプロセスでセキュリティバグは修正されますか?

1. 修正作業はセキュリティチームの限られたメンバーでのみ議論を重ねながら、できる限り内密で行われます。 コードのレビューはセキュリティチーム内で行われます。
2. 修正コード(パッチ)が作られてテストが終わったら、重要なユーザーにのみそのことが伝えられます。そのユーザーはバグが公のものになる前にパッチを適用することが許可されます。
3. そのバグと対応する修正パッチは同時か、できるだけ同時にアナウンスされます。