- スキャン実行ポリシーエディタ
- スキャン実行ポリシーのスキーマ
- スキャン実行ポリシースキーマ
pipelineルールタイプ-
scheduleルールタイプ scanアクションタイプ- セキュリティポリシープロジェクトの例
- スキャン実行ポリシーエディタの例
- 重複スキャンの回避
スキャン実行ポリシー
フラグ: セルフマネジメントのGitLabでは、この機能はデフォルトで有効になっています。無効にするには、scan_execution_policy_pipelinesという機能フラグを無効にするよう管理者に依頼してください。GitLab.comでは、この機能は有効です。
グループ、サブグループ、またはプロジェクトのオーナーは、スキャン実行ポリシーを使用して、指定したスケジュールで、またはプロジェクト・パイプラインと一緒にセキュリティ・スキャンを実行するよう要求することができます。グループやサブグループレベルでポリシーを定義すると、セキュリティスキャンは複数のプロジェクトパイプラインで実行されます。GitLabは、必要なスキャンを新しいジョブとしてCI/CDパイプラインに注入します。
スキャンの実行ポリシーは、GitLab CI/CD設定ファイルがないプロジェクトやAutoDevOpsが無効になっているプロジェクトであっても、該当するすべてのプロジェクトに適用されます。セキュリティポリシーは、ポリシーを実施できるように暗黙的にファイルを作成します。これにより、プロジェクトでビルドを必要としない秘密検出、静的解析、またはその他のスキャナの実行を可能にするポリシーが実行され、実施されることが保証されます。
ジョブ名が衝突したイベントでは、GitLabはジョブ名にハイフンと数字を追加します。GitLab は、ジョブ名が既存のジョブ名と衝突しなくなるまで数字を増やします。グループレベルでポリシーを作成すると、すべての子プロジェクトやサブグループに適用されます。子プロジェクトやサブグループからグループレベルのポリシーを編集することはできません。
この2 つの機能のユーザー エクスペリエンスは統一されていないため、この機能はコンプライアンス フレームワーク パイプラインと一部重複しています。これらの機能の類似点と相違点の詳細については、スキャン実行の強制を参照してください。
test ステージで作成されます。デフォルトのパイプラインを変更すると、 ステージが削除されます。 stagesを変更してtest ステージを削除すると、ジョブはscan-policies ステージで実行されます。このステージが存在しない場合は、評価時にCIパイプラインに注入されます。build ステージが存在 buildする場合は、ステージの直後に注入されます。build ステージが存在しない場合は、パイプラインの最初に注入されます。DASTスキャンは常にステージ内で実行されますdast 。このステージが dast存在しない場合は、パイプラインの最後にステージが注入されます。スキャン実行ポリシーエディタ
ポリシーが完成したら、エディタの下部にある [マージリクエストで設定] を選択して保存します。プロジェクトの設定済みセキュリティポリシープロジェクトのマージリクエストにリダイレクトされます。プロジェクトにリンクされていない場合は、セキュリティポリシープロジェクトが自動的に作成されます。既存のポリシーは、エディタの下部にある「Delete policy（ポリシーの削除）」を選択して、エディタのインターフェイスから削除することもできます。
ほとんどのポリシー変更は、マージリクエストがマージされるとすぐに有効になります。マージリクエストを経由せず、デフォルトブランチに直接コミットされた変更は、ポリシーの変更が有効になるまで最大 10 分かかる場合があります。
スキャン実行ポリシーのスキーマ
スキャン実行ポリシーのYAMLファイルは、scan_execution_policy キーの scan_execution_policy下にネストされたスキャン実行ポリシースキーマに一致するオブジェクトの配列で構成されます。キーのscan_execution_policy 下に最大 5 つのポリシーを設定できます scan_execution_policy。最初の 5 つのポリシーの後に設定された他のポリシーは適用されません。
新しいポリシーを保存すると、GitLabはその内容をこのJSONスキーマに対して検証します。JSONスキーマの読み方に慣れていない場合は、以下のセクションと表で代替案を提供します。
| 項目 | 種類 | 必須 | 可能な値 | 説明 |
|---|---|---|---|---|
scan_execution_policy |
array スキャン実行ポリシー | true | スキャン実行ポリシーのリスト（最大5つ） |
スキャン実行ポリシースキーマ
| 項目 | 種類 | 必須 | 可能な値 | 説明 |
|---|---|---|---|---|
name | string | true | ポリシーの名前。最大255文字です。 | |
description (オプション) | string | true | ポリシーの説明 | |
enabled | boolean | true |
true,false
| ポリシーを有効 (true) または無効 (false) にするフラグです。 |
rules |
array ルールの | true | ポリシーが適用されるルールのリスト。 | |
actions |
array アクションの | true | ポリシーが強制するアクションのリスト。 |
pipeline ルールタイプ
branch_typeフィールドはGitLab 16.1 で導入さ れ、security_policies_branch_typeというフラグがあります。デフォルトでは無効です。branch_typeフィールドはGitLab.comで有効化され、GitLab 16.2で自己管理されるようになりました。
このルールは、パイプラインが選択されたブランチに対して実行されるたびに、定義されたアクションを強制します。
| 項目 | 種類 | 必須 | 可能な値 | 説明 |
|---|---|---|---|---|
type | string | true | pipeline | ルールのタイプ。 |
branches 1
|
array のstring
|
branch_type フィールドが存在しない場合は真。 |
* またはブランチ名 | 指定されたポリシーが適用されるブランチ (ワイルドカードをサポート)。 |
branch_type 1
| string |
branches フィールドが存在しない場合は真。 |
default protected またはall
| 指定されたポリシーが適用されるブランチの種類。 |
-
branchesまたはbranch_typeのどちらか一方のみを指定する必要があります。
schedule ルールタイプ
フラグ: セルフマネジメントのGitLabでは、セキュリティポリシーのボットユーザーが利用できます。この機能を隠すには、管理者がscan_execution_group_bot_usersという機能フラグを無効にします。GitLab.comでは、この機能は利用可能です。
このルールはスキャンパイプラインをスケジュールし、cadence フィールドで定義されたスケジュールで定義されたアクションを実行します。スケジュールされたパイプラインは、プロジェクトの.gitlab-ci.yml ファイルで定義された他のジョブを実行しません。プロジェクトがセキュリティポリシープロジェクトにリンクされると、プロジェクトにセキュリティポリシーボットが作成され、スケジュールされたパイプラインの作成者になります。
| 項目 | 種類 | 必須 | 可能な値 | 説明 |
|---|---|---|---|---|
type | string | true | schedule | ルールのタイプ。 |
branches 1
|
array のstring
|
branch_type またはagents フィールドが存在しない場合は真。 |
* またはブランチ名 | 指定されたポリシーが適用されるブランチ (ワイルドカードをサポート)。 |
branch_type 1
| string |
branches またはagents フィールドが存在しない場合は真。 |
default protected またはall
| 指定されたポリシーが適用されるブランチの種類。 |
cadence | string | true | CRON 式 (例:0 0 * * *) | スケジュールされた時間を表す5つのフィールドを含む、空白で区切られた文字列。branches フィールドと共に使用される場合、最小15分間隔。 |
timezone | string | false | タイムゾーン識別子 (例:America/New_York) | ケイデンスに適用するタイムゾーン。値はIANAタイムゾーンデータベースの識別子でなければなりません。 |
agents 1
| object |
branch_type またはbranches フィールドが存在しない場合、true を返します。 | Operational Container Scanningが実行されるGitLabエージェントの名前。オブジェクトキーは、GitLabでプロジェクトに設定されているKubernetesエージェントの名前です。 |
-
branches、branch_type、agentsのいずれか1つだけを指定する必要があります。
スケジュールされたスキャン パイプラインは、プロジェクトのゲスト メンバーであるセキュリティ ポリシー ボット ユーザーによってトリガーされます。セキュリティ ポリシー ボット ユーザーは、セキュリティ ポリシー プロジェクトがリンクされると自動的に作成され、セキュリティ ポリシー プロジェクトがリンク解除されると削除されます。
プロジェクトにセキュリティ ポリシー ボット ユーザーがいない場合、スケジュール スキャン パイプラインは、セキュリティ ポリシー プロジェクトを最後に変更したユーザーによってトリガされます。
GitLab はcadence フィールドに対して以下のタイプの CRON 構文をサポートしています：
- 例えば、1日1回、1時間に1回、指定された時間に、といった具合です：
0 18 * * * - 週に一度、指定された日に、指定された時間に：
0 13 * * 0
schedule ルールタイプとagents フィールドを併用する場合は、以下の点に注意してください：
- GitLab Agent for Kubernetesは30秒ごとに適用可能なポリシーがあるかどうかをチェックします。ポリシーが見つかると、
cadenceの定義に従ってスキャンが実行されます。 - CRON式はKubernetes-agentポッドのシステム時間を使用して評価されます。
schedule ルールタイプとbranches フィールドを併用する場合は、以下の点に注意してください：
- cron ワーカーは 15 分間隔で実行され、前の 15 分間に実行するようスケジュールされたパイプラインを開始します。
- ルールに基づき、スケジュールされたパイプラインは最大15分のオフセットで実行されます。
- CRON式はGitLab.comの標準UTC時間で評価されます。セルフマネジメントのGitLabインスタンスでサーバーのタイムゾーンを変更した場合、CRON式は新しいタイムゾーンで評価されます。
agent スキーマ
schedule ルール・タイプのagents オブジェクトを定義するには、このスキーマを使用します。
| 項目 | 種類 | 必須 | 可能な値 | 説明 |
|---|---|---|---|---|
namespaces |
array のstring
| true | スキャンされるネームスペース。空の場合、すべてのネームスペースがスキャンされます。 |
ポリシーの例
- 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名前空間。省略すると、すべてのネームスペースがスキャンされます。
scan アクションタイプ
このアクションは、定義されたポリシーの少なくとも 1 つのルールの条件が満たされた場合に、選択したscan を追加パラメータ付きで実行します。
| 項目 | 種類 | 可能な値 | 説明 |
|---|---|---|---|
scan | string |
sast sast_iac,dast,secret_detection,container_scanning、dependency_scanning
| アクションのタイプ。 |
site_profile | string | 選択したDASTサイトプロファイルの名前。 | DAST スキャンを実行する DAST サイトプロファイル。このフィールドは、scan タイプがdast の場合のみ設定します。 |
scanner_profile |
string またはnull
| 選択したDAST スキャナプロファイルの名前。 | DAST スキャンを実行する DAST スキャナプロファイル。このフィールドは、scan タイプがdast の場合のみ設定します。 |
variables | object |
key: value ペアの配列として提供される、選択されたスキャンに適用および実施する CI 変数のセット。key は変数名で、value は文字列として提供されます。このパラメータは、GitLab CIジョブが指定されたスキャンでサポートするすべての変数をサポートします。 | |
tags |
array のstring
| ポリシーの Runner タグのリスト。ポリシーのジョブは指定されたタグを持つ Runner によって実行されます。 |
以下に注意してください。
- 選択したセキュリティポリシープロジェクトに割り当てられているプロジェクトごとに、選択した名前でサイトプロファイルと スキャナプロファイルを作成する必要があります。そうしないと、ポリシーは適用されず、代わりにエラー メッセージのジョブが作成されます。
- ポリシーでサイト プロファイルとスキャナ プロファイルを名前で関連付けると、変更または削除できなくなります。これらを変更する場合は、まず
activeフラグをfalseに設定して、ポリシーを無効にする必要があります。 - スケジュールされた DAST スキャンでポリシーを設定する場合、セキュリティポリシープロジェクトのリポジトリにあるコミットの作成者が、スキャナプロファイルとサイトプロファイルにアクセスできる必要があります。そうでない場合、スキャンは正常にスケジュールされません。
- 秘密検出スキャンでは、デフォルトのルールセットのルールのみがサポートされます。カスタムのルールセットはサポートされません。
- 秘密検出スキャンは、パイプラインの一部として実行される場合は
normalモードで実行され、スケジュールされたスキャンの一部として実行される場合はhistoricモードで実行されます。 -
pipelineルール タイプに設定されているコンテナ スキャン スキャンでは、agentsオブジェクトにagents定義されているエージェントは無視されます。agentsオブジェクトがagents考慮されるのは、scheduleルール タイプのみです。agentsオブジェクトで指定された名前のエージェントを作成し、プロジェクト用に設定する必要があります。
セキュリティポリシープロジェクトの例
この例は、セキュリティポリシープロジェクトに格納されている.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
- 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) で実行されるパイプラインごとに、Scanner Profile AとSite Profile Bで DAST スキャンが実行されます。 - DASTスキャンと秘密検出スキャンは10分ごとに実行されます。DAST スキャンは
Scanner Profile CとSite Profile Dで実行されます。 - 秘密検出、コンテナスキャン、およびSASTスキャンは、
mainブランチで実行されるパイプラインごとに実行されます。SASTスキャンは、SAST_EXCLUDED_ANALYZER変数を"brakeman"に設定して実行されます。
スキャン実行ポリシーエディタの例
この例はスキャン実行ポリシーエディタのYAMLモードで使用できます。これは前の例の1つのオブジェクトに対応します。
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" を設定して内部ジョブを無効にします。この方法でジョブを無効にしても、スキャン実行ポリシーで定義されたセキュリティジョブの実行は妨げられません。