コンプライアンスフレームワーク
- プラン: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
コンプライアンスフレームワークは、プロジェクトに特定のコンプライアンス要件があるか、追加の監視が必要であることを識別するためのラベルとして作成できます。
Ultimateプランでは、コンプライアンスフレームワークは、適用先のプロジェクトに対してオプションでコンプライアンスコンプライアンスパイプライン構成とセキュリティポリシーを適用できます。
コンプライアンスフレームワークはトップレベルグループに作成されます。プロジェクトが既存のトップレベルグループの外部に移動された場合、そのフレームワークは削除されます。
各プロジェクトに最大20個のコンプライアンスフレームワークを適用できます。
クリック可能なデモについては、Custom Compliance frameworksを参照してください。
前提要件
- コンプライアンスフレームワークを作成、編集、削除するには、次のいずれかの権限がユーザーに必要です:
- プロジェクトとの間でコンプライアンスフレームワークを追加または削除するには、プロジェクトが所属するグループにコンプライアンスフレームワークが必要です。
コンプライアンスフレームワークを作成、編集、または削除する
コンプライアンスフレームワークレポートまたはコンプライアンスプロジェクトレポートのいずれかを使用して、コンプライアンスフレームワークを作成、編集、または削除できます。
コンプライアンスフレームワークレポートの使用に関する詳細については、以下を参照してください:
コンプライアンスプロジェクトレポートの使用に関する詳細については、以下を参照してください:
- 新規コンプライアンスフレームワークを作成。
- コンプライアンスフレームワークを編集する。
- コンプライアンスフレームワークを削除する。サブグループとプロジェクトは、トップレベルグループに作成されたすべてのコンプライアンスフレームワークにアクセスできます。ただし、サブグループまたはプロジェクトを使用して、コンプライアンスフレームワークを作成、編集、または削除することはできません。プロジェクトオーナーは、プロジェクトに適用するフレームワークを選択できます。
プロジェクトにコンプライアンスフレームワークを適用する
複数のコンプライアンスフレームワークを1つのプロジェクトに適用できますが、個人用ネームスペースのプロジェクトにはコンプライアンスフレームワークを適用できません。
コンプライアンスフレームワークをプロジェクトに適用するには、コンプライアンスプロジェクトレポートを介してコンプライアンスフレームワークを適用します。
GraphQL APIを使用して、1つまたは複数のコンプライアンスフレームワークをプロジェクトに適用できます。
GraphQLを使用してサブグループにコンプライアンスフレームワークを作成する場合、ユーザーが適切な権限を持っている場合、フレームワークはルート祖先に作成されます。GitLab UIは、この動作を抑制するために読み取り専用ビューを表示します。
コンプライアンスフレームワークをコンプライアンスフレームワークを介してプロジェクトに適用するには:
- 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
- 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
- ページで、プロジェクトタブを選択します。
- コンプライアンスフレームワークにカーソルを合わせ、Edit Framework(フレームワークを編集)タブを選択します。
- プロジェクトセクションを選択します。
- リストからプロジェクトを選択します。
- Update Framework(フレームワークを更新)を選択します。
デフォルトコンプライアンスフレームワーク
グループオーナーは、デフォルトコンプライアンスフレームワークを設定できます。デフォルトのフレームワークは、そのグループで作成されたすべての新しいプロジェクトとインポートされたプロジェクトに適用されます。既存のプロジェクトに適用されるフレームワークには影響しません。デフォルトのフレームワークは削除できません。
デフォルトに設定されているコンプライアンスフレームワークには、defaultラベルが付いています。
コンプライアンスセンターを使用して、デフォルトを設定および削除する
コンプライアンスプロジェクトレポートからデフォルトとして設定する(またはデフォルトを削除する)には:
- 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
- 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
- ページで、プロジェクトタブを選択します。
- コンプライアンスフレームワークにカーソルを合わせ、Edit Framework(フレームワークを編集)タブを選択します。
- デフォルトとして設定を選択します。
- 変更を保存を選択します。
コンプライアンスフレームワークレポートからデフォルトとして設定する(またはデフォルトを削除する)には:
- 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
- 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
- ページで、フレームワークタブを選択します。
- コンプライアンスフレームワークにカーソルを合わせ、Edit Framework(フレームワークを編集)タブを選択します。
- デフォルトとして設定を選択します。
- 変更を保存を選択します。
プロジェクトからコンプライアンスフレームワークを削除する
グループ内の1つまたは複数のプロジェクトからコンプライアンスフレームワークを削除するには、コンプライアンスプロジェクトレポートを使用してコンプライアンスフレームワークを削除します。
コンプライアンスフレームワークをインポートおよびエクスポートする
既存のコンプライアンスフレームワークをJSONファイルとしてダウンロードし、JSONテンプレートから新しいフレームワークをアップロードします。
JSONテンプレートのライブラリは、Compliance Adherence Templatesプロジェクトから入手できます。これらのテンプレートを使用して、定義済みのコンプライアンスフレームワークを迅速に採用します。
コンプライアンスフレームワークをJSONファイルとしてエクスポートする
この機能を使用すると、コンプライアンスフレームワークを共有およびバックアップできます。
コンプライアンスセンターからコンプライアンスフレームワークをエクスポートするには:
- 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
- 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
- ページで、フレームワークタブを選択します。
- エクスポートするコンプライアンスフレームワークを見つけます。
- 縦方向の省略記号( )を選択し、編集を選択します。
- Export as JSON file(JSONファイルとしてエクスポート)を選択します。
JSONファイルがローカルシステムにダウンロードされます。
JSONファイルからコンプライアンスフレームワークをインポートする
この機能を使用すると、共有またはバックアップされたコンプライアンスフレームワークを使用できます。JSONファイルの名前は、既存のコンプライアンスフレームワークと同じであってはなりません。
JSONテンプレートを使用してコンプライアンスフレームワークをインポートするには:
- 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
- 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
- ページで、フレームワークタブを選択します。
- 新規フレームワークを選択します。
- フレームワークのインポートを選択します。
- 表示されるダイアログで、ローカルシステムからJSONファイルを選択します。
インポートが成功すると、新しいコンプライアンスフレームワークがリストに表示されます。エラーは修正のために表示されます。
JSONテンプレートの構造とスキーマ
コンプライアンスフレームワークのJSONテンプレートは、フレームワークのメタデータ、要求、および関連するコントロールを定義する特定のスキーマ構造に従います。この構造を理解すると、組織固有のコンプライアンスのニーズに合わせて、カスタムテンプレートを作成したり、既存のテンプレートを変更したりするのに役立ちます。
フレームワークのプロパティ
各JSONテンプレートには、次のトップレベルグループプロパティが含まれています:
| プロパティ | 型 | 必須 | 説明 |
|---|---|---|---|
name | 文字列 | はい | コンプライアンスフレームワークの表示名。 |
description | 文字列 | はい | フレームワークの目的の詳細な説明。 |
color | 文字列 | はい | フレームワークの16進カラーコード(例: #1f75cb)。 |
requirements | 配列 | いいえ | コンプライアンスコントロールを定義する要求オブジェクトの配列。 |
要求構造
requirements配列内の各要求には、以下が含まれます:
| プロパティ | 型 | 必須 | 説明 |
|---|---|---|---|
name | 文字列 | はい | コンプライアンス要件の名前。 |
description | 文字列 | はい | 要求が強制する内容の詳細な説明。 |
controls | 配列 | はい | 要求を実装するコントロールオブジェクトの配列。 |
コントロール構造
controls配列内の各コントロールは、特定のチェックを定義します:
| プロパティ | 型 | 必須 | 説明 |
|---|---|---|---|
name | 文字列 | はい | GitLabコントロールID(例: scanner_sast_running)。 |
control_type | 文字列 | はい | GitLabコントロールの場合は常に"internal"。 |
expression | オブジェクト | はい | コントロールの評価ロジックを定義します。 |
式オブジェクト
expressionオブジェクトは、コントロールの評価方法を定義します:
| プロパティ | 型 | 必須 | 説明 |
|---|---|---|---|
field | 文字列 | はい | 評価するフィールド名(コントロール名と一致)。 |
operator | 文字列 | はい | 比較演算子(=、>=、<=、>、<)。 |
value | 混合 | はい | 予想される値(ブール値、数値、または文字列)。 |
JSONテンプレート構造の例
完全な構造を示す簡単な例を次に示します:
{
"name": "Example Compliance Framework",
"description": "Example framework demonstrating JSON structure",
"color": "#1f75cb",
"requirements": [
{
"name": "Security Scanning Requirement",
"description": "Ensure security scanning is enabled for all projects",
"controls": [
{
"name": "scanner_sast_running",
"control_type": "internal",
"expression": {
"field": "scanner_sast_running",
"operator": "=",
"value": true
}
},
{
"name": "minimum_approvals_required_2",
"control_type": "internal",
"expression": {
"field": "minimum_approvals_required",
"operator": ">=",
"value": 2
}
}
]
}
]
}要件
- プラン: Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
GitLab Ultimateでは、コンプライアンスフレームワークの特定のrequirements(要求)を定義できます。要求は1つまたは複数のコントロールで構成され、フレームワークが割り当てられているプロジェクトの設定または動作に対するチェックです。各要求には、最大5つのコントロールがあります。
各コントロールには、スケジュールされたスキャンまたはトリガーされたスキャン中にGitLabがプロジェクトのコンプライアンス遵守を評価するために使用するロジックが含まれています。コンプライアンス遵守の追跡方法の詳細については、コンプライアンス状況レポートを参照してください。
GitLabコンプライアンスコントロールまたは外部コントロールをフレームワーク要求に使用できます。
GitLabコンプライアンスコントロール
GitLabコンプライアンスコントロールは、GitLabコンプライアンスフレームワークで使用できます。コントロールは、コンプライアンスフレームワークに割り当てられているプロジェクトの設定または動作に対するチェックです。
GitLabコンプライアンスコントロールを組み合わせて、コンプライアンス標準を満たすのに役立ちます。
| コントロール名 | コントロールID | 説明 |
|---|---|---|
| APIセキュリティを実行中 | scanner_api_security_running | APIセキュリティスキャンが構成され、プロジェクトのデフォルトブランチブランチパイプラインで実行されていることを確認します。パイプラインが正常に実行される必要があります。 |
| 少なくとも1つの承認 | minimum_approvals_required_1 | マージリクエストのマージ前に、少なくとも1つの承認を必要とすることを確認します。 |
| 少なくとも2件の承認 | minimum_approvals_required_2 | マージリクエストのマージ前に、少なくとも2つの承認を必要とすることを確認します。 |
| 認証SSOが有効 | auth_sso_enabled | プロジェクトでシングルサインオン(SSO)認証が有効になっていることを確認します。 |
| 作成者が承認したマージリクエストは禁止されています | merge_request_prevent_author_approval | マージリクエストの作成者が自分の変更を承認できないことを確認します。 |
| ブランチの削除が無効 | branch_deletion_disabled | ブランチを削除できないことを確認します。 |
| CI/CDジョブトークンのスコープが有効 | cicd_job_token_scope_enabled | CI/CDジョブトークンのスコープ制限が有効になっていることを確認します。 |
| コードの変更にはコードオーナーが必要 | code_changes_requires_code_owners | コードの変更にはコードオーナーからの承認が必要であることを確認します。 |
| コードオーナーの承認を必須とする | code_owner_approval_required | コードオーナーファイルが構成されていることを確認します。 |
| コード品質の実行 | scanner_code_quality_running | コード品質スキャンが構成され、プロジェクトのデフォルトブランチブランチパイプラインで実行されていることを確認します。パイプラインが正常に実行される必要があります。 |
| コミッターが承認したマージリクエストは禁止されています | merge_request_prevent_committers_approval | マージリクエストにコミットしたユーザーはそれを承認できないことを確認します。 |
| コンテナスキャンを実行中 | scanner_container_scanning_running | コンテナスキャンが構成され、プロジェクトのデフォルトブランチブランチパイプラインで実行されていることを確認します。パイプラインが正常に実行される必要があります。 |
| DASTを実行中 | scanner_dast_running | 動的アプリケーションセキュリティテスト(DAST)が構成され、プロジェクトのデフォルトブランチブランチパイプラインで実行されていることを確認します。パイプラインが正常に実行される必要があります。 |
| デフォルトブランチの保護 | default_branch_protected | デフォルトブランチブランチに保護ルールが有効になっていることを確認します。 |
| デフォルトブランチが直接プッシュから保護されている | default_branch_protected_from_direct_push | デフォルトブランチブランチへの直接プッシュを防止します。 |
| デフォルトブランチブランチのユーザーがマージできる | default_branch_users_can_merge | ユーザーがデフォルトブランチブランチへの変更をマージできるかどうかを制御します。 |
| デフォルトブランチブランチのユーザーがプッシュできる | default_branch_users_can_push | ユーザーがデフォルトブランチブランチに直接プッシュできるかどうかを制御します。 |
| 依存関係スキャンの実行 | scanner_dep_scanning_running | 依存関係スキャンが構成され、プロジェクトのデフォルトブランチブランチパイプラインで実行されていることを確認します。パイプラインが正常に実行される必要があります。メモ: GitLabセルフマネージドインスタンス(18.4以降)では、アーティファクトの相違により、SBOMベースの依存関係スキャンを使用すると、このコントロールが失敗する可能性があります。互換性に関する考慮事項を参照してください。 |
| リポジトリごとに2人の管理者を確保 | ensure_2_admins_per_repo | 少なくとも2人のオーナーが各プロジェクトに割り当てられていることを確認します。 |
| エラートラッキングが有効 | error_tracking_enabled | プロジェクトでエラートラッキングが有効になっていることを確認します。 |
| 強制プッシュが無効 | force_push_disabled | リポジトリへの強制プッシュを防止します。 |
| プロジェクトのフォークが存在する | has_forks | プロジェクトがフォークされていることを確認します。 |
| ファズテストの実行 | scanner_fuzz_testing_running | プロジェクトのデフォルトブランチパイプラインでファズテストが構成され、実行されていることを確認します。パイプラインが正常に実行される必要があります。 |
| GitLabライセンスレベルUltimate | gitlab_license_level_ultimate | GitLabインスタンスがUltimateライセンスを使用していることを確認します。 |
| 有効なCI/CD設定がある | has_valid_ci_config | プロジェクトに有効なCI/CD設定があることを確認します。 |
| IaCスキャンの実行 | scanner_iac_running | Infrastructure as Code(IaC)スキャンが構成され、プロジェクトのデフォルトブランチパイプラインで実行されていることを確認します。パイプラインが正常に実行される必要があります。 |
| 内部表示レベルが禁止されている | project_visibility_not_internal | プロジェクトが内部表示レベルに設定されていないことを確認します。 |
| イシュートラッキングが有効 | issue_tracking_enabled | プロジェクトでイシュートラッキングが有効になっていることを確認します。 |
| ライセンスコンプライアンスを実行中 | scanner_license_compliance_running | プロジェクトのデフォルトブランチパイプラインでライセンスコンプライアンススキャンが構成され、実行されていることを確認します。パイプラインが正常に実行される必要があります。 |
| マージリクエストのコミットにより承認がリセットされる | merge_request_commit_reset_approvals | マージリクエストへの新しいコミットで承認がリセットされることを確認します。 |
| マージリクエストの承認ルールでは編集を禁止 | merge_requests_approval_rules_prevent_editing | マージリクエストの承認ルールを編集できないようにします。 |
| マージリクエストにはコードオーナーの承認が必要 | merge_requests_require_code_owner_approval | マージリクエストにはコードオーナーからの承認が必要であることを確認します。 |
| 管理者よりもメンバーが多い | more_members_than_admins | プロジェクトに割り当てられている管理者(オーナーまたはメンテナー)の数が、メンバーの総数よりも少ないことを確認します。 |
| トリアージされていないパッケージハンターの検出結果なし | package_hunter_no_findings_untriaged | すべてのパッケージハンターの検出結果がトリアージされていることを確認します。 |
| プロジェクトはアーカイブされていません | project_archived | プロジェクトがアーカイブされているかどうかを確認します。通常、falseに準拠しています。 |
| プロジェクトは削除対象としてマークされていません | project_marked_for_deletion | プロジェクトが削除対象としてマークされているかどうかを確認します。falseに準拠しています。 |
| プロジェクトパイプラインは公開されていません | project_pipelines_not_public | プロジェクトパイプラインが公開されていないことを確認します。 |
| プロジェクトリポジトリが存在する | project_repo_exists | プロジェクトにGitリポジトリが存在することを確認します。 |
| プロジェクトの表示レベルは公開されていません | project_visibility_not_public | プロジェクトが公開表示レベルに設定されていないことを確認します。 |
| 保護ブランチが存在する | protected_branches_set | プロジェクトに保護ブランチが含まれていることを確認します。 |
| プッシュ保護が有効 | push_protection_enabled | 機密ファイルに対してプッシュ保護が有効になっていることを確認します。 |
| ブランチを最新にする必要 | require_branch_up_to_date | ソースブランチが、マージする前にターゲットブランチと一致していることを確認します。 |
| 直線的な履歴が必要 | require_linear_history | マージコミットを禁止することで、直線的なコミット履歴を確保します。 |
| 組織レベルでMFAが必要 | require_mfa_at_org_level | 組織レベルで多要素認証が必須であることを確認します。 |
| コントリビューターにMFAが必要 | require_mfa_for_contributors | コントリビューターが多要素認証を有効にしていることを確認します。 |
| 署名されたコミットが必要 | require_signed_commits | 署名されたコミットが必須であることを確認します。 |
| プッシュ時に承認をリセット | reset_approvals_on_push | マージリクエストに新しいコミットがプッシュされると承認がリセットされることを確認します。 |
| ディスカッションを解決する必要がある | resolve_discussions_required | マージが許可される前に、すべてのディスカッションを解決する必要があることを確認します。 |
| プッシュ/マージアクセスを制限 | restrict_push_merge_access | 保護ブランチへのプッシュまたはマージを許可するユーザーを制限します。 |
| ビルドへのアクセス制限 | restricted_build_access | ビルドアーティファクトとパイプライン出力へのアクセスを制限することを確認します。 |
| 古いリポジトリを確認してアーカイブする | review_and_archive_stale_repos | 古いリポジトリを確認してアーカイブされていることを確認します。 |
| 非アクティブなユーザーを確認して削除する | review_and_remove_inactive_users | 非アクティブなユーザーを確認して削除されていることを確認します。 |
| SASTを実行中 | scanner_sast_running | プロジェクトのデフォルトブランチパイプラインで静的アプリケーションセキュリティテスト(SAST)が構成され、実行されていることを確認します。パイプラインが正常に実行される必要があります。 |
| シークレット検出を実行中 | scanner_secret_detection_running | プロジェクトのデフォルトブランチパイプラインでシークレット検出スキャンが構成され、実行されていることを確認します。パイプラインが正常に実行される必要があります。 |
| セキュアWebhook | secure_webhooks | Webhookが安全に構成されていることを確認します。 |
| 古いブランチのクリーンアップを有効 | stale_branch_cleanup_enabled | 古いブランチの自動クリーンアップが有効になっていることを確認します。 |
| ステータスチェックが必要 | status_checks_required | マージが許可される前にステータスチェックに合格する必要があることを確認します。 |
| ステータスページの設定 | status_page_configured | プロジェクトにステータスページが構成されていることを確認します。 |
| リポジトリに対する厳密なアクセス許可 | strict_permissions_for_repo | リポジトリ・アクセスに対して厳密なアクセス許可が設定されていることを確認します。 |
| Terraformが有効 | terraform_enabled | プロジェクトでTerraformインテグレーションが有効になっていることを確認します。 |
| ユーザー定義のCI/CD変数はメンテナーに制限 | project_user_defined_variables_restricted_to_maintainers | メンテナーロール以上のユーザーのみがパイプラインをトリガーする際にユーザー定義変数を渡すことができるようにします。 |
| 脆弱性のSLO日数がしきい値を超過 | vulnerabilities_slo_days_over_threshold | 脆弱性が、サービスレベル目標(SLO)のしきい値(180日)内で処理されるようにします。 |
外部コントロール
外部コントロールとは、外部コントロールまたは要件のステータスを要求する外部システムへのAPIコールです。
サードパーティツールにデータを送信する外部コントロールを作成できます。
コンプライアンススキャンの実行時に、GitLabは通知を送信します。ユーザーまたは自動化されたワークフローは、GitLabの外部からコントロールのステータスを更新できます。
このインテグレーションにより、ServiceNowなどのサードパーティ製ワークフローツール、または選択したカスタムツールとインテグレーションできます。サードパーティツールは、関連付けられたステータスで応答します。このステータスは、コンプライアンスステータスレポートに表示されます。
プロジェクトごとに外部コントロールを構成できます。外部コントロールはプロジェクト間で共有されません。外部コントロールが6時間以上保留状態のままの場合、ステータスチェックは失敗します。
外部コントロールを追加する
フレームワークの作成時または編集時に外部コントロールを追加するには:
- 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
- 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
- ページで、フレームワークタブを選択します。
- 新規フレームワークを選択するか、既存のものを編集します。
- 要求セクションで、新しい要件を選択します。
- 外部コントロールの追加を選択します。
- フィールドで、外部コントロール名、外部URL、
HMACshared secret(共有シークレット)を編集します。 - オプション。Ping enabled(Pingを有効にする) 切替をオフにして、コンプライアンススキャン中にGitLabが外部サービスに通知を送信するかどうかを制御します。
- フレームワークへの変更を保存を選択して、要件を保存します。
Pingが有効な設定
Ping enabled(Pingを有効にする) の設定は、GitLabが外部システムから外部コントロール・ステータスの更新を12時間ごとにリクエストするかどうかを制御します。
- 有効(デフォルト): GitLabは、HTTPリクエストを外部サービスのURLに12時間ごとに自動的に送信し、応答に基づいて外部コントロール・ステータスを更新します。
- 無効: GitLabは外部サービスに通知を送信せず、外部コントロールはコンプライアンスフレームワークのUIに無効バッジを表示します。外部コントロールのステータスをリクエストするには、外部コントロールAPIを手動で使用する必要があります。
外部コントロール・ライフサイクル
外部コントロールにはasynchronous(非同期)ワークフローがあります。コンプライアンススキャンは、ペイロードを外部サービスに送信するたびに発行します。
%%{init: { "fontFamily": "GitLab Sans" }}%%
sequenceDiagram
accTitle: Workflow for external compliance controls
accDescr: GitLab sends a requirement payload to an external service and receives a control response for compliance validation.
GitLab->>+External service: Requirement payload
External service-->>-GitLab: Control response
Note over External service,GitLab: Response includes SHA at HEAD
ペイロードを受信すると、外部サービスは必要なプロセスを実行できます。次に、外部サービスはREST APIを使用して、応答をマージリクエストにポストバックできます。
外部コントロールには、3つのステータスのいずれかを設定できます。
| ステータス | 説明 |
|---|---|
pending | デフォルトの状態外部サービスから応答を受信しませんでした。 |
pass | 外部サービスから応答を受信し、外部コントロールが外部サービスによって承認されました。 |
fail | 外部サービスから応答を受信し、外部コントロールが外部サービスによって拒否されました。 |
GitLabの外部で何かが変更された場合は、APIを使用して外部コントロールのステータスを設定できます。最初にペイロードが送信されるのを待つ必要はありません。
要件を追加
フレームワークの作成時または編集時に要件を追加するには:
- 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
- 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
- ページで、フレームワークタブを選択します。
- 新規フレームワークを選択するか、既存のものを編集します。
- 要求セクションで、新しい要件を選択します。
- ダイアログで、名前と説明を追加します。
- GitLabコントロールを追加するを選択して、コントロールを追加します。
- コントロール・ドロップダウン・リストでコントロールを検索して選択します。
- フレームワークへの変更を保存を選択して、要件を保存します。
要件の編集
フレームワークの作成時または編集時に要件を編集するには:
- 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
- 左側のサイドバーで、セキュリティ > コンプライアンスセンターを選択します。
- ページで、フレームワークタブを選択します。
- 新規フレームワークを選択するか、既存のものを編集します。
- 要求セクションで、アクション > 編集を選択します。
- ダイアログで、名前と説明を編集します。
- GitLabコントロールを追加するを選択して、コントロールを追加します。
- コントロール・ドロップダウン・リストでコントロールを検索して選択します。
- コントロールを削除するには、 を選択します。
- フレームワークへの変更を保存を選択して、要件を保存します。
トラブルシューティング
コンプライアンスフレームワークを操作しているときに、次の問題が発生する可能性があります。
エラー: Unable to determine the correct upload URL
JSONテンプレートと同じ名前のコンプライアンスフレームワークがすでに存在する場合、コンプライアンスフレームワークのインポート中にこのエラーが発生します。