脆弱性の管理ポリシー
脆弱性ポリシーを使用して、組織のRulesAdminまたはAdminロールのある管理者が、ポリシーのトリガー時に脆弱性のステータスを変更したり、確認のためにフラグを立てる基準を定義することができます。ポリシーを定義する基準には、脆弱性のルール、深刻度、アプリケーション、ルートなどを指定できます。
脆弱性ポリシーによって、どの脆弱性に注意が必要であるか、またどの脆弱性が修復済みでクローズしたと見なされているかをより正確に把握できます。自動検証ポリシーと違反ボリシーを設定できます。
脆弱性がこれらのポリシーに違反する場合、アプリケーション内で通知するように設定できます。管理者には、Contrastアプリケーション内とEメールの両方で違反が通知されます。
自動検証ポリシーのタイプ
自動検証ポリシーは、特定の条件を満たす脆弱性のステータスを自動的に修復済 - 自動検証に変更します。脆弱性の修正・検証後のステータス変更を手動で行うことに依存するのではなく、注意が必要な脆弱性のステータスをより正確に認識したい場合、自動検証ポリシーは便利です。
自動検証ポリシーのタイプには、セッションベース、ルートベース、または時間ペースがあります。
セッションベースの自動検証(推奨)： エージェントの設定ファイルに指定したメタデータ値の組み合わせによって、セッションを定義します。テストランの最後にContrast APIを呼び出すことで、セッション終了のタイミングを制御します。
このタイプの自動検証には、自動化されたテストスイートが必要です。
ルートベースの自動検証： エージェントの設定ファイルに指定したメタデータ値の組み合わせによって、セッションを定義します。セッションベースの自動検証を使用できない場合は、この自動検証タイプを使用して下さい。
このタイプの自動検証には、自動化されたテストスイートが必要です。
時間ベースの自動検証： 指定された期間内でアプリケーションの全てのルートを疎通できることが確実な場合は、この自動検証タイプを使用して下さい。
このタイプの自動検証では、自動テストまたは手動テストを利用できます。
自動検証の動き方
Contrastで、ある脆弱性が2つの異なるセッションに渡って同じルートで検出されない場合、この脆弱性は修復済 - 自動検証というステータスになります。2つのセッションで全く同じセッションメタデータ値が報告された場合、2つのセッションは1つの単独セッションとして見なされます。
定義した値に応じて、各エージェントの実行を単独のセッションの1部にすることもできますし、各エージェントの実行に独自のセッション情報を持たせることもできます。ContrastをCI/CDパイプラインに組み込んでいる場合は、 アプリケーションの新しいバージョンをデプロイするたびに、一意であるセッションメタデータのキーと値のペアを少なくとも1つ送信して下さい。例えば、コミットハッシュ(commitHash)やビルド番号(buildNumber)、バージョン(version)などのメタデータは、アプリケーションのデプロイごとに更新される場合が多いため、これらの値がエージェントから送信されるように設定すると良いです。
Contrastで以前に修復済 - 自動検証のステータスにされた脆弱性が、同じルートを実行した際に再度検出された場合は、その脆弱性のステータスは報告済に変わります。その場合、脆弱性の詳細ページにある「アクティビティ」タブに情報が更新されます。
自動検証ポリシーを無効または削除した後に、Contrastで以前に修復済 - 自動検証のステータスにされた脆弱性が、同じルートを疎通した際に再度検出された場合は、その脆弱性のステータスは報告済に変わります。その場合、脆弱性の詳細ページにある「アクティビティ」タブに情報が更新されます。
セッションベースおよびルートベースの自動検証のためのセッションメタデータ
セッションベースまたはルートベースの脆弱性ポリシーには、エージェントの設定ファイルにセッションメタデータを追加して下さい。
一意のセッションメタデータを指定することによって、検出結果のベースラインができ、ルート比較に基づいて脆弱性が修復されたかどうかを検証できるようになります。
テストラン(testRun)のセッションメタデータフィールドを使用すると、テスト実行中にエージェントやアプリケーションを何度も再起動しても、1つのテスト実行内でのルートと脆弱性を確実に追跡できます。
Contrastでは、一意のメタデータのキーと値のペアごとに、一意のセッションIDが作成されます。この方法でセッションメタデータを使用すれば、複数のテスト実行が 1 つのテストセッションとして統合されます。この操作は、同じルートで異なるコードパスをテストする際などに便利です。
コミットハッシュ(commitHash)やビルド番号(buildNumber)、バージョン(version)などのメタデータは、アプリケーションのデプロイごとに値が更新される場合が多いため、利用すると便利です。
違反ポリシー
違反ポリシーは、脆弱性が特定の基準に一致した場合に、違反の通知をトリガーします。トリガーされると、脆弱性一覧で脆弱性が赤字で表示されます。脆弱性のフィルタを使用すると、ポリシー違反の脆弱性のみを表示できます。
ポリシーのトリガー
以下のトリガータイプが、脆弱性ポリシーに有効です。
セッションベース(推奨)： セッション中の特定のルートで、脆弱性が検出された場合、または検出されなかった場合に、自動検証ポリシーをトリガーします。このトリガーを使用する場合は、Contrast APIを使用してセッションを終了させます。この機能では、テストランの結果をすぐに取得できるよう、セッションの終了タイミングを定義できます。
ルートベース：特定のルートで、脆弱性が検出された場合、または検出されなかった場合に、自動検証ポリシーがトリガーされます。このトリガータイプは、Contrastがルート判定できるサポート対象のテクノロジで利用できます。
時間：指定した日数が経過すると、違反ポリシーまたは自動検証ポリシーがトリガーされます。
環境
最適な結果を得るためには、テストの自動化を行っている環境に脆弱性ポリシーを適用するよう設定します。複数のサーバで同じアプリケーションを実行している場合は、各サーバが開発、QAまたは本番環境用に設定されていることを確認してください。
複数ポリシーの処理
複数のポリシーが同じ脆弱性に影響を与える場合、以下のルールによってContrastの処理が決定されます。
自動検証ポリシーは、違反ポリシーよりも優先されます。例えば、最初に自動検証の期限が適用された場合、脆弱性はクローズされフラグは立てられません。
2つの時間ベースのトリガーが影響する場合は、期限が最も近い処理が先に適用されます。例えば、最初に違反期限が適用された場合、脆弱性にフラグが立てられ、後の期限が適用された時に脆弱性が自動検証されます。