インシデント問題の管理

コンプライアンスの観点から、継続的統合および継続的コンプライアンスのパイプラインの一部としてインシデントの問題 (脆弱性、CVE) を作成、保管、および更新することは、証拠収集のために不可欠です。

エビデンスの収集を有効にした PR パイプライン、CI パイプライン、および CC パイプラインの実行中に、collect-evidence スクリプトはインシデント課題を作成し、収集したエビデンスに添付して、インシデント課題リポジトリに保存します。

collect-evidence スクリプトは、 cocoa incident process コマンドの機能を使用します。このコマンドは、提供されたスキャン結果を処理し、脆弱性ごとに提供されたリポジトリーに新しいインシデント問題を作成するか、サブジェクトとインシデントのペアに基づいて既存のインシデント問題を更新します。そのため、インシデントの問題は資産にバインドされ、特定のツールの結果に従って作成されます。詳しくは、 CI パイプラインと CC パイプラインでの問題処理の違いを参照してください。

PRパイプラインにおけるインシデント処理

証拠収集が有効になっているPRパイプラインは、脆弱性やCVEに遭遇したときにインシデント問題を発生させることができる。 PRパイプラインで証拠収集を有効にするには、PRパイプライン証拠収集を参照

PRパイプラインにおけるインシデントの課題管理は、CIパイプラインのそれと似ている。唯一の違いは、オートクローズのロジックにある。

PRパイプラインによって作成されたインシデントissueは、同じPR上で実行されているPRパイプラインによってのみオートクローズできます。この問題は、広報のパイプラインによって自己解決することはできない：

この問題は、他のPRで実行されているPRパイプラインによって発見される。
この問題は、CIやCCパイプラインによって発見される。

インシデントの問題の処理

CI パイプラインと CC パイプラインには共通のステップがありますが、これらのパイプラインの問題処理にはいくつかの相違点があります。

CI パイプライン中に作成されるインシデントの問題には期限はありませんが、CC パイプライン中に作成されるインシデントの問題にはあります。
CI パイプライン中に作成されたインシデントの問題はビルド中に検出され、CC パイプライン中に作成されたインシデントの問題は実稼働環境で検出されます。

図 1 から図 6 は、これらの違いに基づいて考えられるユース・ケースを示しています。

問題のライフサイクル

問題のライフサイクルは、コード PR から実動スキャンにまで及びます。

脆弱性ユースケースのフロー — 図1. DevSecOps/one パイプライン・ライフサイクル

ユース・ケース 1: ビルドで検出された脆弱性

新しいビルドでは脆弱性が発生しますが、これは受け入れられません。変更要求が手動で承認された緊急 CR でない限り、デプロイメントはブロックされます。

このビルド・パイプライン・フローでは、脆弱性が検出され、対応するユーザー・アクションが以下で説明されています。

ユース・ケース 2: 実動にも存在するビルドで検出された脆弱性

新規ビルドには、現在デプロイされている実動にも存在する脆弱性が含まれています。チームには問題を修正するためのタイムラインがありますが、新しい機能やフィックスは引き続きデプロイできます。

にも存在するビルドで検出された脆弱性

CC パイプラインは、実動で検出されたこのような脆弱性を修正するためのタイムラインを設定します。脆弱性を修正するタイムラインの有効期限が切れている場合にのみ失敗します。フローの概要を以下に示します。

ユース・ケース 2A: 実動で検出された脆弱性により、PR が許可されます

実動の脆弱性によって PR のマージが妨げられることはありません。

ユース・ケース 3: 誤検出

チームが問題を誤検出として分類する場合、その問題に 「免除」 のラベルを付けることができます。その後、この問題は非ブロッキング問題として処理できます。監査証跡を維持するために、変更要求は問題を表示したままにします。

ユース・ケース 4: 修正された問題を自動的に閉じる

CC パイプラインを定期的に実行すると、オープンしていて期限が設定されている問題がクローズされる可能性があります。また、関連する脆弱性がスキャンで見つかりません。

以下の図は、どの問題をクローズし、どの問題を新規に作成するかを検出する CC パイプラインのフローチャートを示しています。

CC パイプラインは、修正された問題を自動的にクローズします — 図 6. CC パイプラインが修正済みの問題を自動的にクローズする

インシデント問題の期限の設定

インシデントの問題が実動で見つかった場合は、 Due Date プロパティーを問題に追加して、問題を修正する必要がある猶予期間を指定することができます。猶予期間の期間は、検出された脆弱性の重大度によって決定されます。

猶予期間のカスタマイズについて詳しくは、 CC パイプラインでのカスタム猶予期間の構成を参照してください。

