スキャン実行ポリシー

スキャン実行ポリシーは、デフォルトまたは最新のセキュリティCI/CDテンプレートに基づいてGitLabのセキュリティスキャンを適用します。スキャン実行ポリシーは、パイプラインの一部として、または指定されたスケジュールでデプロイできます。

スキャン実行ポリシーは、セキュリティポリシープロジェクトにリンクされているすべてのプロジェクトにわたってセキュリティスキャンを適用します。.gitlab-ci.ymlファイルがないプロジェクト、またはAutoDevOpsが無効になっているプロジェクトの場合、セキュリティポリシーは暗黙的に.gitlab-ci.ymlファイルを作成します。.gitlab-ci.ymlファイルは、シークレット検出、静的な解析、またはプロジェクトでのビルドを必要としないその他のスキャナーを実行するポリシーが常に実行され、適用されることを保証します。

スキャン実行ポリシーとパイプライン実行ポリシーはどちらも、複数のプロジェクトにわたってGitLabセキュリティスキャンを設定し、セキュリティとコンプライアンスを管理できます。スキャン実行ポリシーは設定するのがより高速ですが、カスタマイズはできません。以下のいずれかのユースケースに該当する場合は、代わりにパイプライン実行ポリシーを使用してください:

• 高度な設定が必要です。
• カスタムCI/CDジョブまたはスクリプトを適用したい場合。
• 適用されたCI/CDジョブを通じてサードパーティのセキュリティスキャンを有効にしたい場合。

スキャン実行ポリシーを作成する

スキャン実行ポリシーを作成するには、以下のいずれかのリソースを使用できます:

• ビデオウォークスルーについては、GitLabでセキュリティスキャンポリシーを設定する方法を参照してください。
• GitLab CI/CDの設定がないプロジェクトへのスキャン実行ポリシーの適用について詳しくはこちら。
• スキャン実行ポリシーの作成方法については、チュートリアル: スキャン実行ポリシーの設定を参照してください。

制限事項

• 各ポリシーには最大5つのルールを割り当てることができます。
• 各セキュリティポリシープロジェクトには、最大5つのスキャン実行ポリシーを割り当てることができます。
• ローカルプロジェクトのYAMLファイルはスキャン実行ポリシーをオーバーライドできません。スキャン実行ポリシーは、プロジェクトのCI/CD設定で同じジョブ名を使用している場合でも、パイプライン用に定義されたすべての設定よりも優先されます。
• スケジュールされたポリシー（type: schedule）は、スケジュールされたcadenceにのみ従って実行されます。ポリシーを更新しても、即時スキャンはトリガーされません。
• ポリシーの更新をYAML設定ファイルに直接行う場合（ポリシーエディタではなくコミットまたはプッシュで）、システムに伝播するまでに最大10分かかることがあります。（この制限に対する提案された変更については、イシュー512615を参照してください。）

ジョブステージ

DASTスキャンは常にdastステージで実行されます。dastステージが存在しない場合、GitLabはパイプラインの終わりにdastステージを挿入します。

他のすべてのスキャンのポリシージョブは、パイプラインのtestステージで実行されます。testステージをデフォルトのパイプラインから削除した場合、ジョブは以下のルールに従って代わりにscan-policiesステージで実行されます:

• scan-policiesステージがまだ存在しない場合、GitLabは評価時にそのステージをCI/CDパイプラインに挿入します。
• buildステージが存在する場合、GitLabはbuildステージの直後にscan-policiesを挿入します。
• buildステージが存在しない場合、GitLabはパイプラインの最初にscan-policiesを挿入します。

ジョブ名の競合を避けるため、ジョブ名にハイフンと数字が追加されます。各数字は、各ポリシーアクションの一意の値です。例えば、secret-detectionはsecret-detection-1になります。

スキャン実行ポリシーエディタ

スキャン実行ポリシーエディタを使用して、スキャン実行ポリシーを作成または編集します。

前提条件:

• デフォルトでは、グループ、サブグループ、またはプロジェクトのオーナーのみが、セキュリティポリシープロジェクトを作成または割り当てるために必要な権限を持っています。あるいは、セキュリティポリシーリンクを管理する権限を持つカスタムロールを作成できます。

最初のスキャン実行ポリシーを作成する際は、一般的なユースケースのためにこれらのテンプレートから選択してください:

