ポリシー

GitLabのポリシーは、指定された設定に従ってプロジェクトパイプラインが実行されるたびに、セキュリティチームが選択したスキャンの実行を要求する方法を提供します。そのため、セキュリティチームは設定したスキャンが変更、変更、無効化されていないことを確信することができます。プロジェクトのSecure > Policiesページに移動することで、これらのページにアクセスできます。

GitLabは以下のセキュリティポリシーをサポートしています：

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

すべてのセキュリティポリシーは、開発プロジェクト、グループ、あるいは、サブグループにリンクされる別のセキュリティポリシープロジェクトに YAML として保存されます。この関連は、1対多の関係にすることができ、1つのセキュリティポリシープロジェクトを複数の開発プロジェクト、グループ、あるいは、サブグループに適用することができます：

  • GitLab の自己管理インスタンスでは、リンク先のプロジェクトは、リンク先の開発プロジェクトと同じグループや同じサブグループである必要はありません。
  • GitLab SaaSの場合、セキュリティポリシープロジェクトは開発プロジェクトと同じトップレベルのグループにいる必要がありますが、プロジェクトが同じサブグループにいる必要はありません。

Security Policy Project Linking Diagram

1つのプロジェクトを開発プロジェクトとセキュリティポリシープロジェクトの両方にリンクさせることは可能ですが、これは推奨されません。セキュリティポリシープロジェクトを開発プロ ジェクトから分離することで、セキュリティ／コンプライアンスチームと開発チー ムの職務を完全に分離することができます。

すべてのセキュリティポリシーは、リンクされたセキュリティポリシープロジェクト内部の.gitlab/security-policies/policy.yml YAML ファイルに保存されます。この YAML のフォーマットは、格納されるポリシーのタイプに固有です。例とスキーマ情報は、次のポリシータイプで利用可能です：

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

リンクされたセキュリティポリシープロジェクトの管理

note
セキュリティ ポリシー プロジェクトを選択、編集、リンク解除する権限を持つのは、プロジェ クト オーナーのみです。

プロジェクトオーナーとして、以下の手順に従って、現在のプロジェクトとセキュリティポリシープロジェクトとして指定するプロジェクトとの関連付けを作成または編集してください：

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. セキュリティ > ポリシーを選択します。
  3. ポリシープロジェクトの編集]を選択し、ドロップダウンリストからリンクするプロジェクトを検索して選択します。
  4. Save を選択します。

セキュリティポリシープロジェクトのリンクを解除するには、同じ手順に従いますが、代わりにモーダルでゴミ箱アイコンを選択します。

Security Policy Project

リンクされたセキュリティポリシープロジェクトの表示

プロジェクトポリシーページにアクセスでき、プロジェクトオーナーでないすべてのユーザーには、関連するセキュ リティポリシープロジェクトにリンクするボタンが表示されます。セキュリティポリシープロジェクトが関連付けられていない場合、リンクボタンは表示されません。

ポリシー管理

ポリシー ページには、利用可能なすべての環境のデプロイ済みポリシーが表示されます。ポリシーの情報 (説明や実施状況など) を確認したり、デプロイされたポリシーを作成および編集したりできます：

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. セキュリティ > ポリシーを選択します。

Policies List Page

ポリシーエディタ

GitLab 13.4 で導入されました。

ポリシーエディターを使ってポリシーの作成、編集、削除ができます：

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. セキュリティ > ポリシーを選択します。
    • 新しいポリシーを作成するには、[ポリシー]ページのヘッダーにある [新しいポリシー] を選択します。次に、作成するポリシーの種類を選択できます。
    • 既存のポリシーを編集するには、選択したポリシーのドロワーで [ポリシーの編集] を選択します。

ポリシー エディタには 2 つのモードがあります：

  • ビジュアル_ルール_モードでは、ルール ブロックと関連コントロールを使用してポリシー ルールを構築し、プレビューできます。

    Policy Editor Rule Mode

  • YAML モードでは、.yaml フォーマットでポリシー定義を入力することができます。

    Policy Editor YAML Mode

両方のモードを互換的に使用し、いつでも切り替えることができます。YAML リソースが正しくないか、ルールモードでサポートされていないデータが含まれている場合、ルールモードは自動的に無効になります。YAML が正しくない場合、ルールモードが再び利用できるようになる前に、YAML モードを使用してポリシーを修正する必要があります。

