脆弱性の管理ポリシー
脆弱性ポリシーを使用して、組織のRulesAdminまたはAdminロールのある管理者が、ポリシーのトリガー時に脆弱性のステータスを変更したり、確認のためにフラグを立てる基準を定義することができます。ポリシーを定義する基準には、脆弱性のルール、深刻度、アプリケーション、ルートなどを指定できます。
組織のユーザとグループを使用している場合は、組織のRulesAdmin(ルール管理者)ロールまたは組織のAdmin(管理者)が必要です。
ロールベースのアクセス制御を使用している場合は、「組織の管理」アクションのあるロールが必要です。
脆弱性ポリシーによって、どの脆弱性に注意が必要であるか、またどの脆弱性が修復済みでクローズしたと見なされているかをより正確に把握できます。脆弱性の動作、自動検証ポリシー、違反ポリシー、および修復までの時間を設定するオプションがあります。
脆弱性がこれらのポリシーに違反する場合、アプリケーション内で通知するように設定できます。管理者には、Contrastアプリケーション内とEメールの両方で違反が通知されます。
脆弱性の動作
脆弱性の動作の設定を使用すると、ユーザが脆弱性をクローズしようとする際に管理者の承認が必要かどうかを決定できます。また、ユーザが脆弱性ステータスを「問題無し」に変更した時に、「上記以外」とは異なる理由のカスタムラベルを表示するように選択できます。
For organizations that require administrator approval to transition a vulnerability to certain states, you can now grant specific approval permissions to users without making them an Organization Admin. This allows for more granular control, enabling you to delegate the responsibility of vulnerability approval to specific teams or individuals.
You can also display a custom label for reasons other than Other when users change a vulnerability status to Not a Problem.
自動検証ポリシーのタイプ
自動検証ポリシーは、特定の条件を満たす脆弱性のステータスを自動的に修復済 - 自動検証に変更します。脆弱性の修正・検証後のステータス変更を手動で行うことに依存するのではなく、注意が必要な脆弱性のステータスをより正確に認識したい場合、自動検証ポリシーは便利です。
自動検証ポリシーのタイプには、セッションベース、ルートベース、または時間ペースがあります。
セッションベースの自動検証(推奨)： エージェントの設定ファイルに指定したメタデータ値の組み合わせによって、セッションを定義します。テストランの最後にContrast APIを呼び出すことで、セッション終了のタイミングを制御します。
このタイプの自動検証には、自動化されたテストスイートが必要です。
ルートベースの自動検証： エージェントの設定ファイルに指定したメタデータ値の組み合わせによって、セッションを定義します。セッションベースの自動検証を使用できない場合は、この自動検証タイプを使用して下さい。
Use this type of auto-verification if you cannot use session-based auto-verification.
このタイプの自動検証には、自動化されたテストスイートが必要です。
時間ベースの自動検証： 指定された期間内でアプリケーションの全てのルートを疎通できることが確実な場合は、この自動検証タイプを使用して下さい。
このタイプの自動検証では、自動テストまたは手動テストを利用できます。
自動検証の挙動
Contrastで、ある脆弱性が2つの異なるセッションに渡って同じルートで検出されない場合、この脆弱性は修復済 - 自動検証というステータスになります。2つのセッションで全く同じセッションメタデータ値が報告された場合、2つのセッションは1つの単独セッションとして見なされます。
定義した値に応じて、各エージェントの実行を単独のセッションの1部にすることもできますし、各エージェントの実行に独自のセッション情報を持たせることもできます。ContrastをCI/CDパイプラインに組み込んでいる場合は、 アプリケーションの新しいバージョンをデプロイするたびに、一意であるセッションメタデータのキーと値のペアを少なくとも1つ送信して下さい。例えば、コミットハッシュ(commitHash)やビルド番号(buildNumber)、バージョン(version)などのメタデータは、アプリケーションのデプロイごとに更新される場合が多いため、これらの値がエージェントから送信されるように設定すると良いです。
ルートベースの自動検証を使用する場合、ルートが疎通された直後にルートに関連する脆弱性が検査されます。また、セッションベースの自動検証を使用する場合、セッション終了のAPIが呼び出されるまで、セッション中に疎通されたすべてのルートの検査は待機状態となります。
疎通されたルートの脆弱性の観察中にアプリケーションで読み取られた脆弱なパラメータが再度報告されなかった場合にのみ、脆弱性はクローズされます。ルートが疎通されても、脆弱性で特定された特定のパラメータが汚染されたデータのソースとしてContrastで認識されない場合、脆弱性はオープンのままとなります。
Contrastで以前に修復済 - 自動検証のステータスにされた脆弱性が、同じルートを実行した際に再度検出された場合は、その脆弱性のステータスは報告済に変わります。その場合、脆弱性の詳細ページにある「アクティビティ」タブに情報が更新されます。
自動検証ポリシーを無効または削除した後に、Contrastで以前に修復済 - 自動検証のステータスにされた脆弱性が、同じルートを疎通した際に再度検出された場合は、その脆弱性のステータスは報告済に変わります。その場合、脆弱性の詳細ページにある「アクティビティ」タブに情報が更新されます。
セッションベースおよびルートベースの自動検証のためのセッションメタデータ
セッションベースまたはルートベースの脆弱性ポリシーには、エージェントの設定ファイルにセッションメタデータを追加して下さい。
一意のセッションメタデータを指定することによって、検出結果のベースラインができ、ルート比較に基づいて脆弱性が修復されたかどうかを検証できるようになります。
テストラン(testRun)のセッションメタデータフィールドを使用すると、テスト実行中にエージェントやアプリケーションを何度も再起動しても、1つのテスト実行内でのルートと脆弱性を確実に追跡できます。
Contrastでは、一意のメタデータのキーと値のペアごとに、一意のセッションIDが作成されます。この方法でセッションメタデータを使用すれば、複数のテスト実行が 1 つのテストセッションとして統合されます。この操作は、同じルートで異なるコードパスをテストする際などに便利です。
コミットハッシュ(commitHash)やビルド番号(buildNumber)、バージョン(version)などのメタデータは、アプリケーションのデプロイごとに値が更新される場合が多いため、利用すると便利です。
違反ポリシー
違反ポリシーは、脆弱性が特定の基準に一致した場合に、違反の通知をトリガーします。トリガーされると、脆弱性一覧で脆弱性が赤字で表示されます。脆弱性のフィルタを使用すると、ポリシー違反の脆弱性のみを表示できます。
ポリシーのトリガー
以下のトリガータイプが、脆弱性ポリシーに有効です。
セッションベース(推奨)： セッション中の特定のルートで、脆弱性が検出された場合、または検出されなかった場合に、自動検証ポリシーをトリガーします。このトリガーを使用する場合は、Contrast APIを使用してセッションを終了させます。この機能では、テストランの結果をすぐに取得できるよう、セッションの終了タイミングを定義できます。
ルートベース：特定のルートで、脆弱性が検出された場合、または検出されなかった場合に、自動検証ポリシーがトリガーされます。このトリガータイプは、Contrastがルート判定できるサポート対象のテクノロジで利用できます。
時間：指定した日数が経過すると、違反ポリシーまたは自動検証ポリシーがトリガーされます。
環境
最適な結果を得るためには、テストの自動化を行っている環境に脆弱性ポリシーを適用するよう設定します。複数のサーバで同じアプリケーションを実行している場合は、各サーバが開発、QAまたは本番環境用に設定されていることを確認してください。
複数ポリシーの処理
複数のポリシーが同じ脆弱性に影響を与える場合、以下のルールによってContrastの処理が決定されます。
自動検証ポリシーは、違反ポリシーよりも優先されます。例えば、最初に自動検証の期限が適用された場合、脆弱性はクローズされフラグは立てられません。
2つの時間ベースのトリガーが影響する場合は、期限が最も近い処理が先に適用されます。例えば、最初に違反期限が適用された場合、脆弱性にフラグが立てられ、後の期限が適用された時に脆弱性が自動検証されます。
修復までの時間
修復までの時間の設定では、Contrastダッシュボードの「修復までの平均時間」セクションにデフォルトのフィルタを指定できます。
Contrastダッシュボードには、組織の平均修復時間(ATTR)に関するデータが表示されます。これらのメトリクスを生成する際に、組織のプログラムの目標に応じて、脆弱性が最初に検出された日付、最後に検出された日付、またはクローズされた日付でフィルタリングすることを選択できます。
選択された時間枠に基づき、クローズされた脆弱性で、日付がフィルタ範囲内にある脆弱性が検索されます。選択された脆弱性に関して最初に検出された日とクローズされた日の差が調べられ、それらを平均化することでATTRがContrastで計算されます。