問題のライフサイクル

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

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

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

脆弱性が発見された場合のこのビルド・パイプラインの流れと、それに対応するユーザー・アクションを以下の図で説明する。

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

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

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

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

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

ユースケース 3：誤検知と適用除外

チームが課題を「誤検知」として分類した場合、または脆弱性に関してセキュリティ上の例外が認められた場合、その課題には「 適用除外 」というラベルを付けることができます。 その後、この問題は非ブロッキング問題として処理できます。 監査証跡を維持するために、変更要求は問題を表示したままにします。

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

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

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

よくある支払期日のケース

以下のシナリオでは、期日の管理方法について説明します

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

期限の計算

検出日は、継続的コンプライアンス (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 つの問題を作成します。

期限延長の手続き

1. セキュリティ担当者に、延長が必要な理由を説明した上で、再検討を依頼してください。
2. 承認を受けたら、期限日を更新してください：
   • Git Repos and Issue Tracking の場合：インシデントのメタデータフィールドにある「 Due date 」フィールドを変更してください。
   • GitHub Enterprise の場合：課題の説明文にある「 Due date 」フィールドを編集してください。
3. その課題について、セキュリティ担当者の承認を参照し、レビューまたは承認文書へのリンクを記載したコメントを追加してください。

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

セキュリティ例外

セキュリティ上の例外に関する問題がある場合は、その例外の有効期限に合わせて期限を延長することができます。 これにより、例外が失効するまで、証拠の収集とコンプライアンス状況の追跡が適切に継続されることが保証されます。