セキュリティレビューフレームワーク

セキュリティレビューフレームワーク

[!WARNING] このプロセスは DRAFT であり、変更される可能性があります。セキュリティレビューのリクエストについては、AppSec レビュープロセス を使用してください。

このセキュリティレビューフレームワークは、GitLab のプロダクトチームがセキュリティ評価を効率化されたアプローチで実施できるようにし、機能のニーズ・リスクプロファイル・Go-to-market tier に基づいて適切なセキュリティパートナーと連携しやすくします。 開発速度を維持しつつ適切なセキュリティカバレッジを確保するように設計されており、フレームワークは最初にシンプルなチームルーティングプロセスを通じて、最も適切なセキュリティ専門家と直接つなげます。これは Secure Design and Development または Infrastructure Security のいずれかであり、High または Critical のリスクスコアを持つ機能については、Security Platforms and Architecture (SPA) や Data Security チーム からの追加の専門サポートも提供されます。この集中したアプローチにより、不要なプロセスのオーバーヘッドなく、タイムリーで的を絞ったセキュリティガイダンスを受けることができます。

セキュリティレビューフレームワークは、プロダクト開発フロー と連携して動作するように設計されています。 機能のセキュリティレビューを実施する理想的なトリガーポイントは設計フェーズです （Issue 上で workflow::design ラベルで示される Validation phase 4: Design）。 設計フェーズに関わる 主要参加者 は、セキュリティレビューフレームワークを活用して、機能にセキュリティレビューが必要かどうかを判断することが推奨されます。

SRF のスコープ

1. 機能のエンドツーエンドのセキュリティレビュー
2. 設計レビュー

ユースケース例

1. プロダクトデザイナーとして、新機能の設計がすべてのセキュリティのベストプラクティスを考慮していることを確認したい。
2. 新機能の実装に向けて潜在的な設計を作成している開発者として、その設計が顧客データの機密性や完全性の喪失につながらないか、または GitLab インスタンスの可用性に悪影響を及ぼさないかを確認したい。
3. エンジニアリングマネージャーとして、新機能の新しい設計をレビューしている際に、設計上の選択がセキュリティ上の問題を引き起こす可能性があると疑い、セキュリティチームに確認したい。
4. プロダクトマネージャーとして、GTM Tier-0 機能に取り組んでいる際に、その機能が顧客に対してセキュリティリスクをもたらさないことを確認したい。

以下の種類のリクエストは SRF のスコープ外です

1. アドホックな MR レビュー依頼（その機能がすでに SRF によりレビューされている場合を除く）
2. 一般的なアプリケーションセキュリティに関する質問

セキュリティレビューフレームワークがプロダクトチームのワークフローにどう適合するかを次のセクションで図示しています。

プロセス全体のフロー

