Application Security Testing, Composition Analysis

Composition Analysis

GitLab の Composition Analysis グループは、Container Scanning と Software Composition Analysis を行うソリューションの開発を担当しています。 グループが管理するプロジェクトの完全なリストを参照してください。

共通リンク

• Slack チャンネル: #g_ast-composition-analysis
• Slack エイリアス: @secure_composition_analysis_dev
• Google グループ: [email protected]

働き方

ワークフロー

Composition Analysis グループは主に GitLab のエンジニアリングワークフローとプロダクト開発フローに従っています。

これには以下が含まれます:

• Issue トリアージ
• Infradev トリアージ
• より広いコミュニティのマージリクエストトリアージ
• レトロスペクティブ

ステータスの表示とリスクの提起

Issue の進捗を伝えるために Issue のヘルスステータス機能を活用しています。

すべての Issue はマイルストーンの開始時に On Track としてマークされるべきです。これはエピック DRI、または未割り当てのスタンドアロン Issue の場合はエンジニアリングマネージャーが行います。

早期のリスク提起が重要です。時間があればあるほど、選択肢も多くなります。そのため、チームは毎週 Issue をレビューし、チームの優先事項に基づいて適切に修正し、リソースを再割り当てできるよう Need Attention または At Risk の項目を議論します。

リスクを上げたり下げたりする際はこれらの手順に従ってください:

1. Issue のヘルスステータスを更新します:
   1. On Track - 予定されたマイルストーン内に作業が完了する見込み。
   2. Needs Attention - Issue がブロックされているか、議論が必要な他の要因がある。
   3. At Risk - 予定されたマイルストーン内での納品締め切りを逃すリスクがある。
2. リスクが増加または減少した理由についてコメントを追加します。
3. エンジニアリングマネージャーとプロダクトマネージャーをコメントでコピーします。

休暇カレンダー

チームメンバーがいつ休暇を取るかを確認するために共有カレンダーを使用しています: c_629844cc273be17e067767febe12547bc40e129f26f0f17339030bff708cd0d5@group.calendar.google.com。

このカレンダーへのアクセスは Google グループ [email protected] を通じて付与されます。

休暇を共有するには:

1. Slack で Apps メニューの下にある Time Off by Deel アプリケーションを見つけてください。
2. Home で Your Events をクリックしてドロップダウンを表示してください。
3. Settings の区切りの下にある Calendar Sync をクリックしてください。
4. Additional calendars to include? の下にある Add calendar をクリックしてください。上記のカレンダー ID を使用してください。

カレンダーを表示するには:

1. Google カレンダーで、左サイドバーの Other calendars セクションを見つけてください。
2. ➕ アイコンをクリックして Subscribe to calendar を選択してください。上記のカレンダー ID を使用してください。

リアクションローテーション

開発ロードマップに加えて、エンジニアリングチームはセキュリティ脆弱性、サポート、メンテナンス、コミュニティコントリビューションに関連するタスクを実行する必要があります。

過度なコンテキストスイッチングを避け、ワークロードをより均等に分散するために、チームはマイルストーン計画の一部としてこれらのタスクのための容量を確保しています:

• プライマリエンジニア: 以下のタスクに完全に割り当てられます。セキュリティ、サポート、メンテナンスの順で、他のすべての作業よりこれらのタスクを優先する必要があります。
• セカンダリエンジニア: プライマリエンジニアが予定外の欠席や容量超過の場合のバックアップとして機能します。プライマリエンジニアからのリクエストを優先する必要がありますが、それ以外は type::maintenance Issue に集中します。

どちらのエンジニアも機能や重要な成果物の作業に割り当てるべきではありません。クロスファンクショナルマイルストーン計画のコンテキストでは、その割り当てはバグとメンテナンスの比率にカウントされます。

ローテーションスケジュールは、GitLab プロダクトマイルストーンの開始/終了日を使用した開発サイクルに従います。スケジュール作成時、エンジニアリングマネージャーはエンジニアが連続してローテーションを行う回数を最小限に抑えるよう努めるべきです。

ローテーション中に行っているアクションを追跡し、対応する Issue にメモを追加してください（例: ローカルで実行したツールコマンドのコピー、プロジェクトとプロセスへの関連する変更の共有など）。 この目的のために Reaction Rotation Issue テンプレートを使用できます。