インシデント問題のラベル付け

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

Code Risk Analyzer によって検出されたインシデント問題のラベル

Code Risk Analyzer (CRA) は、アプリの依存関係やイメージの脆弱性など、複数のタイプの脆弱性を検出します。

脆弱性のタイプは、 name os、 python、 js、 golang、または java のいずれかです。

脆弱性のタイプが os の場合、 os-vulnerability ラベルが問題に付加されます。その他のタイプの脆弱性の場合は、 app-vulnerability ラベルが問題に付加されます。

使用可能なフィックスがあるインシデント問題のラベル

継続的統合 (CI) パイプラインまたは継続的コンプライアンス (CC) パイプラインによって作成されたインシデントの問題の場合、スキャナーは、スキャン結果の一部として修復情報を持っている可能性があります。修復情報が使用可能な場合は、 fix-available ラベルがインシデントの問題に追加され、問題の説明内の修正の説明へのリンクが示されます。

fix-available ラベルがないということは、すべてのスキャナーがスキャン結果に修正情報を含めるわけではないため、問題が対処可能ではないことを意味しません。スキャナーはフィックス情報を提示します。その情報は、スキャナーがこの「フィックス」データをソースとするすべての場所から取得されます。一部のスキャナーには、最新の「フィックス」辞書がないか、フィックスの情報が含まれていない可能性があります。

インシデントの問題 (期限あり)

collect-エビデンス・スクリプトを使用すると、インシデントの問題が作成され、収集されたエビデンスに添付されます。実動で問題が検出された場合は、デプロイメントがブロックされないように修正する必要がある期間を指定できます。実動中の問題を修正するために与えられる時間フレームは、 _猶予期間_と呼ばれます。ただし、読みやすくするために、期限をインシデントの問題で使用できるようになりました。これにより、ユーザーは、猶予期間から計算することなく、フィックスの期限を知ることができます。

実動で脆弱性や CVE などの問題が検出され、ビルドでも同じ問題が検出された場合でも、ビルドによって状況が悪化することはありません。この機能をデプロイすることができ、チームは実稼働環境での問題の修正に集中できます。

CC パイプラインでのカスタム猶予期間の構成

Continuous Compliance (CC) パイプラインは、問題の重大度に基づいてインシデント問題の期限を計算します。デフォルトの猶予期間値を変更して、カスタム値に置き換えることができます。

パイプラインは、以下の表に従って猶予期間を計算します。

表 1. デフォルトの猶予期間
重大度	猶予期間
情報	90 日間
低	45 日間
中	45 日間
高	15 日
重大	15 日

デフォルト構成を変更するには、CC パイプラインの環境プロパティーに grace-period-configuration という名前の新規プロパティーを作成します。この環境プロパティーは JSON ストリングでなければならず、以下の形式に一致する必要があります。

{
  "informational": 50,
  "low": 40,
  "medium": 30,
  "high": 20,
  "critical": 10
}

環境プロパティーが予期される形式に一致しないか、有効な JSON ストリングでない場合、パイプラインはデフォルト値を使用します。

環境プロパティー grace-period-configuration は、期限がまだ設定されていない問題の期限を設定します。期限が設定されている問題の場合、 grace-period-configuration を再構成しても、それらの期限は更新されません。

期限の計算

検出日は、継続的コンプライアンス (CC) パイプラインが実行され、実稼働環境で問題が検出された日付です。問題が存在する場合、CC はその時点から計算された期限を使用して問題を更新します。

<due date> = <date of finding the issue in prod> + <grace period in days (determined by severity)>

期限の形式

期限は ISO 8601 形式で、 YYYY-MM-DD と表示されます。

例: Due Date: 2022-04-01

ユース・ケース

CC パイプラインにより、実動の基本イメージの 1 つに脆弱性が検出されました。チームには、脆弱性の重大度に従って猶予期間が設定されたインシデントの問題が通知されます。猶予期間は、チームがフィックスをデプロイする必要がある日数です。
チームは、新しいフィーチャーを使用して新しいリリースを作成します。ビルドは、アプリケーションに使用される基本イメージに関連付けられた CVE を検出します。チームは CC パイプラインを手動で実行します。これにより、既に実動中の成果物がスキャンされます。手動 CC 実行では、実動の同じアプリケーションで同じ CVE が検出され、インシデントの問題に猶予期間が追加されます。これで、チームはブロックされることなくビルドとデプロイを行うことができます。

CI パイプラインと CC パイプラインでの問題処理の違い

インシデントの問題は、CI パイプラインと CC パイプラインの両方で作成されます。

