インシデントおよび非インシデントの問題の処理

課題へのデフォルトの割り当て対象者の追加

incident-assignees パイプライン・パラメーターを使用して、問題に対して複数のデフォルト割り当て対象者を定義できます。 incident-assignees パラメーターは、 GitHub アカウントおよび GitLab プレミアム・アカウントでのみ使用できます。 incident-assignees パラメーターについて詳しくは、 ユーザーへの問題の割り当て を参照してください。

incident-assignee パイプライン・パラメーターを使用して、パイプラインのデフォルトの問題割り当て対象者を設定することもできますが、このパラメーターは非推奨になり、 v1 エビデンス (レガシー) コレクションで削除されます。

問題のフィルタリング

デフォルト・ラベルとカスタム・ラベルを使用して、問題をフィルタリングおよび検索できます。 作成時または更新時に、以下のデフォルト・ラベルが問題に割り当てられます。

• 問題処理に使用される スキャン・タイプ が、ツール・ラベル ( tool:cra、 tool:va、 tool:sonarqube など) としてインシデント問題に追加されます。
• 重大度ラベルは、問題にも割り当てられます。 重大度カテゴリーは、スキャン結果に基づいて定義され、 severity:critical、 severity:high、 severity:medium、 severity:low、 severity:informational のいずれかになります。
• has-exempt は、問題がスキャン結果に基づいて免除される場合に問題に割り当てられる VA ツール固有のラベルです。 exempt ステータスがスキャン結果に含まれていない場合は、 exempt ラベルを割り当て、免除された問題チケットのソースへのリンクをコメントに追加することで、問題を手動で免除できます。 詳しくは、 免除 を参照してください。 問題に exempt のマークが付けられている場合は、CI パイプラインを再実行します。 そうしないと、パイプラインは新しい証拠を生成しません。

incident-labels パイプライン・パラメーターを使用して、問題のデフォルト・ラベルを追加することもできます。 詳しくは、 問題のラベル付け を参照してください。

Git Repos and Issue Tracking での検索

Git Repos and Issue Trackingを使用する場合、UI でさまざまな方法で問題を検索できます。 例えば、タイトル、本文、またはコメントのテキストでフィルターに掛けることができます。 任意のラベルでフィルタリングすることもできます。

詳しくは、以下の資料を参照してください。

• GitLabでの検索の方法。
• GitHubで検索する方法。

問題のラベル付け

継続的統合 (CI) または継続的コンプライアンス (CC) パイプラインによって作成された問題には、デフォルト・ラベルを付けることができます。

スキャン・ツールによって作成される問題には、デフォルトの severity ラベルが含まれます。 重大度レベルは、 informational、 low、 medium、 high、または critical です。 ラベルの例は、 severity:informational、 severity:low、 severity:medium、 severity:high、または severity:critical です。 スキャン・ツールに重大度情報がない場合は、デフォルトの severity:high ラベルが問題に付加されます。

問題のデフォルト・ラベルを設定するには、 incident-labels 環境プロパティーを、コンマで区切られた 1 つ以上のラベルに設定します。 例えば、 First-Label または First-Label,Second-Labelなどです。

パイプラインは、 collect-evidence スクリプトによって作成された問題にこれらのラベルを関連付けます。

トリガーごとにこの環境プロパティーを定義して、各トリガーが異なるユーザーを割り当てることができるようにすることができます。

ユーザーへの問題の割り当て

継続的統合 (CI) または継続的コンプライアンス (CC) パイプラインによって作成される問題には、デフォルトの割り当て対象者を設定できます。

デフォルトの割り当て対象者を割り当てるには、 incident-assignees 環境プロパティーを、コンマで区切られた 1 つ以上のユーザー名に設定します。 例えば、 First-User または First-User,Second-Userなどです。 incident-assignees 環境プロパティーについて詳しくは、 パイプライン・パラメーター を参照してください。

パイプラインは、これらのユーザー名を使用して、 collect-evidence スクリプトによって作成されたインシデントの問題にそれらを割り当てます。 ユーザー名が無効な場合、割り当ての失敗に関する警告がログに記録されますが、エビデンス収集は成功します。

トリガーごとにこの環境プロパティーを定義して、各トリガーが異なるユーザーを割り当てることができるようにすることができます。

免除

問題に永久に免除のマークを付ける場合は、 exempt ラベルを問題に追加して、問題がデプロイメントをブロックしないようにします。 ただし、デプロイメントの変更要求には引き続き問題が表示されます。 ベスト・プラクティスとして、免除のソース (例えば、問題チケット) をコメント内の問題にリンクして、問題が免除される理由をレビューアーが理解できるようにします。 免除ラベルを持つ問題は、永続的にオープンされます。

カスタム・ラベルを使用して永続的に免除された問題にマークを付ける場合は、そのラベルを問題に追加してから、カスタム・ラベルと同じ値を使用して custom-exempt-label オプション・パラメーターを CI および CC パイプラインに追加します。

問題に免除のマークが付けられている場合は、CI パイプラインを再実行する必要があります。 それ以外の場合は、新しい証拠は生成されません。

問題管理のベスト・プラクティス

スキャン・ツールは、特定の問題を隠蔽する可能性があるリスト機能を除外または無視します。 これらの関数は、アプリケーション・コード内の無視リストを埋めることによって適切なリスク管理手順をバイパスするため、これらの関数を使用することは推奨されません。 無視リストは、セキュリティー・フォーカルの制御外にある可能性があります。 その代わりに、 DevSecOps CI、CD、CCパイプラインを使用して、 Git の問題における逸脱とインシデントを自動的に追跡することにより、セキュリティとコンプライアンスのリスクを管理する。 パイプラインは、免除、期限、割り当て対象者、およびラベルも収集します。これは、問題を透過的に管理するためのベスト・プラクティスです。