ポリシーの作成または編集が完了したら、[マージ リクエストで設定] ボタンを選択し、結果のマージ リクエストをマージすることによって、ポリシーを保存して適用します。このボタンを押すと、ポリシーの YAML が検証され、結果のエラーが表示されます。さらに、あなたがプロジェクトオーナーであり、セキュリティポリシープロジェクトがこのプロジェクトと以前に関連付けられていない場合、新しいプロジェクトが作成され、最初のポリシーマージ要求が作成されると同時に自動的に関連付けられます。

スクリプトによるプロジェクトの一括管理

脆弱性チェックマイグレーションスクリプトを使用すると、ポリシーを一括作成したり、セキュリティポリシープロジェクトを開発プロジェクトに関連付けたりできます。脆弱性チェックマイグレーションスクリプトの使用方法とデモについては、このビデオを参照してください。

トラブルシューティング

Branch name 'update-policy-<timestamp>' does not follow the pattern '<branch_name_regex>'

新しいセキュリティポリシーを作成したり、既存のポリシーを変更したりすると、update-policy-<timestamp> のパターンに従ったブランチ名で新しいブランチが自動的に作成されます。例:update-policy-1659094451.

テキストupdate-policy-<timestamp> を含むブランチ名パターンを許可しないグループまたはインスタンスのプッシュルールがある場合、Branch name 'update-policy-<timestamp>' does not follow the pattern '<branch_name_regex>' というエラーが表示されます。

回避策としては、グループやインスタンスのプッシュルールを修正して、update-policy- の後に整数のタイムスタンプが続くパターンのブランチを許可するようにします。

セキュリティポリシーの設定に関するよくある問題のトラブルシューティング

  • スキャナが適切に設定され、最新のブランチの結果が得られていることを確認します。セキュリティポリシーは、結果がない場合（セキュリティレポートがない場合）に承認者を必要とするように設計されています。ポリシーによって実施されたスキャンが正常に完了し、評価されない限り、脆弱性があるかどうかを知ることはできません。
  • SAST のアクションに基づいてスキャン実行ポリシーを実行する場合、ターゲットリポジトリに適切なコードファイルが含まれ ていることを確認してください。SAST はリポジトリ内のファイルの種類に基づいて異なるアナライザを実行し、サポートされるファイルが見つからない場合はジョブを実行しません。詳細については、SAST CIテンプレートを参照してください。
  • ブランチ設定の競合をチェックします。ポリシーがmain にルールを適用するように設定されているにもかかわらず、スコープ内のいくつかのプロジェクトがデフォルトブランチとしてmaster を使用している場合、後者にはポリシーが適用されません。ポリシーでdefault ブランチを指定するためのサポートはエピック 9468で提案されています。
  • グループまたはサブグループレベルで作成されたスキャン結果ポリシーは、グループ内のすべてのマージリクエストに適用されるまでに時間がかかることがあります。
  • スケジュールされたスキャン実行ポリシーは、最低 15 分の間隔で実行されます。スケジュール ルール タイプの詳細については、こちらを参照してください。
  • パイプラインをスケジューリングする際、GitLab SaaSではCRONのスケジューリングはUTCに基づいており、セルフマネージドインスタンスではサーバーの時間に基づいていることに留意してください。新しいポリシーをテストするとき、パイプラインが正しく実行されていないように見えるかもしれませんが、実際にはサーバーのタイムゾーンでスケジュールされています。
  • スキャン実行ポリシーを実施する場合、対象プロジェクトのパイプラインは、セキュリティポリシープロジェクトのpolicy.yml ファイルを最後に更新したユーザーによってトリガーされます。ポリシーが適用され、パイプラインが実行されるには、ユーザーがプロジェクトでパイプラインをトリガーする権限を持っている必要があります。これにアドレスする作業は、イシュー394958 で追跡されています。
  • セキュリティポリシープロジェクトを開発プロジェクトと、開発プロジェクトが所属するグループまたはサブグループに同時にリンクすべきではありません。このようにリンクすると、スキャン結果ポリシーの承認ルールが開発プロジェクトのマージリクエストに適用されなくなります。
  • スキャン結果ポリシーを作成する場合、scan_finding ルールの配列severity_levels と配列vulnerability_states のどちらも空白にすることはできません。
  • パイプラインとスキャン結果のポリシーを設定する場合、手動ジョブで実行されるセキュリティスキャンは MR の承認が必要かどうかを判断するために検証されないことを覚えておくことが重要です。セキュリティスキャンを伴う手動ジョブを実行すると、脆弱性が導入されても承認者は確実に承認されません。

まだイシューが発生している場合は、最近レポーターされたバグを表示し、未報告の新しい問題を提起することができます。