CI で作成された問題は、ビルド中に検出されたことを意味します。
CC で作成された問題は、実稼働環境で検出されたことを意味します。

期限は、実稼働環境で検出された問題に関連している場合にのみ、問題に自動的に追加できます。これは、課題に期限を追加できるのは CC パイプラインのみであることを意味します。 CI が問題を検出し、期限が使用できない場合、期限の値は n/a です。

結果の問題への処理

検出された問題の問題は、特定のツールの結果に従って作成されます。 collect-evidence スクリプトは、添付ファイル内の結果ファイルを処理し、問題のリストを作成しようとします。

問題はアセットにバインドされます。アセットは、リポジトリー内のコミット、またはダイジェスト付きの Docker イメージの場合があります。

問題は問題 ID ごとに作成されます。問題 ID は以下のコンポーネントで構成されます。

バインド済み資産
脆弱性を検出したツール
脆弱性 ID (例えば、CVE ID)。

例えば、 CVE-2022-001 が 2 つの別個のツールによって検出された場合、このプロセスは今日、2 つの問題を作成します。

サポート対象のツール

現在、問題処理では以下のツールがサポートされています。

CRA
VA
ゴイセック
シークレットの検出
OWASP-ZAP API スキャナー
OWASP-ZAP UI スキャナー
SonarQube

サポートされないツールまたは結果の形式

collect-evidence スクリプトがサポートされないツールから添付ファイルを受信した場合、または処理中に結果のファイル形式が認識されない場合、スクリプトは問題の作成をスキップし、結果ファイルをエビデンスへの単純な添付ファイルとして使用します。

問題の内容

「問題」 は、問題または脆弱性の名前です。
「期限」 には、フィックスが期限になる日付が表示されます。期限がない場合は n/a が表示されます。
「サブジェクト」 は、問題がバインドされている資産です。
「URL」 は、アセットの正確なバージョンへのリンクです。
「ツール・タイプ」 は、問題の内容を生成したツールです。

Git Repos and Issue Trackingで作成された問題の場合、期限は、問題の説明ではなく、 GitLab のネイティブ期限フィールドに設定されます。

問題の説明には、問題が最初に検出されたときのタイム・スタンプが含まれています。例えば、 First found on 2022-04-07. The date is in YYYY-MM-DD format です。問題が発生した場所は、問題のコメントにリストされています。

インシデントの問題の期限を延期する

インシデントの問題の期限を延期する場合は、セキュリティー・フォーカルにレビューを依頼することができます。レビューに応じて、 Git Repos and Issue Tracking インシデントの問題のメタ・フィールドの Due date フィールドを変更することで、期限を延期できます。

Git Repos and Issue Trackingの期限の設定と更新 — 図 2. Git Repos and Issue Tracking

での期限の設定と更新

コメントでセキュリティー・フォーカル・レビューへのリンクを提供するなど、問題でセキュリティー・フォーカル・レビューを参照するようにしてください。

CC パイプラインの保留中の問題および期限切れの問題に対する Slack アラート

Continuous Compliance (CC) パイプラインは、インシデント問題の期限を設定できます。 Slack 統合が有効になっている場合、パイプラインは Slack を使用して、期限が近づいている問題や期限切れの問題をユーザーに通知することもできます。

詳しくは、継続的統合(CI)ツールチェーンのセットアップを参照してください。期限について詳しくは、 [Incident issues with due date](/docs/devsecops? topic = devsecops-incident-issues#devsecops-devsecops-issues-due-date) を参照してください。

通知される問題は、以下のように分類されます。

特定の時間フレーム内に保留中の期限がある問題: オープンしている問題、期限が設定されている問題、および時間フレーム内に期限が設定されている問題。
期限を過ぎている問題: 未完了の問題、期限がある問題、および日付が過ぎている問題。

時間フレームの期間は、 overdue、 due in 1 day、 due in 2 days、 due in 5 days、および due in 10 days です。

この機能の例を以下に示します。

Overdue issues:
- <issue url#1>
- <issue url#2>
- <issue url#3>

Issues due in 1 day:
- <issue url#4>

Issues due in 2 days:
- <issue url#5>

Issues due in 5 days:
- <issue url#6>
- <issue url#7>

Issues due in 10 days
- <issue url#8>
- <issue url#9>
- <issue url#10>
- <issue url#11>
- <issue url#12>

集計されたリストには、期限切れの問題が最初にリストされ、最も近い期限の問題が、それよりも後の期限の問題よりも前にリストされます。

CC パイプラインの cc-finish ステージは、基準に基づいて問題を照会し、Slack アラートをトリガーします。