• マージリクエストセキュリティ
  • ユースケース: マージリクエストが作成されたときのみ、すべてのコミットではなく、セキュリティスキャンを実行したい場合。
  • 使用時期: デフォルトまたは保護ブランチをターゲットとするソースブランチでセキュリティスキャンを実行する必要があるマージリクエストパイプラインを使用するプロジェクト向け。
  • 最適な用途: マージリクエスト承認ポリシーに合わせ、すべてのブランチでスキャンを回避することでインフラストラクチャコストを削減する。
  • パイプラインソース: 主にマージリクエストパイプライン。
• スケジュールスキャン
  • ユースケース: コードの変更に関わらず、セキュリティスキャンをスケジュール（毎日または毎週など）で自動的に実行したい場合。
  • 使用時期: 開発活動とは無関係に、定期的なケイデンスでセキュリティスキャンを実行する場合。
  • 最適な用途: コンプライアンス要件、ベースラインセキュリティモニタリング、またはコミットがinfrequentなプロジェクト。
  • パイプラインソース: スケジュールされたパイプライン。
• リリースセキュリティ
  • ユースケース: mainまたはリリースブランチへのすべての変更に対してセキュリティスキャンを実行したい場合。
  • 使用時期: リリース前、または保護ブランチでの包括的なスキャンが必要なプロジェクト向け。
  • 最適な用途: リリースでゲートされたワークフロー、本番環境へのデプロイ、または高セキュリティ環境。
  • パイプラインソース: 保護ブランチへのプッシュパイプライン、リリースパイプライン。

利用可能なテンプレートがニーズに合わない場合、またはよりカスタマイズされたスキャン実行ポリシーが必要な場合は、以下を行うことができます:

• カスタムオプションを選択し、カスタム要件を持つ独自のスキャン実行ポリシーを作成します。
• パイプライン実行ポリシーを使用して、セキュリティスキャンおよびCIの適用に関するよりカスタマイズ可能なオプションにアクセスします。

ポリシーが完成したら、エディタの下部にあるマージリクエスト経由で設定を選択してポリシーを保存します。プロジェクトの設定されたセキュリティポリシープロジェクトにあるマージリクエストにリダイレクトされます。セキュリティポリシープロジェクトがプロジェクトにリンクされていない場合、GitLabが自動的に作成します。エディタの下部にあるポリシーの削除を選択することで、エディタインターフェースから既存のポリシーを削除できます。このアクションにより、policy.ymlファイルからポリシーを削除するためのマージリクエストが作成されます。

ほとんどのポリシー変更は、マージリクエストがマージされるとすぐに有効になります。マージリクエストを介さずにデフォルトブランチに直接コミットされた変更は、ポリシー変更が有効になるまでに最大10分かかります。

スキャン実行ポリシースキーマ

スキャン実行ポリシーを持つYAML設定は、スキャン実行ポリシースキーマに一致するオブジェクトの配列で構成されます。オブジェクトはscan_execution_policyキーの下にネストされた状態です。scan_execution_policyキーの下には最大5つのポリシーを設定することができます。最初の5つのポリシーの後に設定されたポリシーは適用されません。

新しいポリシーを保存すると、GitLabはポリシーのコンテンツをこのJSONスキーマに対して検証します。JSONスキーマに慣れていない場合は、以下のセクションと表で代替案を提供します。

スキャン実行ポリシースキーマ

skip_ci型

スキャン実行ポリシーは、誰が[skip ci]ディレクティブを使用できるかを制御します。[skip ci]を使用できる特定のユーザーまたはサービスアカウントを指定すると同時に、重要なセキュリティとコンプライアンスのチェックが確実に実行されるようにすることができます。

skip_ciキーワードを使用して、ユーザーがskip_ciディレクティブを適用してパイプラインをスキップできるかどうかを指定します。キーワードを指定しなかった場合、skip_ciディレクティブは無視され、すべてのユーザーはパイプライン実行ポリシーをバイパスできません。

no_pipeline型

スキャン実行ポリシーは、誰が[no_pipeline]ディレクティブを使用できるかを制御します。[no_pipeline]を使用できる特定のユーザーまたはサービスアカウントを指定すると同時に、重要なセキュリティとコンプライアンスのチェックが確実に実行されるようにすることができます。

