スキャンエンジンの例外理由の構成

ServiceNow スキャンエンジン を使用して検出結果が検出されたときに、例外理由を適用、承認、および再評価する方法を設定します。

始める前に

リアルタイムの適用がオンの場合、警告およびエラーレベルの検出結果には、フォームを保存する前に承認済みの例外理由が必要です。推奨およびレビューレベルの結果はフォームの送信をブロックしません。

必要なロール:スキャンエンジンアドミン (sn_se.scan_engine_admin)

手順

1. 移動先 影響 > プラットフォームヘルス > スキャンエンジン > アドミニストレーション > プロパティ > 例外の理由.
   [例外の理由] の構成オプションが表示されます。
2. [ 却下された例外理由の検証を強制する] を設定して、適用動作を設定します。
   有効で例外理由が却下されると、検出結果が解決されるか、新しい例外理由が送信されるまで、リンクされたオブジェクトは読み取り専用になります。

   重要:

   本番インスタンスでは、このオプションを有効にします。

承認設定

3. [ 本番環境での承認を有効にする (Enable approvals in production)] を設定します。
   例外を本番インスタンスで承認できるか、または例外が発生した環境でのみ承認できるかを制御します。

   注:

   この設定は本番インスタンスにのみ適用されます。false に設定した場合、本番環境で発生した例外は、元の開発インスタンスまたは非本番インスタンスで承認される必要があります。
4. 承認グループを構成します。
   例外理由要求を承認または却下し、新しい要求が送信されたときに通知を受け取るグループを追加します。

   [ 承認グループ ] フィールドで、ラボ承認グループを選択します。

技術的負債の除外を有効にする

5. [ 承認された例外理由を技術的負債から除外する] を設定します。
   有効にすると、承認された例外理由を持つ検出結果が技術的負債メトリクスから除外されます。検出結果はシステムに残り、削除されません。

   注:

   このオプションを有効にします。

コントロールの再評価動作

6. 新しい検出結果が見つかった場合を設定します。
   後続のスキャンで同じ問題が検出されたときに、既存の承認済み例外理由をどのように処理するかを決定します。

   既存の理由を自動承認	既存の理由を再承認
   既存の承認理由は自動的に引き継がれます。再承認は必要ありません。	既存の理由は一時停止されており、再度有効になる前に再確認する必要があります。

7. セット 回線番号の変更時。

   検出結果の行番号がコード内で変更されたとき (リファクタリング後など) に、承認された例外理由をどのように処理するかを決定します。

   既存の理由を自動承認 (デフォルト)	既存の理由を再承認
   行番号がシフトしても、例外理由は承認されたままになります。マイナーなコード移動が予想される場合に使用します。	回線番号を変更する場合は再レビューが必要です。行の位置が例外コンテキストにとって意味がある場合に使用します。

8. [Save (保存)] を選択します。