私の会社では、Microsoft Secure Development Lifecycleの採用に取り組んでおり、MSDLプロセスの一部には、セキュリティとプライバシーのバグバーの確立が含まれます。プロジェクトの概要です。MSDLの前にバグバーの概念を聞いたことがあります。これは基本的に、最終製品で受け入れるバグのレベル/量の定義であると理解していますが、私はプロジェクトのバグバーを作成する方法を理解していません。バグバーを確立するための十分に文書化されたプロセスから学ぶことができますか？
プロジェクトの例や実際のシナリオについて、グーグルを試してみました。プロジェクトの開始時にバグバーを定義しますが、バグバーを確立するプロセスについて良い結果やヒントを得ることができないようです。 MSDLの例がありますですが、私はこのようなものを定義するプロセスについて学ぶことに興味があります。たとえば、以前にこのようなことを行ったことがある人のために、非常に具体的な方法でバグバーを定義しましたか（たとえば、"不正なファイルシステムアクセスはありません。ファイルシステム"）、またはバグが見つかった場合は1から5のスケール（5が最も深刻）で評価するという延期されたアプローチを採用しましたか？今すぐ確立してください3を超えるバグは出荷されず、バグが発見されるまでランキングを残しますか？前者をやろうとするのは愚かで不可能な活動のように感じますが、後者はプロジェクトが本格化するときに寛大さに偏る傾向があります。
繰り返しになりますが、すべてをまとめます。簡潔な質問に、バグバーを定義/作成するための十分に文書化されたアプローチを誰かが私に提供できますか？
回答
Let ” ■バグバーの基本的な定義から始めます。
品質ゲートとバグバーは、セキュリティとプライバシーの品質の最小許容レベルを確立するために使用されます。プロジェクトチーム開発フェーズごとに品質ゲートをネゴシエートする必要があります（たとえば、すべてのコンパイラ警告は、コードチェックインの前にトリアージして修正する必要があります）。バグバーは、セキュリティ脆弱性の重大度のしきい値を定義するために使用される品質ゲートです。リリース時に「重大」または「重要」の評価が付けられたアプリケーションに既知の脆弱性はありません。バグバーを一度設定すると、決して緩和しないでください。
ソフトウェアユーザーがバグレポートを提出するとき、バグがクライアントまたはサーバーのバグであるかどうか、およびバグが影響する範囲を問わず、バグにSTRIDEカテゴリを割り当てる必要があります。ユーザーは、ソフトウェア開発者およびQAスタッフになることができます。 STRIDEの略：
- なりすまし
- 改ざん
- 否認
- 情報開示
- サービスの拒否（DoS）
- 特権の昇格（EoP）
関連する「スコープ」値は次のとおりです。
- クライアント-スプーフィングされた信頼できるUI一般的な/デフォルトのシナリオ
- クライアント-特定の他のシナリオでのなりすましの信頼できるUI
- クライアント-より大きな攻撃シナリオの一部としてのなりすましのUI
- サーバー-なりすましの特定のユーザーまたは安全なプロトコルを介したコンピュータ
- サーバー-スプーフィングされたランダムユーザーまたは安全なプロトコルを介したコンピュータ
- クライアント-再起動後も存続する改ざんされた信頼できるデータ
- クライアント-改ざんされたデータ再起動後も持続しません
そこから、各組み合わせに重大度のレベルを割り当てるマトリックスが作成されます。重大度のレベルに指定できる値は次のとおりです。
- 重要
- 重要
- 中程度
- 低
- なし
マトリックス内のエントリの例（このようなエントリは複数存在する可能性があります）：
STRIDEカテゴリ：なりすまし
スコープ：クライアント-一般的な/デフォルトのシナリオでのなりすましの信頼できるUI説明：攻撃者が提示する機能デフォルト/一般的なシナリオで有効な信頼の決定を行うためにユーザーが依存しなければならないUIとは異なるが、視覚的には同一のUI。信頼の決定は、特定のエンティティ（システム、特定のローカルまたはリモートソース）によって情報が提示されているとユーザーが信じるアクションを実行するたびに定義されます。
重大度：重要
Microsoftは、展開する前に「低い」重要度よりも高いすべてのバグを修正すると主張しています。
参考資料
Microsoft Team Foundation Server2010にセキュリティバグバーを追加する
新しいSDLC：セキュリティ開発ライフサイクル