no_pipelineキーワードを使用して、ユーザーがプッシュ時にパイプラインを作成しないようにno_pipelineディレクティブを適用することを許可されているかどうかを指定します。キーワードを指定しなかった場合、no_pipelineディレクティブは無視され、すべてのユーザーはパイプライン実行ポリシーをバイパスできません。

pipelineルールタイプ

このルールは、選択したブランチに対してパイプラインが実行されるたびに、定義されたアクションを適用します。

1. branchesまたはbranch_typeのいずれかを指定する必要がありますが、両方を指定することはできません。
2. 一部のオプションは、flexible_scan_execution機能フラグが有効な場合にのみ利用できます。詳細については、履歴を参照してください。
3. branch_typeオプションtarget_defaultまたはtarget_protectedが指定されている場合、pipeline_sourcesフィールドはmerge_request_eventおよびpushフィールドのみをサポートします。

scheduleルールタイプ

scheduleルールタイプを使用して、セキュリティスキャナーをスケジュールで実行します。

スケジュールされたパイプライン:

• ポリシーで定義されたスキャナーのみを実行し、プロジェクトの.gitlab-ci.ymlファイルで定義されたジョブは実行しません。
• cadenceフィールドで定義されたスケジュールに従って実行します。
• プロジェクト内のsecurity_policy_botユーザーアカウントの下で実行され、ゲストロールと、パイプラインを作成し、CI/CDジョブからリポジトリのコンテンツを読み取りする権限を持ちます。このアカウントは、ポリシーがグループまたはプロジェクトにリンクされるときに作成されます。
• GitLab.comでは、スキャン実行ポリシーにおける最初の10個のscheduleルールのみが適用されます。制限を超えるルールは効果がありません。

1. branches、branch_type、またはagentsのいずれか1つのみを指定する必要があります。

ケイデンス

cadenceフィールドを使用して、ポリシーのアクションを実行したい時刻をスケジュールします。cadenceフィールドはCron構文を使用しますが、いくつかの制限があります:

• 以下のタイプのCron構文のみがサポートされています:
  • 指定された時刻を中心とした1日1回のケイデンス（例: 0 18 * * *）
  • 指定された曜日と時刻を中心とした1週間に1回のケイデンス（例: 0 13 * * 0）
• 分と時間には、コンマ（,）、ハイフン（-）、またはステップ演算子（/）の使用はサポートされていません。これらの文字を使用しているスケジュールされたパイプラインはスキップされます。

cadenceフィールドの値を選択する際には、以下を考慮してください:

• GitLab.comおよびGitLab Dedicatedの場合、タイミングはUTCに基づいており、GitLab Self-Managedの場合、GitLabホストのシステム時刻に基づいています。新しいポリシーをテストする際、パイプラインはローカルタイムゾーンではなくサーバーのタイムゾーンでスケジュールされているため、不正確な時刻に実行されているように見える場合があります。
• スケジュールされたパイプラインは、作成に必要なリソースが利用可能になるまで開始されません。言い換えれば、パイプラインはポリシーで指定されたタイミングで正確に開始されない可能性があります。

agentsフィールドでscheduleルールタイプを使用する場合:

• Kubernetes向けGitLabエージェントは30秒ごとに適用可能なポリシーがあるかどうかを確認します。エージェントがポリシーを見つけると、スキャンは定義されたcadenceケイデンスに従って実行されます。
• Cron式はKubernetesエージェントポッドのシステム時間を使用して評価されます。

branchesフィールドでscheduleルールタイプを使用する場合:

• Cronワーカーは15分間隔で実行され、前の15分間にスケジュールされていたすべてのパイプラインを開始します。したがって、スケジュールされたパイプラインは最大15分のオフセットで実行できます。
• 大量のプロジェクトまたはブランチに対してポリシーが適用される場合、ポリシーはバッチで処理され、すべてのパイプラインを作成するのに時間がかかることがあります。

agentスキーマ

scheduleルールタイプでagentsオブジェクトを定義するには、このスキーマを使用します。

agentの例

- name: Enforce container scanning in cluster connected through my-gitlab-agent for default and kube-system namespaces
  enabled: true
  rules:
  - type: schedule
    cadence: '0 10 * * *'
    agents:
      <agent-name>:
        namespaces:
        - 'default'
        - 'kube-system'
  actions:
  - scan: container_scanning