ローテーション終了時に、@gitlab-org/secure/composition-analysis-dev/reaction-rotation の Owner として次のエンジニアを追加し、現在のエンジニアを削除します。このグループはスケジュールを調べることなく、ローテーション中のエンジニアにタグ付けするために使用されます。

責務 - セキュリティ

1. 私たちが管理するプロジェクトで報告された脆弱性をトリアージし、優先度に応じた解決を支援します。(セキュリティ脆弱性トリアージプロセスを参照)
2. SLA::Breached Issue を確認します。
3. セキュリティ自動化の失敗を確認します。
4. 依存関係の新しいセキュリティリリースを確認し、使用を確保します:
   1. アップストリームスキャナー（アップストリームスキャナーの更新を参照）
   2. コンテナベースイメージ
   3. アプリケーション依存関係
   4. プログラミング言語
5. スケジュールされたセキュリティ Issue をリファインします。
6. 自動化やツールの作成または更新を検討します（セキュリティ、メンテナーシップ、サポートに関連するもの！）

責務 - サポート

1. 質問、サポートリクエスト、アラートについて Slack チャンネルを監視します。他のチームメンバーもこれらのリクエストに応答する場合がありますが、リアクションローテーションに割り当てられたエンジニアが主に処理することが期待されます。 サポートエンジニアが Slack 経由でサポートを求め、調査やデバッグが必要な場合、Request for Help プロジェクトで Issue を起票するよう誘導してください。
   • #g_ast-composition-analysis
   • #s_application-security-testing
   • #sec-section
   • #s_ast-alerts
   • #f_container_scanning
   • #g_ast-composition-analysis-alerts
   • #f_operational_container_scanning
   • #sec-eng-requests-for-help
2. サポートリクエストについて Section Sec Request For Help プロジェクトを監視します。
3. スケジュールされたバグとメンテナンス Issue をリファインします。

これらの項目はマイルストーン全体を通じて継続的にトリアージされる必要があります。つまり、週に複数回確認する必要があります。

責務 - メンテナーシップ

1. コミュニティコントリビューターと連携してマージリクエストを完成に向けて進めます（コミュニティコントリビューショントリアージプロセスの詳細情報）。
2. License Alias Generator ツールを実行して既知のエイリアスのリストを更新します。手順はこちらで確認できます。このアクションはマイルストーン中に 1 回実行してください。
3. サポートしている言語やパッケージマネージャーの新しいバージョン、または同じものの廃止/削除のサポートを確認し、エンジニアリングマネージャーとプロダクトマネージャーに Issue で通知します。
4. 依存関係（セキュリティ関連でない）の新しいバージョンを確認します:
   1. アップストリームスキャナー（アップストリームスキャナーの更新を参照）。
   2. コンテナベースイメージ。
   3. アプリケーション依存関係。
   4. プログラミング言語。
5. テストの失敗を確認します。関連する Slack チャンネルを確認します（#g_ast-composition-analysis-alerts、#s_ast-alerts）。
6. リリース失敗について最新のパイプラインを確認します。自動リリースプロセスの実行を妨げる Issue がある場合は、リリース失敗エスカレーションプロセスを開始します。
7. 自動化やツールの作成または更新を検討します（セキュリティ、メンテナーシップ、サポートに関連するもの！）。
8. license-db プロジェクトの失敗とエラーを監視し、これらの項目に関するコミュニケーションには #f_licese_database Slack チャンネルを使用して、他のチームメンバーがサポートを提供できるようにします。
9. license-db インフラでのインシデントについて Slack チャンネル #g_ast-composition-analysis-alerts を監視します。 - インシデントが発生した場合、対応中であることを示すために 👁️ でリアクションしてください。 - 30 分以上経っても解決されない場合は調査してください。 - インシデントの Slack スレッドに解決のために取られたすべての手順を記録します。
10. Operational Container Scanning（OCS）とコンテナスキャンに関連するアラートについて Slack チャンネル #f_operational_container_scanning と #f_container_scanning を監視します。

引き継ぎ

1. リアクションローテーションは継続的なプロセスであるため、以下のテンプレートを使用してリアクションローテーション Issue に引き継ぎステータスを投稿してください:

---

**担当終了エンジニア:** [1 番目のリアクションローテーションエンジニア、2 番目のリアクションローテーションエンジニア]

**担当開始エンジニア:** [1 番目のリアクションローテーションエンジニア、2 番目のリアクションローテーションエンジニア]

---

#### **進行中のタスクと Issue**

1. **セキュリティタスク:**
   - **脆弱性:**
     - [Issue #1234](Issue へのリンク): 脆弱性の説明、現在のステータス、次のステップ。
   - **セキュリティ自動化の失敗:**
     - [Automation Job #9012](ジョブへのリンク): 失敗の説明、実施した初期トラブルシューティング手順、次のステップ。
   - **依存関係の更新:**
     - [Dependency Update #3456](更新へのリンク): 説明、現在のステータス、依存関係更新の次のステップ。

2. **サポートタスク:**
   - **サポートリクエスト:**
     - [Request #7890](リクエストへのリンク): 進行中のサポートリクエストの説明、現在のステータス、リクエスターとのコミュニケーション。
   - **Slack チャンネル監視:**
     - #g_ast-composition-analysis: 最近の議論のサマリー、未解決の質問、保留中のアクション。
     - #s_ast-alerts: 最近のアラートのサマリー、未解決の Issue、保留中のアクション。

3. **メンテナンスタスク:**
   - **コミュニティコントリビューション:**
     - [Merge Request #6789](MR へのリンク): コントリビューションの説明、現在のステータス、次のステップ。
   - **スケジュールされたバグとメンテナンス Issue:**
     - [Issue #3456](Issue へのリンク): Issue の説明、現在のステータス、次のステップ。

#### **追加メモ**

1. **次のエンジニアに関連する追加コンテキストまたはメモ:**
   - 追加メモ。

1. リアクションローテーショングループの所有権を新しいエンジニアに割り当てます。

セキュリティ脆弱性トリアージプロセス

私たちは 2 つのプロジェクトセットで報告された脆弱性のトリアージに責任を持ちます: GitLab が管理するプロジェクトと、依存する可能性があるアップストリームスキャナーソフトウェアです。ただし、状況に応じて異なるプロセスが適用されます。

Application Security Testing サブ部門の脆弱性管理プロセスを参照してください。

セキュリティポリシー

CVSS の深刻度と SLA によって検出結果に優先順位を付けます。Critical と High から始めますが、脆弱性に接続されていて SLA::Near Breach ラベルが付いている Issue も探してください。これらの脆弱性は CVSS スコアが低い場合がありますが、SLA 違反に達すると「期限超過」のセキュリティ Issue としてカウントされ、FedRAMP コンプライアンスに影響します。

確保した時間をすべて活用してください。Critical と High をすべて完了した場合は、トリアージを続けてください - すべての検出結果に対処したいですが、リスクベースの順序で取り組んでいます。

SLA::Near Breach Issue

脆弱性をトリアージする際、将来の SLA 違反を防ぐためにローテーションの一部として SLA::Near Breach Issueに注意を払うべきです。

SLA::Breached Issue

場合によっては、できるだけ早く対処する必要がある SLA::Breached Issue があるかもしれません。Tableau ダッシュボードでそれらの Issue の数を確認できます。SLA::Breached Issue は多くの理由で現れる場合があります:

• 優先度が与えられなかったために対処されなかった中程度または低程度の脆弱性。低い脆弱性でも、異なるソースからスコアを得る可能性があるため、severity::1 Issue につながる場合があることに注意してください。
• 関連する脆弱性が解決または却下されているにもかかわらず、クローズされない Issue。
• 修正できない脆弱性については、トリアージ後に適切な ~"risk treatment::" ラベルを適用します。これは修正の失敗と修正できないことを区別します。違反した脆弱性には標準の SLA 例外が適用されないため、リスク受け入れのガイダンスについて脆弱性管理チームに連絡してください。

Issue トラッカーで以下のラベルフィルターを使用して SLA::Breached Issue を検索できます:

• Severity 1
• Severity 2
• Severity 3
• Severity 4

Gemnasium 脆弱性

新しい Dependency Scanner アナライザーは FedRAMP をサポートしているため、Gemnasium は FedRAMP をサポートしなくなりました。したがって、SLA 例外プロセスに従う場合、すべての Gemnasium の脆弱性を non-FedRAMP findings として扱ってください。 プロセスの詳細については SLA 例外ハンドブックページを参照してください。

脆弱性のトリアージ

私たちのポリシーに一致し、関連プロジェクトで報告された項目に集中するためにフィルターを使用した脆弱性レポートを使用します。

1. Analyzers Vulnerability Report
   • レポートを手動で設定するには、すべての共有、コンテナスキャン、依存関係スキャンプロジェクトを選択し、Still detected アクティビティフィルターと Needs Triage ステータスを適用します。
2. License-db Vulnerability Report
   • レポートを手動で設定するには、すべての license-db プロジェクトを選択し、Still detected アクティビティフィルターと Needs Triage ステータスを適用します。

各項目について調査し、却下または確認します。確かな脅威があるか不明な場合は、アプリケーションセキュリティチームにエスカレートしてください。

各ステータスが何を意味するかわからない場合は、脆弱性ステータス定義を参照してください。

アップストリームスキャナーの脆弱性

これは GitLab がメンテナンスしていないプロジェクトにのみ適用されます。

新しいバージョンにアップグレードする際に、アップストリームスキャナーで検出された脆弱性をレビューします。アップストリームスキャナーを更新する際のセキュリティチェックセクションを参照してください。

私たちはアップストリームスキャナーで報告された脆弱性をトリアージする容量が限られています。これらのプロジェクトで報告された脆弱性の継続的なトリアージはベストエフォートで行われます。

脆弱性のトリアージ

私たちのポリシーに一致し、関連プロジェクトで報告された項目に集中するためにフィルターを使用した脆弱性レポートを使用します。

1. Upstream Scanners Vulnerability Report
   • レポートを手動で設定するには、すべてのアップストリームスキャナープロジェクトを選択します。

アップストリームスキャナーで発見された脆弱性については、GitLab の Issue トラッカーで Issue を作成し、関連するオープンソースコミュニティと連携して解決策を提供する必要があります。最後の手段として、脆弱性を早急に修正するために一時的にローカルでパッチを当てたり、アップストリームプロジェクトをフォークしたりすることができます。

脆弱性の却下

脆弱性が誤検知であることに疑いがない場合、FedRAMP イメージ（fips）に関連していない限り、「却下」できます。 脆弱性ステータスオプションから「却下」を選択します。 最後に、脆弱性ステータス変更通知にコメントして理由を説明してください。

却下できる低リスクの検出結果

CVSS での深刻度の一般的な設定方法と、自動スキャナーがアプリケーションのすべてのコンテキストを持っていないため、他の環境やシナリオでは高リスクでも、私たちのユーザーには低リスクな検出結果が多くあります。コンテナはユーザープロジェクトからのコードを取り込み、そのユーザーは開発者アクセス権を持っており、コンテナは一時的で特定のパイプラインに関連しています。

他のケースでは、検出結果がアップストリームの依存関係またはオペレーティングシステムに関連しており、修正が利用不可能で、修正の計画もない場合があります。blocked または blocked upstream ラベルを使用してこれらの Issue をマークしてください。

Issue が数リリースの間ブロックされており低リスクの場合、理由についてのメモとともに検出結果を却下することができます。関連する Issue がある場合は、アプリケーションセキュリティチームに特定の理由を通知して Issue をクローズします（該当する場合）。将来的には、これらの検出結果に関連するすべてのものを、クローズされる際に won’t fix または blocked としてタグ付けしたいと思いますが、現在は Issue でのみ利用可能で検出結果には適用されません。

以下のクラスのコンテナスキャン脆弱性は低リスクと考えられます:

• 開発者が制御する限られた入力を持つ一時コンテナを使用した私たちのプロセスのため、多くのカーネル関連の検出結果はリスクと深刻度が低下します。

• アナライザーに適用されないソフトウェアスタックに関連する Issue（例: GUI 関連の Issue、Bluetooth ドライバーの Issue、ブラウザが非ヘッドレスモードで実行されている場合に必要なブラウザ関連の Issue など）。

• 修正が利用不可能か、アップストリームがパッチをリリースする計画がないことを示している、複雑な悪用方法または限られたリスクを持つ S3 または S4 の検出結果。

• コンテナ/アナライザーのサービス拒否（これらのコンテナは一時的なパイプラインで実行され、タイムアウトに達すると自動的に停止され、すでに開発者アクセス権を持つユーザーからのコードを受け入れるため、結果的にリスクプロファイルの拡大にはなりません）。

• 乱数生成の Issue（数値がランダムでない場合）。コンテナからセキュリティ目的のために乱数を使用しないため。（これが最後に更新された時点ではこれらは真実でした。アナライザーの知識を使用するか、不明な場合は確認してください。）

  上記のリストに項目を追加するには、繰り返し発生する検出パターンをアプリケーションセキュリティと議論し、セキュリティセクションのリーダーからの承認を得て、このリストに追加してください。

脆弱性の確認

脆弱性が依存関係に影響する場合:

1. 依存関係（ソフトウェアライブラリ、システムライブラリ、ベースイメージなど）をアップグレードまたは削除できるか評価します。
2. 脆弱性ステータスを「確認済み」に設定します。
3. 依存関係のアップグレード/削除を含む新しいバージョンのアナライザーをリリースし、脆弱性の解決プロセスに従います。

他のすべての確認された脆弱性については、修正についての議論と追跡のためにセキュリティ Issue を作成してください。

脆弱性の解決

脆弱性が修正された場合、「解決済み」にできます。その際、どのように修正されたかをコメントし、脆弱性ステータスオプションから「解決」を選択し、関連する脆弱性 Issue をクローズします。

セキュリティ Issue の作成

残念ながら、脆弱性ページやセキュリティダッシュボードの「Issue 作成」ボタンから直接セキュリティ Issue を作成することはまだできません。これは、エラーが報告されたのと同じプロジェクトで Issue を作成する場合にのみ機能し、私たちのプロジェクトでは内蔵の Issue トラッカーを無効にしているためです。

代わりに、私たちのワークフローではすべての Issue をメインの GitLab プロジェクトで開きます。

回避策として、脆弱性ページのコンテンツをコピー＆ペーストできます（これにより Markdown 書式が維持されます！）。また、新しいセキュリティ Issue の作成に関するセキュリティガイドラインに従ってください。

必要なラベルを追加するためにクイックアクションを活用できます。

/confidential

/label ~security ~"type::bug" ~"bug::vulnerability"
/label ~"section::sec" ~"devops::application security testing" ~"group::composition analysis"

<!-- 影響を受けるプロジェクトに応じて: -->
/label ~"Category:Software Composition Analysis"
/label ~"Category:Container Scanning"

上記のように ~security と ~"bug::vulnerability" ラベルを追加することが重要です。AppSec Escalation Engine がこれらのラベルを持つすべての Issue を自動的に取り上げ、追加ラベル ~security-sp-label-missing と ~security-triage-psirt を追加し、AppSec トリアージダッシュボードで Issue に言及します。この時点で、安定したカウンターパートまたはアプリケーションセキュリティチームのトリアージ担当者が Issue を取り上げ、appsec トリアージローテーションの一環として深刻度を割り当てます。

Issue が作成されたら、追跡を容易にするために脆弱性のリンク項目に追加してください。

セキュリティ Issue を報告する開発者は、アプリケーションセキュリティチームが脆弱性の影響を評価するのを助け、Impact セクションで Issue の説明を更新する必要があります。

即時のフィードバックが必要な場合は、安定したカウンターパートセクションにリストされているセキュリティエンジニアの 1 人に @-メンションでコメントを追加するか、Slack でメッセージを送ってください。

リリース失敗プロセス

イメージリリースプロセスが失敗している場合、どのように検出、エスカレート、解決されたかを追跡するためのインシデントを作成する必要があります。インシデントを文書化することで、キーワード、ラベル、その他の Issue フィルターによって以前のインシデントを検索することが可能になります。すべてのインシデントはメインの GitLab プロジェクトで開きます。

1. 新しいインシデントを開き、問題の説明と再現手順を追加します。将来的に Composition Analysis に影響を与えたインシデントを追跡できるように、以下のラベルを追加します。

   <!--
   以下の深刻度の 1 つを選択
   参照: https://handbook.gitlab.com/handbook/product-development/how-we-work/issue-triage/#severity
   -->
   /label ~"severity::1"
   /severity S1
   
   /label ~"severity::2"
   /severity S2
   
   /label ~"severity::3"
   /severity S3
   
   /label ~"severity::4"
   /severity S4
   
   <!--
   以下の優先度の 1 つを選択
   参照: https://handbook.gitlab.com/handbook/product-development/how-we-work/issue-triage/#priority
   -->
   /label ~"priority::1"
   /label ~"priority::2"
   /label ~"priority::3"
   /label ~"priority::4"
   
   /label ~"section::sec" ~"devops::application security testing" ~"group::composition analysis" ~"type::bug" ~"bug::availability"
   
   <!--
   以下のカテゴリの 1 つを選択
   -->
   /label ~"Category:Dependency Scanning"
   /label ~"Category:Container Scanning"
   /label ~"Category:License Compliance"
   

2. インシデントをメンテナーシップリアクションローテーション中のエンジニアに割り当てます。

3. クイックアクションで関連する Issue や Zoom ミーティングをリンクしてインシデントのタイムラインイベントを記録します。インシデントの開始、検出、解決、およびインシデント対応の一部としてハイライトする価値があると思う他のイベントについてイベントが存在することを確認します。

4. Issue の修正時に、解決の詳細なサマリーと完了すべき初期フォローアップアクションを含めます。最後に、インシデントのエントリをグループ全体でレビューできるように、週次 Composition Analysis グループミーティングに追加します。

インシデントの例

• PHP Composer segfaults in gemnasium analyzer

メンテナンストリアージプロセス

エンジニアリングマネージャーがメンテナンス Issue を優先順位付けするのを支援するために、エンジニアリングチームは優先度ラベルを割り当てます。

1. メンテナンス Issue ボードを活用します。
2. 優先度ラベルのない各オープン Issue（「Open」カラム）について、Issue を短時間（1 時間未満）調査してコメントを付けます。私たちの作業タイプ分類（例: ~maintenance::refactor）に従って、正しいサブカテゴリラベルが適用されていることを確認します。

コードレビュー

Composition Analysis グループに参加すると、チームメンバーはグループが管理するすべてのプロジェクトのレビュアーまたはメンテナーになることが想定されます。メンテナーになるプロセスは、一般的なコードレビューガイドラインに説明されています。

プロジェクト

Composition Analysis グループはスキャン機能を提供するためにいくつかのプロジェクトを維持しています。

共有

• common ライブラリ

Dependency Scanning

• gemnasium アナライザー
• gemnasium-maven-plugin
• gemnasium-gradle-plugin
• dependency-scanning アナライザー
• 内部のみ gitlab-depscan

追加メモ:

• gemnasium-db は Vulnerability Research グループによって管理されています。

Container Scanning

• container-scanning アナライザー
• rhsa2ovaloracle: アナライザーが使用する Oracle アドバイザリを生成します。
• multiple-container-scanner

License-db

• advisory-processor
• deployment
• license-exporter
• license-feeder
• license-interfacer
• license-processor
• schema
• PMDB tools
• Static Reachability Modules Scraper

Operational Container Scanning

• trivy-k8s-wrapper
• OCS モジュール
• Cluster Image Scanning 関連コード
  • Operational Container Scanning 機能に必要です。

OCS モジュールは Environments グループが管理する gitlab-agent プロジェクトの一部です。Composition Analysis グループは OCS モジュールのみの管理に責任を持ちます。

Dependency Management

• orchestrator
• updater

Semver dialects gem

• semver_dialects

CI/CD コンポーネント

• Dependency Scanning
• Container Scanning

アップストリームスキャナーのミラー

一部のアナライザーはオープンソースソフトウェアに依存しているため、カバレッジを増やしリスクを軽減するためにセキュリティテストに含めています。

そのために、リポジトリをミラーし、関連するセキュリティスキャンを実行します:

• trivy
• trivy-db
• trivy-java-db
  • oras-mirror-config ブランチには registry.gitlab.com/gitlab-org/security-products/dependencies/trivy-java-db:1 イメージを最新状態に保つスケジュールパイプラインが含まれています。
• trivy-db-data
• trivy-db-glad
• vuln-list-update

現在使用しているバージョンのスキャナーで報告された脆弱性は、グループレベルの脆弱性レポートに自動的に報告され、セキュリティ脆弱性トリアージプロセスの一部としてトリアージされます。

ミラーの設定

1. https://gitlab.com/gitlab-org/security-products/dependencies に新しいプロジェクトを作成してください（空のプロジェクト）。
2. プロジェクトリポジトリをアップストリームリポジトリのプルミラーとして設定してください。
3. アナライザーが現在使用しているバージョンに一致する git タグを見つけてください（通常はアナライザーの Dockerfile の SCANNER_VERSION 変数で表されます）。使用しているリリースに対応する git タグがない場合は、正確なコミットを使用してください。
4. VERSION-security-checks という命名規則に従ったブランチを作成してください。VERSION は現在使用しているアップストリームスキャナーのバージョンです（例: v6.12.0）。
5. すべての互換性のあるセキュリティスキャンを設定するための .gitlab-ci.yml 設定ファイルを追加してください。
6. 報告された脆弱性がダッシュボードと脆弱性レポートに表示されるように、VERSION-security-checks をデフォルトブランチに設定してください。

アップストリームスキャナーの更新

アップストリームスキャナーの新しいリリースは月次で確認しており、リリース Issue の一部として行います。更新が利用可能な場合は、スキャナー更新 Issue テンプレートを使用して新しい Issue が作成され、次のマイルストーンに追加されます。

アップストリームツールとアナライザーのリスト

1. Trivy.
   1. Container Scanning
   2. Trivy K8S wrapper
2. OpenTofu
   1. Deployment
3. OpenTofu コンポーネント
   1. Deployment アップストリームスキャナーに依存するすべてのアナライザーには、"アップストリームスキャナーの更新方法" セクションがあり、プロセスを詳述しています。これには可能な新しいセキュリティ脆弱性の検証とライセンスチェックが含まれており、以下で詳述します。

アップストリームスキャナーを更新する際のセキュリティチェック

新しいバージョンのアップストリームスキャナーを含むアナライザーをリリースする前に、現在のポリシーに一致するセキュリティ脆弱性がないことを確認する必要があります。

1. 新しいタグ（またはコミット）をチェックアウトし、NEW_VERSION-security-checks という命名規則に従ったブランチを作成してください。
2. 現在の VERSION-security-check ブランチから既存の .gitlab-ci.yml 設定ファイルをコピー＆ペーストしてください。
3. 私たちのポリシーに一致する新しい検出結果がある場合は、トリアージプロセスに従って対処してください。
4. 上記の検出結果が修正された場合にのみ、NEW_VERSION-security-checks をデフォルトブランチに更新し、この新しいバージョンを使用するようにアナライザーの更新を進めてください。

アップストリームスキャナーを更新する際のライセンスチェック

新しいバージョンのアップストリームスキャナーを含むアナライザーをリリースする前に、そのライセンスが変更されていないか、私たちのポリシーと互換性があることを確認する必要があります。

FIPS ランナー

FIPS イメージをテストするために、独自のランナーインスタンスをホストしています。 VM インスタンスを sca-fips-runner- でフィルタリングすることで確認できます。新しいランナーをプロビジョニングする必要がある場合は、プロビジョニングスクリプトを使用して、含まれている指示に従ってください。

モニタリング

• Grafana 上のステージグループダッシュボード
• 継続的な脆弱性スキャン（gitlab.com の Rails プラットフォームでのバックグラウンド処理）
• Dependency Scanning SBOM スキャン API
• Dependency Scanning アナライザーメトリクス
• Multi Container Scanning メトリクス

関連リソース

• CA チームのコントローラー、API エンドポイント、Sidekiq ワーカー、データベーステーブルのリスト

ランブック

Composition Analysis ランブックページを参照してください。

Slack アラート

以下のテーブルは Slack アラートを生成できるさまざまな GitLab プロジェクトを示しています。 Sentry によって生成されるアラートは含まれていないことに注意してください。 Slack チャンネルの名前を変更した場合は、アラートが引き続き機能するようにプロジェクトのインテグレーションを更新してください。

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