flowchart TD

    A[Product team requests a feature review] -->B[Product team adds a `SecurityReview:Requested` on a feature issue/epic/mr]
    B --> C[ProdSec automation adds Initial Triage Questions in the feature issue and adds label `initial-triage:pending-answers`]
    C --> D[Product team fills the Initial Triage questions and removes pending label]
    D --> F{Team Routing logic}
    F --> |SD&D| G[ProdSec automation adds Risk Dimensions questionnaire']
    F --> |InfraSec| G[ProdSec automation adds Risk Dimensions questionnaire]
    F --> |InfraSec + SD&D | G[ProdSec automation adds corresponding Risk Dimensions questionnaire and label `risk-dimension:pending-answers`]
    G --> I[Product team fills Risk Dimensions questionnaire and remove pending labels]
    I --> J{Risk scoring}
    J --> |Critical Risk| K[Security review request created in ProdSec Ingestion Queue]
    J --> |High Risk| K[Security review request created in ProdSec Ingestion Queue]
    J --> |Medium Risk| L[Self Service]
    J --> |Low Risk| L[Self Service]
    F --> |No triggers| L
    L --> M[Issue created with self service guidelines]

フレームワークの目的

1. プロダクトセキュリティチームによるセキュリティレビューが必要な GitLab の機能を特定する。
2. プロダクトセキュリティチームから、どのタイプの セキュリティレビュー が必要か。
3. セキュリティレビューに関与する必要があるプロダクトセキュリティチーム。
4. プロダクトおよびエンジニアリングが、各種セキュリティレビューから期待できる成果物。

チームの責任

1: セキュリティチームのルーティング

最初のステップは、機能のセキュリティレビューに関与すべきセキュリティチームを判断することです。このルーティングは詳細なリスク評価の前に実施され、各チームが自分の領域に関連する質問のみに答えるようにします。

初期トリアージの質問

プロダクトチームが 機能 を開始する際、チームルーティングを判断するために初期トリアージを実施します。

Secure Design and Development トリガー

• この機能は顧客のリポジトリ、認証情報、PII データを扱いますか？(Y/N)
• この機能は認証、認可または暗号化に関連するコアメカニズムを追加または変更しますか？(Y/N)
• この機能はサードパーティサービスと連携しますか？(Y/N)
• この機能は 新しいサービスコンポーネント を追加しますか？(Y/N)
• この変更は認証、認可または暗号化に関連するコアメカニズムに間接的に影響しますか？(Y/N)

Infrastructure Security トリガー

• この機能は新しいクラウドインフラコンポーネントを必要としますか？(Y/N)
• この機能はコンテナ化やオーケストレーションの設定を変更しますか？(Y/N)
• この機能はネットワークアーキテクチャまたはセキュリティグループを変更しますか？(Y/N)
• この機能は Infrastructure-as-Code の実装を変更しますか？(Y/N)
• この機能は本番デプロイプロセスを変更しますか？(Y/N)
• この機能は新しいデータストア（例: クラウドストレージバケット、データベース、キャッシュ）を導入しますか？(Y/N)
• この機能はシークレット管理または認証情報処理を変更しますか？(Y/N)

チームルーティングロジック

これらのトリアージ質問への回答に基づき、システムはレビューを適切なチームにルーティングします:

IF ANY Secure Design and Development Trigger is YES
    THEN engage Secure Design and Development Team
IF ANY Infrastructure Security Trigger is YES
    THEN engage Infrastructure Security Team

複数の領域にまたがるトリガーを持つ複雑な機能では、複数のチームが関与する場合があります。

2: チーム別リスク評価モデル

関与すべきチームを特定した後、関与する各チームは領域固有のリスク評価を行ってレビューの深さを決定します。

Secure Design and Development リスク次元

Infrastructure Security リスク次元

詳細スコアリング基準

Secure Design and Development リスク次元

データ処理影響 (1-4)

• 4: 顧客リポジトリ、認証情報、PII データへの直接アクセス/変更。
• 3: 信頼されたコンポーネントから来るデータであっても、信頼されていないデータを処理する。
• 2: プロジェクト/パイプラインに関するメタデータへのアクセス。
• 1: 機密データへのアクセスがない、または表示のみの機能。

機能露出度 (1-5)

• 5: 認証なしでアクセス可能なパブリック向け API または Web インターフェース。
• 4: すべての認証済みユーザーに利用可能な機能。
• 3: 適切なロール権限が必要だが広く利用される機能。
• 2: 管理者専用機能、または特定のユーザーロールに限定される機能。
• 1: 顧客に公開されない内部ツール。

アーキテクチャ影響 (1-4)

• 4: コア認証、認可、またはシステムアーキテクチャの変更。
• 3: 現在のアプリケーションの信頼境界外にある新しいサービス（GitLab またはサードパーティ）統合。
• 2: 現在のアプリケーションの信頼境界内での機能追加。
• 1: バックエンドへの影響がない UI 変更。

実装複雑度 (2-3)

• 3: 新機能の実装。
• 2: 既存機能の拡張。

Launch Tier 影響 (0-3)

• 3: Tier 0
• 2: Tier 1
• 1: Tier 2
• 0: Tier 3

Note: Launch tier は GitLab tiers (Free/Premium/Ultimate) とは異なります。Launch tier は機能のローンチに伴うイベント/アナウンスの種類を示します。定義は この Google Sheet（社内）にあります。

Note: ~"group::[group-name]"、~"severity::1/2/3"、~"bug::vulnerability" ラベルの組み合わせを使ってプロジェクトの Issue トラッカーを検索することで、これを特定できます。

Infrastructure Security リスク次元

インフラスコープ (1-5)

• 5: 複数のプロダクト提供で使用される本番インフラに影響を与える。
• 4: 単一のプロダクト提供で使用される本番インフラに影響を与える。
• 3: 単一のプロダクト提供の本番インフラの一部で、顧客への影響が最小限の部分に影響を与える。
• 2: 他のシステムが依存する非本番インフラに影響を与える（例: 自動テスト環境）。
• 1: 他のシステムが依存しない非本番インフラに影響を与える（例: サンドボックス環境）。

環境クリティカリティ (1-5)

• 5: 顧客データを伴う本番環境コンポーネント。
• 4: 直接的な顧客データを伴わない本番環境コンポーネント。
• 3: プリプロダクション/ステージング環境。
• 2: テスト環境。
• 1: 開発環境のみ。

構成複雑度 (1-4)

• 4: 複数のサービスを伴う複雑な Infrastructure-as-Code。
• 3: いくつかの依存関係を伴う中程度のインフラ変更。
• 2: シンプルなインフラ変更。
• 1: 設定ファイル変更のみ。

自動化レベル (1-3)

• 3: 手動でのインフラ変更が必要。
• 2: 部分的に自動化されたインフラ変更。
• 1: 完全に自動化された Infrastructure-as-Code 実装。

Launch Tier 影響 (0-3)

• 3: Tier 0
• 2: Tier 1
• 1: Tier 2
• 0: Tier 3

Note: Launch tier は GitLab tiers (Free/Premium/Ultimate) とは異なります。Launch tier は機能のローンチに伴うイベント/アナウンスの種類を示します。定義は この Google Sheet にあります。

リスクスコアの計算

関与する各チームは、領域固有の次元を使用してリスクスコアを計算します:

Secure Design and Development Risk Score = Data Processing Impact + Feature Exposure + Architecture Impact + Implementation Complexity + Launch Tier Impact
Infrastructure Security Risk Score = Infrastructure Scope + Environment Criticality + Configuration Complexity + Automation Level + Launch Tier Impact

リスク分類

各チームは領域固有のスコアに基づいてリスクを分類します:

Secure Design and Development

• スコア ≥ 15: Critical Risk
• スコア 12-14: High Risk
• スコア 8-11: Medium Risk
• スコア < 8: Low Risk

各リスクレベルのセキュリティレビュープロセスは Secure Design and Development Review Process セクションで詳述されています。

Infrastructure Security

• スコア ≥ 15: Critical Risk
• スコア 12-14: High Risk
• スコア 8-11: Medium Risk
• スコア < 8: Low Risk

各リスクレベルのセキュリティレビュープロセスは Infrastructure Security Review Process セクションで詳述されています。

セキュリティレビューの優先度

セキュリティレビューの優先度は、機能の ロードマップ優先度（Interlock Priority::P1、Interlock Priority::P2、Interlock Priority::P3）と機能の リスクスコア を考慮して決定されます。

SPA および Data Security チームの関与基準

Secure Design and Development レビューについて

リスクスコア計算中に、大きなアーキテクチャ影響またはデータ処理影響が特定された場合、機能はアーキテクチャレビューおよび/またはデータセキュリティレビューにフラグ付けされます。

IF Architecture Impact >= 4
    THEN Flag the feature for Architecture review by SPA team
IF Data Processing Impact >= 4 then
    THEN Flag the feature for Data Security review by Data Security team.

InfraSec レビューについて

IF Infrastructure Scope >= 4
   THEN Flag the feature for SPA review
IF Environment Criticality>=4
   THEN Flag the feature for Data Security review

機能が SPA または Data Security レビューにフラグ付けされた場合、レビューリクエストに追加されたラベルでそれが示されます。

3: チームとリスクレベル別のレビュープロセス

Secure Design and Development レビュープロセス

• SDX Reviews DRI: SD&D チーム
• Data Security Review DRI: Data Security チーム。リソース制約があるため、このレビューはベストエフォートで実施されます。
• SPA Security Review DRI: SPA チーム。リソース制約があるため、このレビューはベストエフォートで実施されます。

[!WARNING] SDX Design review、SDX Code review、SDX Verify に記載されているステップは、 https://gitlab.com/groups/gitlab-com/gl-security/product-security/appsec/-/epics/75 の結果に基づいて変更される可能性があります。

Critical Risk レビュー

SDX Design review

• 脅威モデリング
  • DRI: SD&D
  • 成果物: 設計レベルのセキュリティ評価と特定された脅威を含む脅威モデル。
• 機能設計レビュー
  • DRI: SD&D
  • 成果物: 設計はベストプラクティスに照らして検証され、推奨事項が提供されます。
• SPA レビュー (IF Architecture Impact >= 4)
  • DRI: SPA
  • 成果物: システム設計、データフロー、アーキテクチャパターン、信頼境界、コンポーネント間の相互作用がベストプラクティスに照らして検証され、推奨事項が提供されます。
• Data Security レビュー (IF Data Processing Impact >= 4)
  • DRI: Data Security
  • 成果物: データアクセス制御、データインフラ、データライフサイクル、暗号化、鍵管理、サードパーティサービスがベストプラクティスに照らして検証され、推奨事項が提供されます。

SDX Code review

• マージリクエストレビュー
  • DRI: SD&D
  • 成果物: MR は実装レベルのセキュリティ問題についてレビューされます。
• Secure Coding Guidelines の遵守確認
  • DRI: SD&D
  • 成果物: Secure Coding Guidelines に従っているかをチェックするために MR がレビューされます。
• 静的解析
  • DRI: SD&D
  • 成果物: SD&D は Dependency scanning、Container Scanning ツール、および SAST tools を使用してソフトウェアコンポジション分析を実行します。

SDX Verify 最終セキュリティレビュー

• 動的解析
  • DRI: SD&D
  • 成果物: SD&D は DAST tools を使用して動的解析を実行します。
• 侵入テスト
  • DRI: SD&D
  • 成果物: SD&D は侵入テストを実行し、特定された問題を共有します。
• 発見された問題のチェック
  • DRI: SD&D
  • 成果物: 他のレビューで特定された重大な脆弱性が修正されているかチェックします。

High Risk レビュー

SDX Design review

• 変更にフォーカスした脅威モデリング
  • DRI: SD&D
  • 成果物: 設計レベルのセキュリティ評価と特定された脅威を含む脅威モデル。
• 変更にフォーカスした設計レビュー
  • DRI: SD&D
  • 成果物: 設計はベストプラクティスに照らして検証され、推奨事項が提供されます。
• SPA レビュー (IF Architecture Impact >= 4)
  • DRI: SPA
  • 成果物: システム設計、データフロー、アーキテクチャパターン、信頼境界、コンポーネント間の相互作用がベストプラクティスに照らして検証され、推奨事項が提供されます。
• Data Security レビュー (IF Data Processing Impact >= 4)
  • DRI: Data Security
  • 成果物: データアクセス制御、データインフラ、データライフサイクル、暗号化、鍵管理、サードパーティサービスがベストプラクティスに照らして検証され、推奨事項が提供されます。

SDX Code review

• マージリクエストレビュー
  • DRI: SD&D
  • 成果物: MR は実装レベルのセキュリティ問題についてレビューされます。
• Secure Coding Guidelines の遵守確認
  • DRI: SD&D
  • 成果物: Secure Coding Guidelines に従っているかをチェックするために MR がレビューされます。
• 静的解析
  • DRI: SD&D
  • 成果物: SD&D は Dependency scanning、Container Scanning ツール、および SAST ツールを使用してソフトウェアコンポジション分析を実行します。

SDX Verify 最終セキュリティレビュー

• 動的解析
  • DRI: SD&D
  • 成果物: SD&D は DAST tools を使用して動的解析を実行します。
• 侵入テスト
  • DRI: SD&D
  • 成果物: SD&D は侵入テストを実行し、特定された問題を共有します。
• 発見された問題のチェック
  • DRI: SD&D
  • 成果物: 他のレビューで特定された重大な脆弱性が修正されているかチェックします。

Medium Risk レビュー

セキュリティチェックリストの完了

• DRI: プロダクトチーム
• 成果物:
  • セキュリティ標準 が満たされているかチェックします。
  • Secure Coding Guidelines に従っているかチェックします。

自動セキュリティスキャン

• DRI: プロダクトチーム
• 成果物:
  • Dependency scanning、Container Scanning を使用したソフトウェアコンポジション分析で特定された問題を修正します。
  • SAST tools で特定された問題が有効化されていることを修正します。
  • DAST tools のようなツールを使用した動的解析で特定された問題を修正します。

Low Risk レビュー

セキュリティガイドラインに対する自己評価

• DRI: プロダクトチーム
• 成果物:
  • セキュリティ標準 が満たされているかチェックします。
  • Secure Coding Guidelines に従っているかチェックします。

自動セキュリティスキャン

• DRI: プロダクトチーム
• 成果物:
  • Dependency scanning、Container Scanning を使用したソフトウェアコンポジション分析で特定された問題を修正します。
  • SAST tools で特定された問題が有効化されていることを修正します。
  • DAST tools のようなツールを使用した動的解析で特定された問題を修正します。

レビュー SLO

これらは初期見積もりであり、フレームワークの採用に伴って変更される可能性があります。

Note: Low リスクレベルはここに記載されていません。プロダクトチームがそれらのレビューの DRI であるためです。

レビューはどの程度早く提出する必要があるか？

次のマイルストーン開始の少なくとも 10 暦日前に受け取ったレビューリクエストは、次のマイルストーンにスコープされます。

次のマイルストーン開始の 10 日前より遅く受け取ったリクエストは、マイルストーン+2 にスコープされます。

SLO は計画されたマイルストーンの開始日から開始されます。

Infrastructure Security レビュープロセス

Note: このセクションに記載されているレビューのリストは例であり、網羅的ではなく、また常に適用されるわけではありません。

• InfraSec Reviews DRI: InfraSec チーム
• Data Security Review DRI: Data Security チーム。リソース制約があるため、このレビューはベストエフォートで実施されます。
• SPA Security Review DRI: SPA チーム。リソース制約があるため、このレビューはベストエフォートで実施されます。

Critical Risk レビュー

• 共同のアーキテクチャおよびインフラレビュー
• 包括的なインフラセキュリティレビュー
• クラウド設定監査
• ネットワークセキュリティ分析
• コンテナセキュリティレビュー
• Infrastructure-as-Code セキュリティ分析
• 複数のセキュリティエンジニアが関与
• 実装後の検証
• タイムライン: TBD（機能の設計と実装の間にギャップが存在する可能性があるため、複数のマイルストーンにまたがる場合があります）

High Risk レビュー

• 共同のアーキテクチャレビュー
• 重点を絞ったインフラレビュー
• 主要設定の検証
• セキュリティグループ分析
• セキュリティアーキテクトとインフラセキュリティエンジニアの協働
• タイムライン: TBD（機能の設計と実装の間にギャップが存在する可能性があるため、複数のマイルストーンにまたがる場合があります）

Medium Risk レビュー

• インフラセキュリティチェックリストの完了
• 主要コンポーネントの設定検証
• タイムライン: 3〜5 営業日

Low Risk レビュー

• インフラセキュリティガイドラインに対する自己評価
• GitLab IaC scanning または Checkov を使用した自動設定チェック

例外ワークフロー

セキュリティレビューフレームワーク (SRF) はドライラン段階にあり、まだロールアウトされていないため、例外ワークフローは現時点で適用できません。SRF がロールアウトされた後、セキュリティレビューが機能リリースに対して必須となる前に、必要なセキュリティレビューを完了せずに機能をリリースするような状況をカバーするため、適切な 例外ワークフロー が SRF に追加されます。

4. 実装

セキュリティレビュー Phase 1: 初期トリアージ

1. セキュリティレビュープロセスは、プロダクトチームが機能のセキュリティレビューをリクエストすることから始まります。リクエストの理想的なタイミングは設計が準備できた 設計フェーズ です（設計フェーズの前に AppSec または InfraSec の質問がある場合は、それぞれ Contacting us と Working With Us に従ってください）。これは、機能の Issue または Epic (~"type::feature") にラベル SecurityReview::Requested を追加することで行われます。
2. ProdSec オートメーションは、この機能 Issue に初期トリアージのアンケートを追加し、レビュー開始者に完了を促し、ラベル initial-triage:pending-answers を追加します。初期トリアージのアンケート は、この機能が Secure Design and Development (SD&D, SPA) または InfraSec からのレビューが必要かどうかを判断するための Yes/No の質問のセットです。
3. Phase 1 のアンケートが完了したら、レビュー開始者は initial-triage:pending-answers ラベルを削除します。

セキュリティレビュー Phase 2: リスクスコアの決定

1. ProdSec オートメーションは、その後 Team Routing Logic を実行して、機能のセキュリティレビューを実施する必要があるチームを決定し、対応する Risk Dimensions のアンケートを機能 Issue に追加します。レビュー開始者は質問の完了を促され、ラベル risk-dimension:pending-answers も Issue に追加されます。
2. アンケートが完了したら、レビュー開始者は risk-dimension:pending-answers ラベルを削除します。
3. ProdSec オートメーションは、その後リスクスコアを計算し、レビュー種別と推奨タイムラインを決定します。続いて、ProdSec のインジェスチョンキューに ProdSec オートメーションによってセキュリティレビューリクエスト Issue が開かれます。

ProdSec インジェスチョンキューのセキュリティレビューリクエスト Issue には、以下の詳細が含まれ、ProdSec のインジェスチョントリアージプロセスがリクエストをチームメンバーにリダイレクトできます。

1. 初期トリアージのアンケートとその回答
2. Secure Design and Development リスク次元のアンケートとその回答
3. Infrastructure Security リスク次元とその回答（該当する場合）
4. Secure Design and Development リスクスコア
5. Infrastructure Security リスクスコア（該当する場合）
6. 推奨セキュリティレビュー種別
7. 推奨セキュリティレビューチーム (SD&D, SPA, InfraSec)

セキュリティレビュー Phase 3: セキュリティレビューの実施

リスクスコアに基づき、ProdSec は Critical、High、または Medium レベルのセキュリティレビューを実施します。

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