スケジュールルールのキーは次のとおりです:

• cadence（必須）: スキャンが実行される時期のCron式。
• agents:<agent-name>（必須）: スキャンに使用するエージェントの名前。
• agents:<agent-name>:namespaces（オプション）: スキャンするKubernetesネームスペース。省略された場合、すべてのネームスペースがスキャンされます。

time_windowスキーマ

scheduleルールタイプのtime_windowオブジェクトを使用して、スケジュールされたスキャンが時間とともにどのように分散されるかを定義します。time_windowは、ポリシーエディタのYAMLモードでのみ設定することができます。

time_windowの例

- name: Enforce container scanning with a time window of 1 hour
  enabled: true
  rules:
  - type: schedule
    cadence: '0 10 * * *'
    time_window:
      value: 3600
      distribution: random
  actions:
  - scan: container_scanning

大規模プロジェクト向けのスケジュールされたパイプラインを最適化する

ポリシーが複数のプロジェクトとブランチにわたってスケジュールされたパイプラインを適用すると、パイプラインは同時に実行されます。各プロジェクトでスケジュールされたパイプラインが最初に実行されると、そのプロジェクトのスケジュールを実行する責任を負うセキュリティボットユーザーが作成されます。

大規模プロジェクトのパフォーマンスを最適化するには:

• 一部のプロジェクトから開始し、スケジュールされたスキャン実行ポリシーを段階的にロールアウトします。セキュリティポリシースコープを活用して、特定のグループ、プロジェクト、または指定されたコンプライアンスフレームワークラベルを含むプロジェクトをターゲットにすることができます。
• tagタグが指定されたRunnerでスケジュールを実行するようにポリシーを設定することができます。他のRunnerへの影響を軽減するために、ポリシーから適用されるスケジュールを処理するために各プロジェクトに専用のRunnerを設定することを検討してください。
• 本番環境にデプロイする前に、ステージングまたはそれより低い環境で実装をテストしてください。パフォーマンスをモニタリングし、結果に基づいてロールアウト計画を調整してください。

スケジュールされたスキャン実行ポリシーの最大スケジュール期間を設定する

スケジュールされたスキャン実行ポリシーは、cadenceフィールドとCron式を使用して月次スケジュールをサポートしています。time_windowを最大2629746秒（約30日）まで設定することで、その期間内にスキャンをランダムに分散できます。

例えば、30日間の分散ウィンドウで月次スケジュールされたスキャンをスケジュールするには:

rules:
  - type: schedule
    cadence: '0 0 1 * *'  # Run on the first day of each month
    time_window:
      value: 2592000  # 30 days in seconds
      distribution: random

インスタンスのダウンタイム中のスケジュールされたスキャンを理解する

スケジュールされたスキャンは、次回の実行時刻を追跡します。スキャンが成功すると、システムは次回のスキャンがいつ実行されるべきかを更新します。GitLabインスタンスがスケジュールされたスキャン時刻に利用できない場合（メンテナンス、停止、または再起動のため）、システムはすでに実行されるべきだったが実行されていないスキャンを識別し、インスタンスが利用可能になったときにパイプラインを作成します。

スケジュールされたスキャンを含むプロジェクトを削除する

プロジェクトを削除すると、関連するすべてのスケジュールされたスキャンも削除されます。削除されたプロジェクトではパイプラインは実行されません。

実行中のスケジュールされたスキャンをキャンセルする

スケジュールされたスキャンをキャンセルするには、2つのオプションがあります:

• 個別のパイプラインをキャンセルする: プロジェクトでジョブをキャンセルするのに必要な権限がある場合、パイプラインビューから直接実行中のパイプラインをキャンセルできます。
• Disable the policy: ポリシーエディタでenabled: falseを設定して、スキャン実行ポリシーを無効にします。すでに実行中、または次の15分以内（約）に実行がスケジュールされているスキャンは、引き続き実行される可能性があります。

大規模デプロイメントに関する推奨事項

多くのプロジェクトにわたってスケジュールされたスキャン実行ポリシーをデプロイする場合、以下の推奨事項を考慮してください:

• 段階的なロールアウトを使用する: 少数のプロジェクトから開始し、徐々にプロジェクトを追加します。コンプライアンスフレームワークラベルを使用して、ポリシーを特定のプロジェクトグループにスコープします。
• time_windowを設定する: スケジュールされたポリシーで常にtime_windowパラメータを設定してください。これがないと、すべてのパイプラインが同じ時刻にスケジュールされ、パフォーマンスの問題やリソース競合を引き起こす可能性があります。
• ステージングでテストする: 本番環境にデプロイする前に、ステージングまたはそれより低い環境でポリシーの設定を検証してください。パフォーマンスをモニタリングし、結果に基づいて調整してください。
• Runner容量を考慮する: Runnerへの影響は、ポリシーの設定、Runnerの可用性、およびGitLabインスタンスのデプロイに依存します。特定のタグを持つRunnerを使用するようにポリシーを設定することで、負荷を分散します。

スケジュールされたスキャンの最適化に関する詳細については、スケジュールされたパイプラインを大規模プロジェクト向けに最適化するを参照してください。

並行処理制御

GitLabは、time_windowプロパティを設定すると並行処理制御を適用します。

並行処理制御は、ポリシーで定義されたtime_window設定に従ってスケジュールされたパイプラインを分散します。

scanアクションタイプ

このアクションは、定義されたポリシー内の少なくとも1つのルールの条件が満たされた場合に、選択されたscanを追加パラメータと共に実行します。

スキャナーの動作

一部のスキャナーは、通常のCI/CDパイプラインスキャンとは異なり、scanアクションで異なる動作をします:

• 静的アプリケーションセキュリティテスト（SAST）: リポジトリにSASTでサポートされるファイルが含まれている場合にのみ実行されます。
• シークレット検出:
  • デフォルトでは、デフォルトルールセット内のルールのみがサポートされています。
  • ルールセットの設定をカスタマイズするには、以下のいずれかの方法があります:
    • デフォルトルールセットを変更します。スキャン実行ポリシーを使用して、SECRET_DETECTION_RULESET_GIT_REFERENCE CI/CD変数を指定します。デフォルトでは、これはデフォルトルールセットからのルールのみをオーバーライドまたは無効にするリモート設定ファイルを指します。この変数のみを使用しても、デフォルトのルールセットを拡張または置換することはサポートされていません。
    • デフォルトルールセットを拡張するか、置換するか。スキャン実行ポリシーを使用して、SECRET_DETECTION_RULESET_GIT_REFERENCECI/CD変数と、Gitパススルーを使用するリモート設定ファイルを指定し、デフォルトルールセットを拡張または置換します。詳細なガイドについては、中央管理されたパイプラインのシークレット検出設定を設定する方法を参照してください。
  • scheduledスキャン実行ポリシーの場合、シークレット検出はデフォルトで最初にhistoricモード（SECRET_DETECTION_HISTORIC_SCAN = true）で実行されます。後続のすべてのスケジュールされたスキャンは、SECRET_DETECTION_LOG_OPTIONSが最後の実行と現在のSHA間のコミット範囲に設定されたデフォルトモードで実行されます。この動作は、スキャン実行ポリシーでCI/CD変数を指定することでオーバーライドできます。詳細については、完全な履歴パイプラインシークレット検出を参照してください。
  • triggeredスキャン実行ポリシーの場合、シークレット検出は、.gitlab-ci.ymlで手動で設定された通常のスキャンと同様に機能します。
• コンテナスキャン: pipelineルールタイプ用に設定されたスキャンは、agentsオブジェクトで定義されたエージェントを無視します。agentsオブジェクトはscheduleルールタイプにのみ考慮されます。agentsオブジェクトで提供される名前を持つエージェントは、プロジェクト用に作成および設定されている必要があります。

DASTスキャンプロファイル

動的アプリケーションセキュリティテスト（DAST）を適用する際には、以下の要件が適用されます:

• ポリシーのスコープ内のすべてのプロジェクトに対して、指定されたサイトプロファイルとスキャナースキャンプロファイルが存在する必要があります。これらが利用できない場合、ポリシーは適用されず、代わりにエラーメッセージを含むジョブが作成されます。
• 有効なスキャン実行ポリシーでDASTサイトプロファイルまたはスキャンプロファイルが指定されている場合、そのプロファイルを変更または削除することはできません。プロファイルを編集または削除するには、まずポリシーエディタでポリシーを無効にするか、YAMLモードでenabled: falseを設定する必要があります。
• スケジュールされたDASTスキャンでポリシーを設定する場合、セキュリティポリシープロジェクトのリポジトリ内のコミットの作成者は、スキャナーおよびサイトプロファイルにアクセスできる必要があります。そうしないと、スキャンは正常にスケジュールされません。

