適切に表現されたプロダクトセキュリティリスクガイド

GitLab で体系的なプロダクトまたはプラットフォームのセキュリティリスクを特定したと思われる場合、最初のステップは、適切に表現されたリスクの形で問題ステートメントを文書化することです。適切に表現されたリスクが文書化されて初めて、プロダクトセキュリティはトリアージ、評価、優先順位付け、対応のプロセスを開始できます。それらの下流のプロセスは、初期のリスク文書化のスコープ外です。

適切に表現されたリスクとは何か

適切に表現されたプロダクトセキュリティリスクは、次のことを明確に伝えます:

1. 問題ステートメント: GitLab（製品）を侵害にさらす、セキュリティ脆弱性、設計上の弱点、機能ロジックの問題、または機能ギャップの具体的かつ簡潔な説明。
2. 潜在的影響: リスクが対処されないままになった場合の GitLab および/またはその顧客への潜在的な被害の明確な説明（潜在的なビジネス影響、データ侵害シナリオ、サービスまたは運用の中断などを含む）。
3. 裏付けエビデンス: リスクが理論上のものではなく実在することを実証し、優先順位付けの判断材料となる具体的なトレンド、データポイント、または概念実証。
4. スコープと規模: リスクがどの程度広範囲に及ぶか、そして製品やインフラストラクチャのどの部分が影響を受けるかについての情報。

説明しているリスクが複雑な場合は、効果的に説明するためにフローチャートや図を含めることを検討してください。

最初にリスクを報告するとき、可能な解決策のアイデアがあるかもしれませんし、対処する必要のある課題やブロッカーをすでに知っているかもしれません。それは素晴らしいことです！適切に表現されたリスクを作成した後、それらを Issue にコメントとして追加してください。それらは下流のリスク対応計画プロセスに反映されます。

適切に表現されたリスクではないもの

1. 解決策ステートメント: 根本となるリスクを説明せずに「X 技術を実装する必要がある」または「Y 機能を構築する必要がある」とすること。
2. 機能リクエスト: 実際のセキュリティ露出に結び付けることなく、望ましい機能性を説明すること。
3. 個別の脆弱性: 特定の CVE やコンポーネントベースの脆弱性は別の場所に属します。
4. 曖昧または一般化された問題: 具体的な詳細なしに「私たちのセキュリティ態勢は弱い」とすること。

追加のガイダンス

初期リスクのドラフトに助けが必要な場合、セキュリティリスクチームによるこのリスクドラフトガイダンスを参照してください。あるいは、Slack の #security-spa でセキュリティプラットフォームとアーキテクチャチームに連絡してください。

ページのソースコードを見る - ページの編集 - please contribute.