スキャン実行ポリシー

スキャン実行ポリシーは、デフォルトまたは最新のsecurity CI/CD templatesに基づいて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分かかる場合があります。（この制限に対する提案された変更については、issue 512615を参照してください。）

ジョブ

DASTスキャン以外のスキャンのポリシージョブは、パイプラインのtestステージに作成されます。testステージをデフォルトのパイプラインから削除すると、ジョブは代わりにscan-policiesステージで実行されます。このステージは、存在しない場合、評価時にCI/CDパイプラインに挿入されます。buildステージが存在する場合、scan-policiesはbuildステージの直後に挿入され、そうでない場合はパイプラインの先頭に挿入されます。DASTスキャンは常にdastステージで実行されます。dastステージが存在しない場合は、dastステージがパイプラインの最後に挿入されます。

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

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

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

前提要件:

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

最初のスキャン実行ポリシーを作成する際に、最も一般的なユースケースをすぐに開始できるように、テンプレートが用意されています:

• マージリクエストセキュリティテンプレート

  • ユースケース: セキュリティスキャンは、すべてのコミットではなく、マージリクエストが作成されたときにのみ実行されるようにする必要がある。
  • 使用するケース: デフォルトまたは保護ブランチをターゲットとするソースブランチでセキュリティスキャンを実行する必要があるマージリクエストパイプラインを使用するプロジェクトの場合。
  • 最適な対象: すべてのブランチでのスキャンを回避することで、マージリクエスト承認ポリシーに準拠し、インフラストラクチャのコストを削減したいチーム。
  • パイプラインソース: 主にマージリクエストパイプライン。

• スケジュールされたスキャンテンプレート

  • ユースケース: の変更に関係なく、セキュリティスキャンをスケジュールに基づいて（毎日または毎週のように）自動的に実行する必要がある。
  • 使用するケース: 開発アクティビティーとは関係なく、定期的なケイデンスでのセキュリティスキャンの場合。
  • 最適な対象: コンプライアンスフレームワーク要件、ベースラインセキュリティモニタリング、またはコミットがまれなプロジェクト。
  • パイプラインソース: スケジュールされたパイプライン。

• リリースセキュリティテンプレートのマージ

  • ユースケース: すべての変更をmainまたはリリースブランチでセキュリティスキャンを実行する必要がある。
  • 使用するケース: リリース前、または保護ブランチで包括的なスキャンを必要とするプロジェクトの場合。
  • 最適な対象: リリースゲート型ワークフロー、本番環境デプロイ、または高度なセキュリティ環境。
  • パイプラインソース: 保護ブランチへのプッシュパイプライン、リリースパイプライン。

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

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

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

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

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

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

新しいポリシーを保存すると、GitLabはこのJSONスキーマに照らしてポリシーの内容を検証します。JSON schemasに精通していない場合は、以下のセクションと表で代替案を確認してください。

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

skip_ci型

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

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

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フィールドで定義されたスケジュールに従って実行します。
• CI/CDジョブからパイプラインを作成し、リポジトリのコンテンツを読み取りるためのゲストロールと権限を持つ、プロジェクト内のsecurity_policy_botユーザーアカウントで実行されます。このアカウントは、ポリシーがグループまたはプロジェクトにリンクされるときに作成されます。
• GitLab.comでは、スキャン実行ポリシーの最初の10個のscheduleルールのみが適用されます。制限を超えるルールは無効です。

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

ケイデンス

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

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

cadenceフィールドの値を選択するときは、次の点を考慮してください:

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

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

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

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

• 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オブジェクトを使用して、スケジュールされたスキャンが時間の経過とともにどのように分散されるかを定義します。ポリシーエディタのYAMLモードでのみtime_windowを設定できます。

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への影響を軽減することを検討してください。
• 本番環境にデプロイする前に、ステージング環境または下位環境で実装をテストします。パフォーマンスを監視し、結果に基づいてロールアウト計画を調整します。

並行処理

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

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

scanアクションタイプ

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

スキャナーの動作

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

• 静的アプリケーションセキュリティテスト（SAST）: リポジトリにSASTでサポートされているファイルが含まれている場合にのみ実行されます。
• シークレット検出:
  • デフォルトでは、デフォルトルールセットのルールのみがサポートされています。
  • ルールセットの設定をカスタマイズするには、次のいずれかの方法を実行します:
    • デフォルトのルールセットを変更します。スキャン実行ポリシーを使用して、SECRET_DETECTION_RULESET_GIT_REFERENCE CI/CD変数を指定します。デフォルトでは、これはデフォルトのルールセットからのルールをオーバーライドまたは除外するリモート設定ファイルを指します。この変数のみを使用しても、デフォルトのルールセットの拡張または置換はサポートされません。
    • デフォルトのルールセットを拡張または置換します。スキャン実行ポリシーを使用して、SECRET_DETECTION_RULESET_GIT_REFERENCE CI/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変数に事前設定された値が使用されます。これらの値をオーバーライドできますが、ポリシーで宣言されている場合にonly（のみ）可能です。これらは、グループまたはプロジェクトの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ジョブがパイプラインで実行されます:

• 1つはデベロッパーの変数を使用します。
• もう1つは、セキュリティおよびコンプライアンスチームの変数を使用します。

重複するスキャンの実行を回避するには、プロジェクトの.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で定義されたパイプラインを作成しない場合は、workflow:rulesがプロジェクトの.gitlab-ci.ymlファイルにあり、ポリシーによるパイプラインの作成を妨げている可能性があります。

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

たとえば、次のworkflow:rules設定では、すべてのパイプラインが作成されません:

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

解決:

この問題を解決するには、次のいずれかのオプションを使用できます:

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

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

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

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