スキャン設定

以下の設定がscan_settingsパラメータでサポートされています:

CI/CD変数

スキャン実行ポリシーで定義された変数は、標準のCI/CD変数の優先順位に従います。

スキャン実行ポリシーが適用されるすべてのプロジェクトで、以下のCI/CD変数に事前設定された値が使用されます。ポリシーのみがこれらの値をオーバーライドできます。グループまたはプロジェクトのCI/CD変数はこれらの変数をオーバーライドできません:

DS_EXCLUDED_PATHS: spec, test, tests, tmp
SAST_EXCLUDED_PATHS: spec, test, tests, tmp
SECRET_DETECTION_EXCLUDED_PATHS: ''
SECRET_DETECTION_HISTORIC_SCAN: false
SAST_EXCLUDED_ANALYZERS: ''
DEFAULT_SAST_EXCLUDED_PATHS: spec, test, tests, tmp
DS_EXCLUDED_ANALYZERS: ''
SECURE_ENABLE_LOCAL_CONFIGURATION: true

GitLab 16.9以前:

• _EXCLUDED_PATHSで終わるCI/CD変数がポリシーで宣言されていた場合、それらの値はグループまたはプロジェクトのCI/CD変数によってオーバーライドされる可能性がありました。
• _EXCLUDED_ANALYZERSで終わるCI/CD変数がポリシーで宣言されていた場合、それらの値は、ポリシー、グループ、またはプロジェクトのどこで定義されていても無視されました。

ポリシーのスコープスキーマ

ポリシーの適用をカスタマイズするには、ポリシーのスコープを定義して、指定したプロジェクト、グループ、またはコンプライアンスフレームワークのラベルを含めるか、除外します。詳細については、スコープを参照してください。

ポリシー更新の伝播

ポリシーを更新すると、その更新方法によって変更の伝播が異なります:

• セキュリティポリシープロジェクトでのマージリクエストを使用する場合: マージリクエストがマージされた後、すぐに変更が有効になります。
• .gitlab/security-policies/policy.ymlへの直接コミット: 変更が有効になるまでに最大10分かかることがあります。

トリガー動作

パイプラインベースのポリシー（type: pipeline）への更新は、即時パイプラインをトリガーせず、すでに進行中のパイプラインにも影響を与えません。ポリシーの変更は、将来のパイプライン実行に適用されます。

スケジュールされたポリシーのルールを、そのスケジュールされたケイデンス外で手動でトリガーすることはできません。

セキュリティポリシープロジェクトの例

セキュリティポリシープロジェクトに保存されている.gitlab/security-policies/policy.ymlファイルで、この例を使用できます:

---
scan_execution_policy:
- name: Enforce DAST in every release pipeline
  description: This policy enforces pipeline configuration to have a job with DAST scan for release branches
  enabled: true
  rules:
  - type: pipeline
    branches:
    - release/*
  actions:
  - scan: dast
    scanner_profile: Scanner Profile A
    site_profile: Site Profile B
- name: Enforce DAST and secret detection scans every 10 minutes
  description: This policy enforces DAST and secret detection scans to run every 10 minutes
  enabled: true
  rules:
  - type: schedule
    branches:
    - main
    cadence: "*/10 * * * *"
  actions:
  - scan: dast
    scanner_profile: Scanner Profile C
    site_profile: Site Profile D
  - scan: secret_detection
    scan_settings:
      ignore_default_before_after_script: true
- name: Enforce secret detection and container scanning in every default branch pipeline
  description: This policy enforces pipeline configuration to have a job with secret detection and container scanning scans for the default branch
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: secret_detection
  - scan: sast
    variables:
      SAST_EXCLUDED_ANALYZERS: brakeman
  - scan: container_scanning

この例では:

• release/*ワイルドカードに一致するブランチ（例: release/v1.2.1ブランチ）で実行されるすべてのパイプラインの場合
  • DASTスキャンはScanner Profile AおよびSite Profile Bで実行されます。
• DASTおよびシークレット検出スキャンは10分ごとに実行されます。DASTスキャンはScanner Profile CおよびSite Profile Dで実行されます。
• シークレット検出、コンテナスキャン、およびSASTスキャンは、mainブランチで実行されるすべてのパイプラインに対して実行されます。SASTスキャンは、SAST_EXCLUDED_ANALYZER変数が"brakeman"に設定されて実行されます。

スキャン実行ポリシーエディタの例

スキャン実行ポリシーエディタのYAMLモードでこの例を使用できます。これは、前の例の単一のオブジェクトに対応します。

name: Enforce secret detection and container scanning in every default branch pipeline
description: This policy enforces pipeline configuration to have a job with secret detection and container scanning scans for the default branch
enabled: true
rules:
  - type: pipeline
    branches:
      - main
actions:
  - scan: secret_detection
  - scan: container_scanning

重複スキャンを避ける

プロジェクトの.gitlab-ci.ymlファイルにスキャンジョブを含めると、スキャン実行ポリシーによって同じタイプのスキャナーが複数回実行される可能性があります。

スキャナーは異なる変数と設定で複数回実行できるため、重複スキャンは意図的に実行されます。例えば、ポリシーを通じて適用されるものとは異なる変数でSASTスキャンを実行する場合があります。このシナリオでは、2つのSASTジョブがパイプラインで実行されます:

• カスタム変数を使用するもの。
• ポリシーによって適用される変数を使用するもの。

重複スキャンを防ぐには、プロジェクトの.gitlab-ci.ymlファイルからいずれかのスキャンを削除するか、変数を持つローカルジョブをスキップします。ジョブをスキップしても、スキャン実行ポリシーで定義されたセキュリティジョブの実行は妨げられません。

変数を持つスキャンジョブをスキップするには、以下を使用できます:

• SAST_DISABLED: "true"を使用してSASTジョブをスキップします。
• DAST_DISABLED: "true"を使用してDASTジョブをスキップします。
• CONTAINER_SCANNING_DISABLED: "true"を使用してコンテナスキャンジョブをスキップします。
• SECRET_DETECTION_DISABLED: "true"を使用してシークレット検出ジョブをスキップします。
• DEPENDENCY_SCANNING_DISABLED: "true"を使用して依存関係スキャンジョブをスキップします。

ジョブをスキップできるすべての変数の概要については、CI/CD変数ドキュメントを参照してください。

トラブルシューティング

スキャン実行ポリシーを使用しているときに、以下のイシューに遭遇する可能性があります。

スキャン実行ポリシーパイプラインが作成されない

スキャン実行ポリシーが、期待どおりにtype: pipelineで定義されたパイプラインを作成しない場合、プロジェクトの.gitlab-ci.ymlファイルに、パイプラインの作成を妨げるworkflow:rulesがある可能性があります。

type: pipelineルールを持つスキャン実行ポリシーは、マージされたCI/CD設定に依存してパイプラインを作成します。プロジェクトのworkflow:rulesがパイプライン全体をフィルタリングする場合、スキャン実行ポリシーはパイプラインを作成できません。

例えば、以下のworkflow:rules設定は、すべてのパイプラインが作成されるのを防ぎます:

# .gitlab-ci.yml
workflow:
  rules:
  - if: $CI_PIPELINE_SOURCE == "push"
    when: never

解決策:

このイシューを解決するには、以下のいずれかのオプションを使用できます:

• プロジェクトの.gitlab-ci.ymlファイル内のworkflow:rulesを修正して、スキャン実行ポリシーがパイプラインを作成できるようにします。$CI_PIPELINE_SOURCE変数を使用して、ポリシーによってトリガーされるパイプラインを識別できます:

  workflow:
    rules:
    - if: $CI_PIPELINE_SOURCE == "security_orchestration_policy"
    - if: $CI_PIPELINE_SOURCE == "push"
      when: never

• type: pipelineルールの代わりにtype: scheduleルールを使用します。スケジュールされたスキャン実行ポリシーはworkflow:rulesの影響を受けず、定義されたスケジュールに従ってパイプラインを作成します。

• CI/CDパイプラインでセキュリティスキャンがいつ、どのように実行されるかをより細かく制御するには、パイプライン実行ポリシーを使用します。