[{"data":1,"prerenderedAt":838},["ShallowReactive",2],{"/ja-jp/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features":3,"navigation-ja-jp":43,"banner-ja-jp":464,"footer-ja-jp":474,"blog-post-authors-ja-jp-Cherry Han|Gavin Peltz":709,"blog-related-posts-ja-jp-finserv-how-to-implement-gitlabs-separation-of-duties-features":736,"blog-promotions-ja-jp":777,"next-steps-ja-jp":829},{"id":4,"title":5,"authorSlugs":6,"authors":9,"body":12,"category":13,"categorySlug":13,"config":14,"content":18,"date":26,"description":19,"extension":27,"externalUrl":28,"featured":17,"heroImage":21,"isFeatured":17,"meta":29,"navigation":30,"path":31,"publishedDate":26,"rawbody":32,"seo":33,"slug":16,"stem":37,"tagSlugs":38,"tags":41,"template":15,"updatedDate":28,"__hash__":42},"blogPosts/ja-jp/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features.md","金融サービス業界向け：GitLabの職務分離機能を実装する方法",[7,8],"cherry-han","gavin-peltz",[10,11],"Cherry Han","Gavin Peltz","ソフトウェア開発の過程において、特に金融サービスのようなデータの完全性や規制の遵守が不可欠な業界では、強固なセキュリティとコンプライアンス対策が求められます。これらの基準を維持する上で重要な要素の1つが職務分離（SoD）です。SoDは、プロセス全体の管理を1人に割り当てないようにすることで、エラーや不正行為のリスクを軽減するアプローチです。SoDにより、ソフトウェア開発プロセスの完全性を損なう可能性のある外部からの悪意ある行為を防ぎ、ソフトウェアサプライチェーンにおけるリスクを軽減できます。\n\n## 金融サービス業界におけるSoDの重要性\n\n金融サービス業界では、SoDが機密情報の保護やコンプライアンス遵守の確保を実現する上で重要な役割を果たします。SoDは、金融サービス業界において戦略的に以下のようなメリットをがあります。\n\n* **リスク軽減**：職務を複数の役割に分担することで、システムの完全性や規制コンプライアンスの遵守を損なう可能性のあるエラー、不正行為、無許可のアクティビティのリスクを軽減します。\n* **責任の強化**：明確な職務分担により、1人の担当者がプロセス全体を一貫して管理することができなくなり、結果として透明性と責任意識が高まります。透明性と責任意識は、ステークホルダーや規制当局との信頼関係を維持する上で不可欠です。\n* **規制コンプライアンス**：SoDは、機密性の高い業務が監視と審査の下で行われることを保証する目的で、金融規制によって義務付けられています。これらの基準を遵守することで、ペナルティを回避できるだけでなく、組織の評判も保護されます。\n* **運用の強靭性**：意思決定と実行を分散することで、組織は人的ミスや悪意ある行為、および予期せぬ出来事によってもたらされる混乱の影響を受けにくくなります。\n\n## GitLabによる職務分離とベストプラクティス\nGitLabでは、DevSecOpsワークフロー全体を対象としたエンドツーエンドの職務分離機能を使用できます。\n\n![金融サービスのSoD - 画像1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097695/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097695697.png)\n\n上記の図は、SoDの原則を維持するために、マージリクエスト承認ポリシー、保護機能、ユーザー権限、コンプライアンスフレームワーク、監査イベントといった重要な要素がどのように統合され、連携しているかを示しています。各要素については、後続のセクションで安全かつコンプライアンスに準拠した開発環境の構築方法を解説する中で、詳述します。\n\n### マージリクエスト承認ポリシー\n\n金融サービス業界が直面する課題のひとつに、不正またはチェックされていない変更が統合されるのを防ぐ承認メカニズムの実装があります。ここで役立つのが[マージリクエスト承認ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/scan-result-policies/)です。このポリシーにより、セキュリティと開発の職務分離が強制され、デベロッパーが脆弱性を含むコード変更を自分で承認したり、開発チームが適切な監視なしにコードを本番環境に直接デプロイしたりすることを防止できます。\n\nポリシーを作成する際には、承認者として誰が適切であるかを検討することをおすすめします。承認者には、個人ユーザー、アプリケーションセキュリティチームなどのグループ、あるいはメンテナーといったロールタイプを指定できます。さらに制約を加えたい場合は、以下の主要なポリシー機能の使用をご検討ください。\n\n- 作成者による承認を防止：このポリシーにより、マージリクエストの作成者が自身の変更を承認できないようガードレールが設定されます。独立したレビューを求めることで、承認プロセスの客観性と公平性が維持されます。\n\n- コミットを追加したユーザーによる承認を防ぐ：マージリクエストにコミットを追加したユーザーも、承認を行うことができないようにします。これにより、変更に直接関わっていないチームメンバーによって検証が行われる、独立したレビューの原則がさらに強化されます。\n\n- 承認ルールの編集を防止：承認プロセスの整合性を維持するため、GitLabではプロジェクトやマージリクエストレベルで承認ルールの編集を管理者が禁止できます。これにより、一度定義された承認ポリシーが無断で変更されたり回避されたりしないよう保証されます。\n\n- 承認にユーザーパスワードを要求：追加のセキュリティ対策として、GitLabではマージリクエストを承認するユーザーに対して、パスワードの入力を求めることができます。\n\n職務分離を明確に維持するため、マージリクエスト承認ポリシーを含むセキュリティポリシーを格納するための専用の[トップレベルグループを別途作成](https://docs.gitlab.com/ja-jp/user/application_security/policies/#enforce-policies-globally-in-gitlab-dedicated-or-your-gitlab-self-managed-instance)することが推奨されます。この設定により、権限を継承するユーザーの数が最小限に抑えられ、ポリシー管理を厳格に制御できます。この専用グループから、目標に合う最上位グループレベルで[セキュリティポリシープロジェクトをリンク](https://docs.gitlab.com/ja-jp/user/application_security/policies/#link-to-a-security-policy-project)することで、ポリシー管理の手間を軽減し、開発環境全体で包括的なカバレッジを確保できます。\n\nまた、ポリシーがデフォルトで有効になっている場合、そのポリシーは関連するリンクされたグループ、サブグループ、および個別のプロジェクト内のすべてのプロジェクトに適用されることにも注意してください。より対象を絞ってポリシーを適用したい場合、GitLabは[コンプライアンスフレームワークラベル](https://docs.gitlab.com/ja-jp/user/group/compliance_frameworks/)を使用してポリシーの適用範囲を絞り込むことを推奨しています。厳格な規制に対応しているお客様の多くは、「SOX」や「PCI」などの規制要件に対応するコンプライアンスラベルを作成しています。また、このフレームワークへのリンクにより、[ネイティブコンプライアンスセンター](https://docs.gitlab.com/ja-jp/user/compliance/compliance_center/)でさまざまなユースケースに合わせたセキュリティポリシーを管理できるようになります。\n\n### コンプライアンスフレームワークと制御\n\n規制対象の業界に属するお客様は、大規模な組織においてコンプライアンスを維持する上で大きな課題に直面しています。手動のプロセスはエラーが生じやすく、チーム間でポリシーを一貫して適用し続けることが難しい場合もあります。\n\nGitLabのコンプライアンスフレームワークを使用することで、組織は予防措置の自動化と管理、リスクの体系的な管理、そして規制コンプライアンスのシームレスな適用を実現できます。これらのフレームワークによって、どのようなパイプラインでもセキュリティプロトコルやカスタムジョブを実施できます。\n\nコンプライアンス設定を組織レベルで保護するために、GitLabではグループまたはプロジェクトのオーナーのみがコンプライアンスフレームワークを追加または削除できるようになっています。この対策により、適切な権限レベルを持たない開発チームやマネージャーによるコンプライアンス設定の変更が防止され、セキュリティがさらに強化されます。なお、メンテナー権限を持つ個人がサブグループを作成できる場合、そのサブグループのオーナーとなりコンプライアンスフレームワークを変更できる点に注意してください。これを防ぐには、権限とグループの設定で[サブグループの作成者](https://docs.gitlab.com/ja-jp/user/group/subgroups/#change-who-can-create-subgroups)を制限してください。\n\n## SoDのための権限とロール\n\n金融サービス業界で職務分離を効果的に実施するには、明確かつ正確なアクセス制御の設定が不可欠です。GitLabには、あらかじめ定義されたロール（ゲスト、レポーター、デベロッパー、メンテナー、オーナーなど）による階層的な[権限モデル](https://docs.gitlab.com/ja-jp/user/permissions/)が備わっています。各ロールには特定の権限セットが割り当てられており、個人が業務を遂行する際に自身の権限の範囲を逸脱しないようになっています。これにより、利益相反やセキュリティリスクを抑えられます。GitLabでは[最小権限の原則](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/)に従ってロールを割り当てることを推奨しています。\n\n細かいニーズを持つ組織、特にGitLab Ultimateを使用している組織では、[カスタムロール](https://docs.gitlab.com/ja-jp/user/custom_roles/)を活用することで、さらに柔軟な対応が可能になります。これらのロールを使用することで、各組織の独自のワークフローやコンプライアンス要件に合わせた特定の権限を設定できます。担当者が相反するタスクを実行できなくなるため、SoDの強制に特に役立ちます。\n\n一般的なユースケースとして、デプロイロールが必要な場合があります。これは、デプロイの権限が必要な個人に対して、コードの編集やプッシュの権限は与えたくない場合に使用できます。こういった要件に対応するために、GitLabは[保護環境](https://docs.gitlab.com/ja-jp/ci/environments/protected_environments/#protecting-environments)を提供しています。保護環境を使用すると、[ジョブのデプロイ承認を受けたグループを招待](https://docs.gitlab.com/ja-jp/ci/environments/protected_environments/#deployment-only-access-to-protected-environments)し、ユーザーのロールをレポーターに限定できます。なお、デプロイジョブにはenvironmentキーワードを含める必要があります。この設定により、コードの編集権限がないユーザーがデプロイを実行できるようになり、コンプライアンス要件に準拠できます。\n\n組織においてロールと権限を慎重に定義し適用することで、安全かつコンプライアンスに準拠した開発環境を構築できます。ユーザー権限を広範に見直したい場合、[こちらのグループメンバーレポート](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/gitlab-group-member-report)を使用して各ロールのメンバー数を確認し、それに応じた次のステップを検討することが可能です。\n\n## 保護機能\nGitLabは、開発プロセスをより厳重にかんりできるようにするために「保護」機能を提供しています。これらの機能は、指定された担当者のみが重要な変更を行えるようにするために使用でき、SoDを維持するためには不可欠です。\n\n- 保護ブランチ：保護ブランチでは、誰がプッシュ、マージ、または強制プッシュを実行できるかが制限されます。権限を持つユーザーのみが変更を加えられるように制御でき、特に「main」や「production」のようなブランチで効果的です。\n- 保護Gitタグ：このタグを使用すると、タグの作成権限を持つユーザーを制御できます。タグの作成後に誤った更新や削除が発生しないよう防止され、バージョン管理の整合性が保たれます。\n- 保護環境：特定の環境、特に本番環境への無許可のアクセスを防ぐことは必須事項と言えます。保護環境では、適切な権限を持つユーザーのみがデプロイできるため、意図しない変更から環境を保護できます。これは前述のデプロイロール機能と関連しており、コードを編集せずにジョブをデプロイできるようになるため、コンプライアンスとセキュリティを確保できます。\n- 保護パッケージ：パッケージ保護ルールを使用することで、どのユーザーがパッケージに変更を加えられるかを制限できます。\nこれらの保護機能はすべて、SoDの原則に沿った安全でコンプライアンスに準拠した開発環境の維持に役立ちます。\n\n## 監査イベントとコンプライアンスセンター\nここまで承認ポリシー、コンプライアンスフレームワーク、ロール、保護機能について説明してきましたが、最後に、GitLabでこれらの実装をどのようにモニタリングおよび監査してコンプライアンスを遵守できるかについて解説します。GitLabの[監査イベント](https://docs.gitlab.com/ja-jp/user/compliance/audit_events/)では、ユーザーの活動やプロジェクトの変更など、オーナーや管理者向けに詳細なアクティビティ履歴を提供します。このログは、ユーザーアクションを追跡したり、無許可のアクティビティを検出したりする上で不可欠です。組織において[監査イベントストリーミング](https://docs.gitlab.com/ja-jp/user/compliance/audit_event_streaming/)を使用して監査イベントを外部システムにストリーミングすることで、リアルタイムでの分析やアラートが可能になります。これにより、改変や違反が検出され、迅速に修正できるようになります。\n\n[GitLabのコンプライアンスセンター](https://docs.gitlab.com/ja-jp/user/compliance/compliance_center/)は、コンプライアンスに関連するアクティビティを一元的に管理およびモニタリングできる場所です。ここではプロジェクトやグループ全体のコンプライアンス状況の概要を確認でき、マージリクエスト承認ルールやその他のポリシーの違反が強調表示されます。管理者は問題に迅速に対処し、あらかじめ定義されたコンプライアンス基準への準拠を確認できます。この一元化されたアプローチにより、コンプライアンス管理が簡素化され、高度なレベルでモニタリングと制御を行えます。\n\n> GitLabのSoDやコンプライアンスに関する考え方について詳しく知りたい方は、[Governステージに関するGitLabの製品方針](https://docs.gitlab.com/ja-jp/user/compliance/) と[GitLabのコンプライアンスドキュメント](https://docs.gitlab.com/ja-jp/administration/compliance/)をご覧ください。\n\n## その他のリソース\n\n- [GitLabのコンプライアンスとセキュリティポリシー管理で規制基準を遵守](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)\n- [GitLabを使ったGitLabの構築：セキュリティ認証ポートフォリオを拡充](https://about.gitlab.com/blog/building-gitlab-with-gitlab-expanding-our-security-certification-portfolio/)\n- [オンライン小売業者bol社、GitLabで拡大するコンプライアンスニーズに対応](https://about.gitlab.com/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab/)","security",{"template":15,"slug":16,"featured":17},"BlogPost","finserv-how-to-implement-gitlabs-separation-of-duties-features",false,{"title":5,"description":19,"authors":20,"heroImage":21,"tags":22,"category":13,"date":26,"body":12},"金融サービス業界において、GitLabの職務分離機能を活用して安全でコンプライアンスに準拠したソフトウェア開発を実現する方法をご説明します。また、規制フレームワークの遵守を支援する機能も併せてご紹介します。",[10,11],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097688/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%286%29_6vL96ttKF8zJLLqfPpvFs_1750097687913.png",[13,23,24,25],"DevSecOps platform","product","financial services","2024-08-13","md",null,{},true,"/ja-jp/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features","---\nseo:\n  title: 金融サービス業界向け：GitLabの職務分離機能を実装する方法\n  description: >-\n    金融サービス業界において、GitLabの職務分離機能を活用して安全でコンプライアンスに準拠したソフトウェア開発を実現する方法をご説明します。また、規制フレームワークの遵守を支援する機能も併せてご紹介します。\n  ogTitle: 金融サービス業界向け：GitLabの職務分離機能を実装する方法\n  ogDescription: >-\n    金融サービス業界において、GitLabの職務分離機能を活用して安全でコンプライアンスに準拠したソフトウェア開発を実現する方法をご説明します。また、規制フレームワークの遵守を支援する機能も併せてご紹介します。\n  noIndex: false\n  ogImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097688/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%286%29_6vL96ttKF8zJLLqfPpvFs_1750097687913.png\n  ogUrl: >-\n    https://about.gitlab.com/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features\n  ogSiteName: https://about.gitlab.com\n  ogType: article\n  canonicalUrls: >-\n    https://about.gitlab.com/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features\ntitle: 金融サービス業界向け：GitLabの職務分離機能を実装する方法\ndescription: 金融サービス業界において、GitLabの職務分離機能を活用して安全でコンプライアンスに準拠したソフトウェア開発を実現する方法をご説明します。また、規制フレームワークの遵守を支援する機能も併せてご紹介します。\nauthors:\n  - Cherry Han\n  - Gavin Peltz\nheroImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097688/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%286%29_6vL96ttKF8zJLLqfPpvFs_1750097687913.png\ntags:\n  - security\n  - DevSecOps platform\n  - product\n  - financial services\ncategory: security\ndate: '2024-08-13'\nslug: finserv-how-to-implement-gitlabs-separation-of-duties-features\nfeatured: false\ntemplate: BlogPost\n---\n\nソフトウェア開発の過程において、特に金融サービスのようなデータの完全性や規制の遵守が不可欠な業界では、強固なセキュリティとコンプライアンス対策が求められます。これらの基準を維持する上で重要な要素の1つが職務分離（SoD）です。SoDは、プロセス全体の管理を1人に割り当てないようにすることで、エラーや不正行為のリスクを軽減するアプローチです。SoDにより、ソフトウェア開発プロセスの完全性を損なう可能性のある外部からの悪意ある行為を防ぎ、ソフトウェアサプライチェーンにおけるリスクを軽減できます。\n\n## 金融サービス業界におけるSoDの重要性\n\n金融サービス業界では、SoDが機密情報の保護やコンプライアンス遵守の確保を実現する上で重要な役割を果たします。SoDは、金融サービス業界において戦略的に以下のようなメリットをがあります。\n\n* **リスク軽減**：職務を複数の役割に分担することで、システムの完全性や規制コンプライアンスの遵守を損なう可能性のあるエラー、不正行為、無許可のアクティビティのリスクを軽減します。\n* **責任の強化**：明確な職務分担により、1人の担当者がプロセス全体を一貫して管理することができなくなり、結果として透明性と責任意識が高まります。透明性と責任意識は、ステークホルダーや規制当局との信頼関係を維持する上で不可欠です。\n* **規制コンプライアンス**：SoDは、機密性の高い業務が監視と審査の下で行われることを保証する目的で、金融規制によって義務付けられています。これらの基準を遵守することで、ペナルティを回避できるだけでなく、組織の評判も保護されます。\n* **運用の強靭性**：意思決定と実行を分散することで、組織は人的ミスや悪意ある行為、および予期せぬ出来事によってもたらされる混乱の影響を受けにくくなります。\n\n## GitLabによる職務分離とベストプラクティス\nGitLabでは、DevSecOpsワークフロー全体を対象としたエンドツーエンドの職務分離機能を使用できます。\n\n![金融サービスのSoD - 画像1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097695/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097695697.png)\n\n上記の図は、SoDの原則を維持するために、マージリクエスト承認ポリシー、保護機能、ユーザー権限、コンプライアンスフレームワーク、監査イベントといった重要な要素がどのように統合され、連携しているかを示しています。各要素については、後続のセクションで安全かつコンプライアンスに準拠した開発環境の構築方法を解説する中で、詳述します。\n\n### マージリクエスト承認ポリシー\n\n金融サービス業界が直面する課題のひとつに、不正またはチェックされていない変更が統合されるのを防ぐ承認メカニズムの実装があります。ここで役立つのが[マージリクエスト承認ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/scan-result-policies/)です。このポリシーにより、セキュリティと開発の職務分離が強制され、デベロッパーが脆弱性を含むコード変更を自分で承認したり、開発チームが適切な監視なしにコードを本番環境に直接デプロイしたりすることを防止できます。\n\nポリシーを作成する際には、承認者として誰が適切であるかを検討することをおすすめします。承認者には、個人ユーザー、アプリケーションセキュリティチームなどのグループ、あるいはメンテナーといったロールタイプを指定できます。さらに制約を加えたい場合は、以下の主要なポリシー機能の使用をご検討ください。\n\n- 作成者による承認を防止：このポリシーにより、マージリクエストの作成者が自身の変更を承認できないようガードレールが設定されます。独立したレビューを求めることで、承認プロセスの客観性と公平性が維持されます。\n\n- コミットを追加したユーザーによる承認を防ぐ：マージリクエストにコミットを追加したユーザーも、承認を行うことができないようにします。これにより、変更に直接関わっていないチームメンバーによって検証が行われる、独立したレビューの原則がさらに強化されます。\n\n- 承認ルールの編集を防止：承認プロセスの整合性を維持するため、GitLabではプロジェクトやマージリクエストレベルで承認ルールの編集を管理者が禁止できます。これにより、一度定義された承認ポリシーが無断で変更されたり回避されたりしないよう保証されます。\n\n- 承認にユーザーパスワードを要求：追加のセキュリティ対策として、GitLabではマージリクエストを承認するユーザーに対して、パスワードの入力を求めることができます。\n\n職務分離を明確に維持するため、マージリクエスト承認ポリシーを含むセキュリティポリシーを格納するための専用の[トップレベルグループを別途作成](https://docs.gitlab.com/ja-jp/user/application_security/policies/#enforce-policies-globally-in-gitlab-dedicated-or-your-gitlab-self-managed-instance)することが推奨されます。この設定により、権限を継承するユーザーの数が最小限に抑えられ、ポリシー管理を厳格に制御できます。この専用グループから、目標に合う最上位グループレベルで[セキュリティポリシープロジェクトをリンク](https://docs.gitlab.com/ja-jp/user/application_security/policies/#link-to-a-security-policy-project)することで、ポリシー管理の手間を軽減し、開発環境全体で包括的なカバレッジを確保できます。\n\nまた、ポリシーがデフォルトで有効になっている場合、そのポリシーは関連するリンクされたグループ、サブグループ、および個別のプロジェクト内のすべてのプロジェクトに適用されることにも注意してください。より対象を絞ってポリシーを適用したい場合、GitLabは[コンプライアンスフレームワークラベル](https://docs.gitlab.com/ja-jp/user/group/compliance_frameworks/)を使用してポリシーの適用範囲を絞り込むことを推奨しています。厳格な規制に対応しているお客様の多くは、「SOX」や「PCI」などの規制要件に対応するコンプライアンスラベルを作成しています。また、このフレームワークへのリンクにより、[ネイティブコンプライアンスセンター](https://docs.gitlab.com/ja-jp/user/compliance/compliance_center/)でさまざまなユースケースに合わせたセキュリティポリシーを管理できるようになります。\n\n### コンプライアンスフレームワークと制御\n\n規制対象の業界に属するお客様は、大規模な組織においてコンプライアンスを維持する上で大きな課題に直面しています。手動のプロセスはエラーが生じやすく、チーム間でポリシーを一貫して適用し続けることが難しい場合もあります。\n\nGitLabのコンプライアンスフレームワークを使用することで、組織は予防措置の自動化と管理、リスクの体系的な管理、そして規制コンプライアンスのシームレスな適用を実現できます。これらのフレームワークによって、どのようなパイプラインでもセキュリティプロトコルやカスタムジョブを実施できます。\n\nコンプライアンス設定を組織レベルで保護するために、GitLabではグループまたはプロジェクトのオーナーのみがコンプライアンスフレームワークを追加または削除できるようになっています。この対策により、適切な権限レベルを持たない開発チームやマネージャーによるコンプライアンス設定の変更が防止され、セキュリティがさらに強化されます。なお、メンテナー権限を持つ個人がサブグループを作成できる場合、そのサブグループのオーナーとなりコンプライアンスフレームワークを変更できる点に注意してください。これを防ぐには、権限とグループの設定で[サブグループの作成者](https://docs.gitlab.com/ja-jp/user/group/subgroups/#change-who-can-create-subgroups)を制限してください。\n\n## SoDのための権限とロール\n\n金融サービス業界で職務分離を効果的に実施するには、明確かつ正確なアクセス制御の設定が不可欠です。GitLabには、あらかじめ定義されたロール（ゲスト、レポーター、デベロッパー、メンテナー、オーナーなど）による階層的な[権限モデル](https://docs.gitlab.com/ja-jp/user/permissions/)が備わっています。各ロールには特定の権限セットが割り当てられており、個人が業務を遂行する際に自身の権限の範囲を逸脱しないようになっています。これにより、利益相反やセキュリティリスクを抑えられます。GitLabでは[最小権限の原則](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/)に従ってロールを割り当てることを推奨しています。\n\n細かいニーズを持つ組織、特にGitLab Ultimateを使用している組織では、[カスタムロール](https://docs.gitlab.com/ja-jp/user/custom_roles/)を活用することで、さらに柔軟な対応が可能になります。これらのロールを使用することで、各組織の独自のワークフローやコンプライアンス要件に合わせた特定の権限を設定できます。担当者が相反するタスクを実行できなくなるため、SoDの強制に特に役立ちます。\n\n一般的なユースケースとして、デプロイロールが必要な場合があります。これは、デプロイの権限が必要な個人に対して、コードの編集やプッシュの権限は与えたくない場合に使用できます。こういった要件に対応するために、GitLabは[保護環境](https://docs.gitlab.com/ja-jp/ci/environments/protected_environments/#protecting-environments)を提供しています。保護環境を使用すると、[ジョブのデプロイ承認を受けたグループを招待](https://docs.gitlab.com/ja-jp/ci/environments/protected_environments/#deployment-only-access-to-protected-environments)し、ユーザーのロールをレポーターに限定できます。なお、デプロイジョブにはenvironmentキーワードを含める必要があります。この設定により、コードの編集権限がないユーザーがデプロイを実行できるようになり、コンプライアンス要件に準拠できます。\n\n組織においてロールと権限を慎重に定義し適用することで、安全かつコンプライアンスに準拠した開発環境を構築できます。ユーザー権限を広範に見直したい場合、[こちらのグループメンバーレポート](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/gitlab-group-member-report)を使用して各ロールのメンバー数を確認し、それに応じた次のステップを検討することが可能です。\n\n## 保護機能\nGitLabは、開発プロセスをより厳重にかんりできるようにするために「保護」機能を提供しています。これらの機能は、指定された担当者のみが重要な変更を行えるようにするために使用でき、SoDを維持するためには不可欠です。\n\n- 保護ブランチ：保護ブランチでは、誰がプッシュ、マージ、または強制プッシュを実行できるかが制限されます。権限を持つユーザーのみが変更を加えられるように制御でき、特に「main」や「production」のようなブランチで効果的です。\n- 保護Gitタグ：このタグを使用すると、タグの作成権限を持つユーザーを制御できます。タグの作成後に誤った更新や削除が発生しないよう防止され、バージョン管理の整合性が保たれます。\n- 保護環境：特定の環境、特に本番環境への無許可のアクセスを防ぐことは必須事項と言えます。保護環境では、適切な権限を持つユーザーのみがデプロイできるため、意図しない変更から環境を保護できます。これは前述のデプロイロール機能と関連しており、コードを編集せずにジョブをデプロイできるようになるため、コンプライアンスとセキュリティを確保できます。\n- 保護パッケージ：パッケージ保護ルールを使用することで、どのユーザーがパッケージに変更を加えられるかを制限できます。\nこれらの保護機能はすべて、SoDの原則に沿った安全でコンプライアンスに準拠した開発環境の維持に役立ちます。\n\n## 監査イベントとコンプライアンスセンター\nここまで承認ポリシー、コンプライアンスフレームワーク、ロール、保護機能について説明してきましたが、最後に、GitLabでこれらの実装をどのようにモニタリングおよび監査してコンプライアンスを遵守できるかについて解説します。GitLabの[監査イベント](https://docs.gitlab.com/ja-jp/user/compliance/audit_events/)では、ユーザーの活動やプロジェクトの変更など、オーナーや管理者向けに詳細なアクティビティ履歴を提供します。このログは、ユーザーアクションを追跡したり、無許可のアクティビティを検出したりする上で不可欠です。組織において[監査イベントストリーミング](https://docs.gitlab.com/ja-jp/user/compliance/audit_event_streaming/)を使用して監査イベントを外部システムにストリーミングすることで、リアルタイムでの分析やアラートが可能になります。これにより、改変や違反が検出され、迅速に修正できるようになります。\n\n[GitLabのコンプライアンスセンター](https://docs.gitlab.com/ja-jp/user/compliance/compliance_center/)は、コンプライアンスに関連するアクティビティを一元的に管理およびモニタリングできる場所です。ここではプロジェクトやグループ全体のコンプライアンス状況の概要を確認でき、マージリクエスト承認ルールやその他のポリシーの違反が強調表示されます。管理者は問題に迅速に対処し、あらかじめ定義されたコンプライアンス基準への準拠を確認できます。この一元化されたアプローチにより、コンプライアンス管理が簡素化され、高度なレベルでモニタリングと制御を行えます。\n\n> GitLabのSoDやコンプライアンスに関する考え方について詳しく知りたい方は、[Governステージに関するGitLabの製品方針](https://docs.gitlab.com/ja-jp/user/compliance/) と[GitLabのコンプライアンスドキュメント](https://docs.gitlab.com/ja-jp/administration/compliance/)をご覧ください。\n\n## その他のリソース\n\n- [GitLabのコンプライアンスとセキュリティポリシー管理で規制基準を遵守](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)\n- [GitLabを使ったGitLabの構築：セキュリティ認証ポートフォリオを拡充](https://about.gitlab.com/blog/building-gitlab-with-gitlab-expanding-our-security-certification-portfolio/)\n- [オンライン小売業者bol社、GitLabで拡大するコンプライアンスニーズに対応](https://about.gitlab.com/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab/)\n",{"title":5,"description":19,"ogTitle":5,"ogDescription":19,"noIndex":17,"ogImage":21,"ogUrl":34,"ogSiteName":35,"ogType":36,"canonicalUrls":34},"https://about.gitlab.com/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features","https://about.gitlab.com","article","ja-jp/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",[13,39,24,40],"devsecops-platform","financial-services",[13,23,24,25],"8aA-CfVZPxB_kSxj_hjIy5sxwT1fUBOfDz4yAgqisQU",{"logo":44,"freeTrial":49,"sales":54,"login":59,"items":64,"search":384,"minimal":417,"duo":434,"switchNav":443,"pricingDeployment":454},{"config":45},{"href":46,"dataGaName":47,"dataGaLocation":48},"/ja-jp/","gitlab logo","header",{"text":50,"config":51},"無料トライアルを開始",{"href":52,"dataGaName":53,"dataGaLocation":48},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp&glm_content=default-saas-trial/","free trial",{"text":55,"config":56},"お問い合わせ",{"href":57,"dataGaName":58,"dataGaLocation":48},"/ja-jp/sales/","sales",{"text":60,"config":61},"サインイン",{"href":62,"dataGaName":63,"dataGaLocation":48},"https://gitlab.com/users/sign_in/","sign in",[65,94,196,201,304,365],{"text":66,"config":67,"menu":69},"プラットフォーム",{"dataNavLevelOne":68},"platform",{"type":70,"columns":71},"cards",[72,78,86],{"title":66,"description":73,"link":74},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":75,"config":76},"プラットフォームを探索",{"href":77,"dataGaName":68,"dataGaLocation":48},"/ja-jp/platform/",{"title":79,"description":80,"link":81},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":82,"config":83},"GitLab Duoのご紹介",{"href":84,"dataGaName":85,"dataGaLocation":48},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":87,"description":88,"link":89},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":90,"config":91},"詳細はこちら",{"href":92,"dataGaName":93,"dataGaLocation":48},"/ja-jp/why-gitlab/","why gitlab",{"text":95,"left":30,"config":96,"menu":98},"製品",{"dataNavLevelOne":97},"solutions",{"type":99,"link":100,"columns":104,"feature":175},"lists",{"text":101,"config":102},"すべてのソリューションを表示",{"href":103,"dataGaName":97,"dataGaLocation":48},"/ja-jp/solutions/",[105,130,153],{"title":106,"description":107,"link":108,"items":113},"自動化","CI/CDと自動化でデプロイを加速",{"config":109},{"icon":110,"href":111,"dataGaName":112,"dataGaLocation":48},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[114,118,121,126],{"text":115,"config":116},"CI/CD",{"href":117,"dataGaLocation":48,"dataGaName":115},"/ja-jp/solutions/continuous-integration/",{"text":79,"config":119},{"href":84,"dataGaLocation":48,"dataGaName":120},"gitlab duo agent platform - product menu",{"text":122,"config":123},"ソースコード管理",{"href":124,"dataGaLocation":48,"dataGaName":125},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":127,"config":128},"自動化されたソフトウェアデリバリー",{"href":111,"dataGaLocation":48,"dataGaName":129},"Automated software delivery",{"title":131,"description":132,"link":133,"items":138},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":134},{"href":135,"dataGaName":136,"dataGaLocation":48,"icon":137},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[139,143,148],{"text":140,"config":141},"アプリケーションセキュリティテスト",{"href":135,"dataGaName":142,"dataGaLocation":48},"Application security testing",{"text":144,"config":145},"ソフトウェアサプライチェーンの安全性",{"href":146,"dataGaLocation":48,"dataGaName":147},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":149,"config":150},"ソフトウェアコンプライアンス",{"href":151,"dataGaName":152,"dataGaLocation":48},"/ja-jp/solutions/software-compliance/","software compliance",{"title":154,"link":155,"items":160},"測定",{"config":156},{"icon":157,"href":158,"dataGaName":159,"dataGaLocation":48},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[161,165,170],{"text":162,"config":163},"可視性と測定",{"href":158,"dataGaLocation":48,"dataGaName":164},"Visibility and Measurement",{"text":166,"config":167},"バリューストリーム管理",{"href":168,"dataGaLocation":48,"dataGaName":169},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":171,"config":172},"分析とインサイト",{"href":173,"dataGaLocation":48,"dataGaName":174},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":176,"type":99,"items":177},"GitLabが活躍する場所",[178,184,190],{"text":179,"config":180},"エンタープライズ",{"icon":181,"href":182,"dataGaLocation":48,"dataGaName":183},"Building","/ja-jp/enterprise/","enterprise",{"text":185,"config":186},"スモールビジネス",{"icon":187,"href":188,"dataGaLocation":48,"dataGaName":189},"Work","/ja-jp/small-business/","small business",{"text":191,"config":192},"公共部門",{"icon":193,"href":194,"dataGaLocation":48,"dataGaName":195},"Organization","/ja-jp/solutions/public-sector/","public sector",{"text":197,"config":198},"価格",{"href":199,"dataGaName":200,"dataGaLocation":48,"dataNavLevelOne":200},"/ja-jp/pricing/","pricing",{"text":202,"config":203,"menu":205},"リソース",{"dataNavLevelOne":204},"resources",{"type":99,"link":206,"columns":210,"feature":290},{"text":207,"config":208},"すべてのリソースを表示",{"href":209,"dataGaName":204,"dataGaLocation":48},"/ja-jp/resources/",[211,244,262],{"title":212,"items":213},"はじめに",[214,219,224,229,234,239],{"text":215,"config":216},"インストール",{"href":217,"dataGaName":218,"dataGaLocation":48},"/ja-jp/install/","install",{"text":220,"config":221},"クイックスタートガイド",{"href":222,"dataGaName":223,"dataGaLocation":48},"/ja-jp/get-started/","quick setup checklists",{"text":225,"config":226},"学ぶ",{"href":227,"dataGaLocation":48,"dataGaName":228},"https://university.gitlab.com/","learn",{"text":230,"config":231},"製品ドキュメント",{"href":232,"dataGaName":233,"dataGaLocation":48},"https://docs.gitlab.com/ja-jp/","product documentation",{"text":235,"config":236},"ベストプラクティスビデオ",{"href":237,"dataGaName":238,"dataGaLocation":48},"/ja-jp/getting-started-videos/","best practice videos",{"text":240,"config":241},"インテグレーション",{"href":242,"dataGaName":243,"dataGaLocation":48},"/ja-jp/integrations/","integrations",{"title":245,"items":246},"検索する",[247,252,257],{"text":248,"config":249},"お客様成功事例",{"href":250,"dataGaName":251,"dataGaLocation":48},"/ja-jp/customers/","customer success stories",{"text":253,"config":254},"ブログ",{"href":255,"dataGaName":256,"dataGaLocation":48},"/ja-jp/blog/","blog",{"text":258,"config":259},"リモート",{"href":260,"dataGaName":261,"dataGaLocation":48},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":263,"items":264},"つなげる",[265,270,275,280,285],{"text":266,"config":267},"GitLabサービス",{"href":268,"dataGaName":269,"dataGaLocation":48},"/ja-jp/services/","services",{"text":271,"config":272},"コミュニティ",{"href":273,"dataGaName":274,"dataGaLocation":48},"/community/","community",{"text":276,"config":277},"フォーラム",{"href":278,"dataGaName":279,"dataGaLocation":48},"https://forum.gitlab.com/","forum",{"text":281,"config":282},"イベント",{"href":283,"dataGaName":284,"dataGaLocation":48},"/events/","events",{"text":286,"config":287},"パートナー",{"href":288,"dataGaName":289,"dataGaLocation":48},"/ja-jp/partners/","partners",{"config":291,"text":294,"image":295,"link":299},{"background":292,"textColor":293},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":296,"config":297},"ソースプロモカード",{"src":298},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":300,"config":301},"最新情報を読む",{"href":302,"dataGaName":303,"dataGaLocation":48},"/ja-jp/the-source/","the source",{"text":305,"config":306,"menu":308},"会社情報",{"dataNavLevelOne":307},"company",{"type":99,"columns":309},[310],{"items":311},[312,317,323,325,330,335,340,345,350,355,360],{"text":313,"config":314},"GitLabについて",{"href":315,"dataGaName":316,"dataGaLocation":48},"/ja-jp/company/","about",{"text":318,"config":319,"footerGa":322},"採用情報",{"href":320,"dataGaName":321,"dataGaLocation":48},"/jobs/","jobs",{"dataGaName":321},{"text":281,"config":324},{"href":283,"dataGaName":284,"dataGaLocation":48},{"text":326,"config":327},"経営陣",{"href":328,"dataGaName":329,"dataGaLocation":48},"/company/team/e-group/","leadership",{"text":331,"config":332},"チーム",{"href":333,"dataGaName":334,"dataGaLocation":48},"/company/team/","team",{"text":336,"config":337},"ハンドブック",{"href":338,"dataGaName":339,"dataGaLocation":48},"https://handbook.gitlab.com/","handbook",{"text":341,"config":342},"投資家向け情報",{"href":343,"dataGaName":344,"dataGaLocation":48},"https://ir.gitlab.com/","investor relations",{"text":346,"config":347},"トラストセンター",{"href":348,"dataGaName":349,"dataGaLocation":48},"/ja-jp/security/","trust center",{"text":351,"config":352},"AI Transparency Center",{"href":353,"dataGaName":354,"dataGaLocation":48},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":356,"config":357},"ニュースレター",{"href":358,"dataGaName":359,"dataGaLocation":48},"/company/contact/#contact-forms","newsletter",{"text":361,"config":362},"プレス",{"href":363,"dataGaName":364,"dataGaLocation":48},"/press/","press",{"text":55,"config":366,"menu":367},{"dataNavLevelOne":307},{"type":99,"columns":368},[369],{"items":370},[371,374,379],{"text":55,"config":372},{"href":57,"dataGaName":373,"dataGaLocation":48},"talk to sales",{"text":375,"config":376},"サポートを受ける",{"href":377,"dataGaName":378,"dataGaLocation":48},"https://support.gitlab.com","support portal",{"text":380,"config":381},"カスタマーポータル",{"href":382,"dataGaName":383,"dataGaLocation":48},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":385,"login":386,"suggestions":393},"閉じる",{"text":387,"link":388},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":389,"config":390},"GitLab.com",{"href":62,"dataGaName":391,"dataGaLocation":392},"search login","search",{"text":394,"default":395},"提案",[396,398,403,405,409,413],{"text":79,"config":397},{"href":84,"dataGaName":79,"dataGaLocation":392},{"text":399,"config":400},"コード提案（AI）",{"href":401,"dataGaName":402,"dataGaLocation":392},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":115,"config":404},{"href":117,"dataGaName":115,"dataGaLocation":392},{"text":406,"config":407},"GitLab on AWS",{"href":408,"dataGaName":406,"dataGaLocation":392},"/ja-jp/partners/technology-partners/aws/",{"text":410,"config":411},"GitLab on Google Cloud",{"href":412,"dataGaName":410,"dataGaLocation":392},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":414,"config":415},"GitLabを選ぶ理由",{"href":92,"dataGaName":416,"dataGaLocation":392},"Why GitLab?",{"freeTrial":418,"mobileIcon":422,"desktopIcon":427,"secondaryButton":430},{"text":50,"config":419},{"href":420,"dataGaName":53,"dataGaLocation":421},"https://gitlab.com/-/trials/new/","nav",{"altText":423,"config":424},"GitLabアイコン",{"src":425,"dataGaName":426,"dataGaLocation":421},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":423,"config":428},{"src":429,"dataGaName":426,"dataGaLocation":421},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":212,"config":431},{"href":432,"dataGaName":433,"dataGaLocation":421},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/get-started/","get started",{"freeTrial":435,"mobileIcon":439,"desktopIcon":441},{"text":436,"config":437},"GitLab Duoの詳細について",{"href":84,"dataGaName":438,"dataGaLocation":421},"gitlab duo",{"altText":423,"config":440},{"src":425,"dataGaName":426,"dataGaLocation":421},{"altText":423,"config":442},{"src":429,"dataGaName":426,"dataGaLocation":421},{"button":444,"mobileIcon":449,"desktopIcon":451},{"text":445,"config":446},"/switch",{"href":447,"dataGaName":448,"dataGaLocation":421},"#contact","switch",{"altText":423,"config":450},{"src":425,"dataGaName":426,"dataGaLocation":421},{"altText":423,"config":452},{"src":453,"dataGaName":426,"dataGaLocation":421},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":455,"mobileIcon":460,"desktopIcon":462},{"text":456,"config":457},"価格ページに戻る",{"href":199,"dataGaName":458,"dataGaLocation":421,"icon":459},"back to pricing","GoBack",{"altText":423,"config":461},{"src":425,"dataGaName":426,"dataGaLocation":421},{"altText":423,"config":463},{"src":429,"dataGaName":426,"dataGaLocation":421},{"title":465,"button":466,"config":471},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":467,"config":468},"6月10日のGitLab Transcendに申し込む",{"href":469,"dataGaName":470,"dataGaLocation":48},"/ja-jp/releases/whats-new/#sign-up","transcend event",{"layout":472,"icon":473,"disabled":17},"release","AiStar",{"data":475},{"text":476,"source":477,"edit":483,"contribute":488,"config":493,"items":498,"minimal":700},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":478,"config":479},"ページのソースを表示",{"href":480,"dataGaName":481,"dataGaLocation":482},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":484,"config":485},"このページを編集",{"href":486,"dataGaName":487,"dataGaLocation":482},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":489,"config":490},"ご協力をお願いします",{"href":491,"dataGaName":492,"dataGaLocation":482},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":494,"facebook":495,"youtube":496,"linkedin":497},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[499,544,597,639,666],{"title":197,"links":500,"subMenu":515},[501,505,510],{"text":502,"config":503},"プランの表示",{"href":199,"dataGaName":504,"dataGaLocation":482},"view plans",{"text":506,"config":507},"Premiumを選ぶ理由",{"href":508,"dataGaName":509,"dataGaLocation":482},"/ja-jp/pricing/premium/","why premium",{"text":511,"config":512},"Ultimateを選ぶ理由",{"href":513,"dataGaName":514,"dataGaLocation":482},"/ja-jp/pricing/ultimate/","why ultimate",[516],{"title":55,"links":517},[518,520,522,524,529,534,539],{"text":55,"config":519},{"href":57,"dataGaName":58,"dataGaLocation":482},{"text":375,"config":521},{"href":377,"dataGaName":378,"dataGaLocation":482},{"text":380,"config":523},{"href":382,"dataGaName":383,"dataGaLocation":482},{"text":525,"config":526},"ステータス",{"href":527,"dataGaName":528,"dataGaLocation":482},"https://status.gitlab.com/","status",{"text":530,"config":531},"利用規約",{"href":532,"dataGaName":533,"dataGaLocation":482},"/terms/","terms of use",{"text":535,"config":536},"プライバシーに関する声明",{"href":537,"dataGaName":538,"dataGaLocation":482},"/ja-jp/privacy/","privacy statement",{"text":540,"config":541},"Cookie 優先設定",{"dataGaName":542,"dataGaLocation":482,"id":543,"isOneTrustButton":30},"cookie preferences","ot-sdk-btn",{"title":95,"links":545,"subMenu":554},[546,550],{"text":547,"config":548},"DevSecOpsプラットフォーム",{"href":77,"dataGaName":549,"dataGaLocation":482},"devsecops platform",{"text":551,"config":552},"AI支援開発",{"href":84,"dataGaName":553,"dataGaLocation":482},"ai-assisted development",[555],{"title":556,"links":557},"トピック",[558,562,567,572,577,582,587,592],{"text":115,"config":559},{"href":560,"dataGaName":561,"dataGaLocation":482},"/ja-jp/topics/ci-cd/","cicd",{"text":563,"config":564},"GitOps",{"href":565,"dataGaName":566,"dataGaLocation":482},"/ja-jp/topics/gitops/","gitops",{"text":568,"config":569},"DevOps",{"href":570,"dataGaName":571,"dataGaLocation":482},"/ja-jp/topics/devops/","devops",{"text":573,"config":574},"バージョン管理",{"href":575,"dataGaName":576,"dataGaLocation":482},"/ja-jp/topics/version-control/","version control",{"text":578,"config":579},"DevSecOps",{"href":580,"dataGaName":581,"dataGaLocation":482},"/ja-jp/topics/devsecops/","devsecops",{"text":583,"config":584},"クラウドネイティブ",{"href":585,"dataGaName":586,"dataGaLocation":482},"/ja-jp/topics/cloud-native/","cloud native",{"text":588,"config":589},"コーディングのためのAI",{"href":590,"dataGaName":591,"dataGaLocation":482},"/ja-jp/topics/devops/ai-for-coding/","ai for coding",{"text":593,"config":594},"エージェント型AI",{"href":595,"dataGaName":596,"dataGaLocation":482},"/ja-jp/topics/agentic-ai/","agentic ai",{"title":598,"links":599},"ソリューション",[600,603,605,610,614,617,620,623,625,627,630,635],{"text":140,"config":601},{"href":135,"dataGaName":602,"dataGaLocation":482},"Application Security Testing",{"text":127,"config":604},{"href":111,"dataGaName":112,"dataGaLocation":482},{"text":606,"config":607},"アジャイル開発",{"href":608,"dataGaName":609,"dataGaLocation":482},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":611,"config":612},"SCM",{"href":124,"dataGaName":613,"dataGaLocation":482},"source code management",{"text":115,"config":615},{"href":117,"dataGaName":616,"dataGaLocation":482},"continuous integration & delivery",{"text":166,"config":618},{"href":168,"dataGaName":619,"dataGaLocation":482},"value stream management",{"text":563,"config":621},{"href":622,"dataGaName":566,"dataGaLocation":482},"/ja-jp/solutions/gitops/",{"text":179,"config":624},{"href":182,"dataGaName":183,"dataGaLocation":482},{"text":185,"config":626},{"href":188,"dataGaName":189,"dataGaLocation":482},{"text":628,"config":629},"公共機関",{"href":194,"dataGaName":195,"dataGaLocation":482},{"text":631,"config":632},"教育",{"href":633,"dataGaName":634,"dataGaLocation":482},"/ja-jp/solutions/education/","education",{"text":636,"config":637},"金融サービス",{"href":638,"dataGaName":25,"dataGaLocation":482},"/ja-jp/solutions/finance/",{"title":202,"links":640},[641,643,645,647,650,652,654,656,658,660,662,664],{"text":215,"config":642},{"href":217,"dataGaName":218,"dataGaLocation":482},{"text":220,"config":644},{"href":222,"dataGaName":223,"dataGaLocation":482},{"text":225,"config":646},{"href":227,"dataGaName":228,"dataGaLocation":482},{"text":230,"config":648},{"href":232,"dataGaName":649,"dataGaLocation":482},"docs",{"text":253,"config":651},{"href":255,"dataGaName":256,"dataGaLocation":482},{"text":248,"config":653},{"href":250,"dataGaName":251,"dataGaLocation":482},{"text":258,"config":655},{"href":260,"dataGaName":261,"dataGaLocation":482},{"text":266,"config":657},{"href":268,"dataGaName":269,"dataGaLocation":482},{"text":271,"config":659},{"href":273,"dataGaName":274,"dataGaLocation":482},{"text":276,"config":661},{"href":278,"dataGaName":279,"dataGaLocation":482},{"text":281,"config":663},{"href":283,"dataGaName":284,"dataGaLocation":482},{"text":286,"config":665},{"href":288,"dataGaName":289,"dataGaLocation":482},{"title":305,"links":667},[668,670,672,674,676,678,680,684,689,691,693,695],{"text":313,"config":669},{"href":315,"dataGaName":307,"dataGaLocation":482},{"text":318,"config":671},{"href":320,"dataGaName":321,"dataGaLocation":482},{"text":326,"config":673},{"href":328,"dataGaName":329,"dataGaLocation":482},{"text":331,"config":675},{"href":333,"dataGaName":334,"dataGaLocation":482},{"text":336,"config":677},{"href":338,"dataGaName":339,"dataGaLocation":482},{"text":341,"config":679},{"href":343,"dataGaName":344,"dataGaLocation":482},{"text":681,"config":682},"Sustainability",{"href":683,"dataGaName":681,"dataGaLocation":482},"/sustainability/",{"text":685,"config":686},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":687,"dataGaName":688,"dataGaLocation":482},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":346,"config":690},{"href":348,"dataGaName":349,"dataGaLocation":482},{"text":356,"config":692},{"href":358,"dataGaName":359,"dataGaLocation":482},{"text":361,"config":694},{"href":363,"dataGaName":364,"dataGaLocation":482},{"text":696,"config":697},"現代奴隷制の透明性に関する声明",{"href":698,"dataGaName":699,"dataGaLocation":482},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":701},[702,704,707],{"text":530,"config":703},{"href":532,"dataGaName":533,"dataGaLocation":482},{"text":705,"config":706},"Cookieの設定",{"dataGaName":542,"dataGaLocation":482,"id":543,"isOneTrustButton":30},{"text":535,"config":708},{"href":537,"dataGaName":538,"dataGaLocation":482},[710,724],{"id":711,"title":10,"body":28,"config":712,"content":714,"description":28,"extension":718,"meta":719,"navigation":30,"path":720,"seo":721,"stem":722,"__hash__":723},"blogAuthors/en-us/blog/authors/cherry-han.yml",{"template":713},"BlogAuthor",{"name":10,"config":715},{"headshot":716,"ctfId":717},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750713473/ehktvdbix2o1t0mmcvll.png","6gkuhRkgzCNP1Ee6J14yLu","yml",{},"/en-us/blog/authors/cherry-han",{},"en-us/blog/authors/cherry-han","423YS5YJhamDZ16wrw52ICoxcneLpTgjS66vce3TKcE",{"id":725,"title":11,"body":28,"config":726,"content":727,"description":28,"extension":718,"meta":731,"navigation":30,"path":732,"seo":733,"stem":734,"__hash__":735},"blogAuthors/en-us/blog/authors/gavin-peltz.yml",{"template":713},{"name":11,"config":728},{"headshot":729,"ctfId":730},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662831/Blog/Author%20Headshots/gavin_peltz.png","27UwgXDMqa0oBWV93rXTgN",{},"/en-us/blog/authors/gavin-peltz",{},"en-us/blog/authors/gavin-peltz","Expo-2S0aRtyigiH0p1b68iP-7NhMnFl5iUi637pn-g",[737,751,765],{"content":738,"config":749},{"heroImage":739,"body":740,"authors":741,"updatedDate":743,"date":744,"title":745,"tags":746,"description":748,"category":13},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773843921/rm35fx4gylrsu9alf2fx.png","GitLab 18.10では、脆弱性管理の品質とスピードの向上に焦点を当て、AIを活用したさまざまな新しいセキュリティ機能が導入されました。これらの機能を組み合わせることで、デベロッパーが誤検出の調査に費やす時間を削減し、自動修正をワークフローに直接組み込めるようになるため、セキュリティの専門知識がなくても脆弱性を修正できる環境が実現します。\n\n新機能の概要は以下のとおりです。\n\n* **[静的アプリケーションセキュリティテスト（SAST）の誤検出判定](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/false_positive_detection/)** **の一般提供が開始されました。** このフローでは、LLMによるエージェント型推論を使用して、脆弱性が誤検出である可能性を判定できるため、セキュリティチームと開発チームは重大な脆弱性の修正に優先的に取り組めるようになります。\n* **[エージェント型SAST脆弱性の修正](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/agentic_vulnerability_resolution/)** **がベータ版として提供開始されました。** エージェント型SAST脆弱性解決は、検証済みのSAST脆弱性に対する修正案を含むマージリクエストを自動的に作成します。修正までの時間が短縮され、高度なセキュリティ専門知識の必要になるケースが少なくなります。\n* **[シークレットの誤検出判定機能](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/secret_false_positive_detection/)** **がベータ版として提供開始されました。** このフローは、AIを活用したノイズ削減をシークレット検出にも適用し、ダミーやテスト用のシークレットにフラグを付けてレビューの負担を軽減します。\n\nこれらのフローは、GitLab Duo Agent Platformを使用するGitLab Ultimateのお客様にご利用いただけます。\n\n## SASTの誤検出判定機能でトリアージ時間を短縮\n\n従来のSASTスキャナーは、コードパスが到達可能かどうかや、フレームワークが既にリスクを処理しているかどうかに関係なく、疑わしいコードパターンにすべてフラグ付けしていました。ランタイムコンテキストがなければ、実際の脆弱性と危険に見えるだけの安全なコードを区別できません。\n\nそのため、デベロッパーは誤検出と判明するまで、検出結果の調査に何時間も費やす可能性がありました。時間の経過とともにレポートへの信頼が低下し、実際のリスクの修正を担当するチームの作業が遅延する原因となっていたのです。\n\n各SASTスキャンの後、GitLab Duo Agent Platformは新しい「致命的」と「高」の重大度の検出結果を自動的に分析し、以下の情報を付加します。\n\n* 検出結果が誤検出である可能性を示す信頼度スコア\n* AI生成による判定理由の説明\n* UIにより「誤検出の可能性が高い」と「実際の脆弱性の可能性が高い」を簡単に目視で識別できるバッジ\n\nこれらの検出結果は、以下のように[脆弱性レポート](https://docs.gitlab.com/ja-jp/user/application_security/vulnerability_report/)に表示されます。レポートをフィルタリングして「誤検出ではない」とマークされた検出結果を絞り込むことで、チームはノイズの選別ではなく実際の脆弱性への対応に時間を使えるようになります。\n\n![脆弱性レポート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773844787/i0eod01p7gawflllkgsr.png)\n\nGitLab Duo Agent Platformの評価はあくまで推奨事項です。すべての誤検出の判定はユーザーが管理でき、エージェントの推論をいつでも監査して信頼性の高いモデルを構築できます。\n\n## 脆弱性を自動修正に変換\n\n実際に脆弱性であると判明しても、まだ作業の半分が完了したにすぎません。修正には、コードパスの理解、安全なパッチの作成、他の部分への影響がないことの確認が必要です。\n\nSASTの誤検出判定フローによって脆弱性が誤検出ではない可能性が高いと判定された場合、エージェント型SAST脆弱性解決フローが自動的に以下を実行します。\n\n1. リポジトリから脆弱なコードとその周辺のコンテキストを読み取る\n2. 高品質な修正案を生成する\n3. 自動テストによって修正を検証する\n4. 以下を含む修正案のマージリクエストを作成する：\n\n   * 具体的なコード変更\n   * 信頼度スコア\n   * 変更内容とその理由の説明\n\nこのデモでは、GitLabがSAST脆弱性を検出からレビュー可能なマージリクエストまで自動的に処理する様子をご覧いただけます。エージェントがコードを読み取り、修正を生成・検証し、明確で説明可能な変更を含むMRを作成する流れをご確認ください。デベロッパーにセキュリティの専門知識がなくても、より迅速に修正を行えるようになります。\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1174573325?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab 18.10 AI SAST False Positive Auto Remediation\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\nAI生成の提案と同様に、マージを行う前に提案されたマージリクエストを慎重にレビューしてください。\n\n## 実際のシークレットを特定\n\nシークレット検出は、チームが結果を信頼できて初めて有用なものとなります。レポートにテスト用の認証情報やプレースホルダーの値、サンプルトークンが大量に含まれていると、デベロッパーは実際の漏洩を修正するよりも、ノイズのレビューに時間を浪費してしまう可能性があります。その結果、修正が遅延し、スキャンへの信頼が低下しかねません。\n\nシークレットの誤検出判定機能は、チームが重要なシークレットに集中し、より迅速にリスクを軽減できるよう支援します。この機能がデフォルトブランチで実行されると、自動的に以下が行われます。\n\n1. 各検出結果を分析し、テスト用の認証情報、サンプル値、ダミーシークレットの可能性を特定する\n2. 検出結果が実際のリスクか誤検出の可能性が高いかの信頼度スコアを付与する\n3. 実際のシークレット、ノイズのいずれかとして扱われる理由の説明を生成する\n4. 脆弱性レポートにバッジを追加し、デベロッパーがステータスを一目で確認できるようにする\n\nデベロッパーは、脆弱性レポートからシークレット検出の結果に対して「**誤検出を確認**」を選択することで、この分析を手動でトリガーすることもできます。リスクのない検出結果を除外し、実際のシークレットへの対応をより速やかに開始できます。\n\n## AIを活用したセキュリティ機能を今すぐお試しください\n\nGitLab 18.10では、SASTとシークレット検出における誤検出ノイズの削減から、修正案を含むマージリクエストの自動生成まで、脆弱性ワークフロー全体をカバーする機能が導入されました。\n\nAIを活用したセキュリティ機能がレビュー時間の短縮と検出結果のマージ可能な修正への変換にどのように役立つかをご確認いただくには、[GitLab Duo Agent Platformの無料トライアルを今すぐ開始](https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_gitlab-18-10-brings-ai-native-triage-and-remediation)してください。",[742],"Alisa Ho","2026-03-25","2026-03-19","GitLab 18.10がAIネイティブなトリアージと修正機能を導入",[24,13,747],"features","ノイズを排除して実際の脆弱性を特定し、修正案につなげるGitLab Duo Agent Platformの機能をご紹介します。",{"featured":17,"template":15,"slug":750},"gitlab-18-10-brings-ai-native-triage-and-remediation",{"content":752,"config":763},{"heroImage":753,"body":754,"authors":755,"updatedDate":757,"date":758,"title":759,"tags":760,"description":762,"category":13},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772721753/frfsm1qfscwrmsyzj1qn.png","コンテナの脆弱性は、次のデプロイメントを待ってくれるわけではありません。イメージのビルド時や、コンテナが本番環境で稼働している間など、あらゆるタイミングで発生する可能性があります。\nGitLab はこうした現実に対応するため、コンテナライフサイクルのさまざまな段階に対応した複数のコンテナスキャンアプローチを提供しています。\n\n本ガイドでは、GitLab が提供するコンテナスキャンの種類、各機能の有効化方法、および初期設定に役立つ一般的な構成についてご説明します。\n\n## コンテナスキャンが重要な理由\n\nコンテナイメージのセキュリティ脆弱性は、アプリケーションライフサイクル全体にわたってリスクをもたらします。ベースイメージ、OSパッケージ、アプリケーションの依存関係はいずれも、攻撃者が積極的に悪用する脆弱性を含んでいる可能性があります。コンテナスキャンはこれらのリスクを早期に、本番環境に到達する前に検出し、利用可能な場合は修正方法を提供します。\n\nコンテナスキャンはソフトウェアコンポジション分析（SCA）の重要なコンポーネントであり、コンテナ化されたアプリケーションが依存する外部依存関係を把握し、保護するために役立ちます。\n\n## GitLab コンテナスキャンの5つの種類\n\nGitLab は5つの異なるコンテナスキャンアプローチを提供しており、それぞれがセキュリティ戦略において固有の目的を果たします。\n\n### 1. パイプラインベースのコンテナスキャン\n\n* 機能：CI/CDパイプラインの実行中にコンテナイメージをスキャンし、デプロイ前に脆弱性を検出します。\n* 最適な用途：シフトレフトセキュリティ、脆弱性のあるイメージが本番環境に到達するのを防止\n* 利用可能なプラン：Free、Premium、Ultimate（Ultimateではより高度な機能を利用可能）\n* [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/)\n\nGitLab は Trivy セキュリティスキャナーを使用してコンテナイメージの既知の脆弱性を分析します。パイプラインの実行時にスキャナーがイメージを検査し、詳細なレポートを生成します。\n\n#### パイプラインベースのコンテナスキャンを有効にする方法\n\n**オプション A：事前設定済みのマージリクエスト**\n\n* プロジェクトで **Secure > セキュリティ設定** に移動します。\n* 「コンテナスキャン」の行を見つけます。\n* **マージリクエストで設定** を選択します。\n* 必要な設定を含むマージリクエストが自動的に作成されます。\n\n**オプション B：手動設定**\n\n* `.gitlab-ci.yml` に以下を追加します。\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n```\n\n#### 一般的な設定\n\n**特定のイメージをスキャンする：**\n\n特定のイメージをスキャンするには、`container_scanning` ジョブの `CS_IMAGE` 変数を上書きします。\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\ncontainer_scanning:\n  variables:\n    CS_IMAGE: myregistry.com/myapp:latest\n```\n\n**重大度のしきい値でフィルタリングする：**\n\n特定の重大度基準を持つ脆弱性のみを検出するには、`container_scanning` ジョブの `CS_SEVERITY_THRESHOLD` 変数を上書きします。以下の例では、重大度が **High** 以上の脆弱性のみが表示されます。\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\ncontainer_scanning:\n  variables:\n    CS_SEVERITY_THRESHOLD: \"HIGH\"\n```\n\n#### マージリクエストでの脆弱性の確認\n\nマージリクエスト内でコンテナスキャンの脆弱性を直接確認することで、セキュリティレビューをシームレスかつ効率的に実施できます。CI/CDパイプラインにコンテナスキャンを設定すると、GitLab はマージリクエストの[セキュリティウィジェット](https://docs.gitlab.com/ja-jp/user/project/merge_requests/widgets/#application-security-scanning)に検出された脆弱性を自動的に表示します。\n\n![マージリクエストに表示されたコンテナスキャンの脆弱性](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/lt6elcq6jexdhqatdy8l.png \"マージリクエストに表示されたコンテナスキャンの脆弱性\")\n\n* マージリクエストの「セキュリティスキャン」セクションまでスクロールすると、コンテナイメージで新たに検出された脆弱性と既存の脆弱性の概要が確認できます。\n* **脆弱性** をクリックすると、重大度レベル、影響を受けるパッケージ、利用可能な修正ガイダンスなど、検出内容の詳細情報にアクセスできます。\n\n![GitLab セキュリティ - MRでの詳細表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/hplihdlekc11uvpfih1p.png)\n\n![GitLab セキュリティ - MRでの詳細表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/jnxbe7uld8wfeezboifs.png \"MRでのコンテナスキャン脆弱性の詳細\")\n\nこの可視性により、開発者とセキュリティチームはコンテナの脆弱性が本番環境に到達する前に発見・対処できるようになり、セキュリティがコードレビュープロセスに統合されます。\n\n#### 脆弱性レポートでの脆弱性の確認\n\nマージリクエストのレビューに加え、GitLab はプロジェクト内のすべてのコンテナスキャン結果を一元的に確認できる[脆弱性レポート](https://docs.gitlab.com/ja-jp/user/application_security/vulnerability_report/)を提供しており、セキュリティチームに包括的な可視性をもたらします。\n\n![コンテナスキャンでフィルタリングされた脆弱性レポート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547524/gagau279fzfgjpnvipm5.png \"コンテナスキャンでフィルタリングされた脆弱性レポート\")\n\n* プロジェクトのサイドバーで **セキュリティとコンプライアンス > 脆弱性レポート** に移動してレポートにアクセスします。\n* ここでは、ブランチ全体で検出されたすべてのコンテナ脆弱性が集約されて表示され、重大度、ステータス、スキャナーの種類、特定のコンテナイメージでフィルタリングする強力なオプションが利用できます。\n* 脆弱性をクリックすると、脆弱性ページにアクセスできます。\n\n![脆弱性ページ - 1番目のビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547520/e1woxupyoajhrpzrlylj.png)\n\n![脆弱性ページ - 2番目のビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547521/idzcftcgjc8eryixnbjn.png)\n\n![脆弱性ページ - 3番目のビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547522/mbbwbbprtf9anqqola10.png \"コンテナスキャン脆弱性の詳細\")\n\n[脆弱性の詳細](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/)では、影響を受けるコンテナイメージとレイヤーが正確に示されるため、脆弱性の発生源を容易に追跡できます。脆弱性をチームメンバーに割り当て、ステータスを変更（検出済み、確認済み、解決済み、却下済み）し、コラボレーションのためのコメントを追加し、修正作業の追跡のために関連するイシューをリンクすることができます。\n\nこのワークフローにより、脆弱性管理がスプレッドシートによる管理から開発プロセスの一部へと変わり、コンテナセキュリティの検出結果が体系的に追跡・優先順位付け・解決されるようになります。\n\n#### 依存関係リストの確認\n\nGitLab の[依存関係リスト](https://docs.gitlab.com/ja-jp/user/application_security/dependency_list/)は、コンテナイメージ内のすべてのコンポーネントをカタログ化した包括的なソフトウェア部品表（SBOM）を提供し、ソフトウェアサプライチェーンの完全な透明性をもたらします。\n\n* **セキュリティとコンプライアンス > 依存関係リスト** に移動すると、プロジェクト全体でコンテナスキャンが検出したすべてのパッケージ、ライブラリ、依存関係のインベントリにアクセスできます。\n* このビューは、ベースOSパッケージからアプリケーションレベルの依存関係まで、コンテナ内で実際に稼働しているものを把握するために非常に役立ちます。\n\n![GitLab 依存関係リスト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/vjg6dk3nhajqamplroji.png \"GitLab 依存関係リスト（SBOM）\")\n\nパッケージマネージャー、ライセンスの種類、または脆弱性のステータスでリストをフィルタリングすることで、セキュリティリスクやコンプライアンス上の問題をもたらすコンポーネントを素早く特定できます。各依存関係エントリには関連する脆弱性が表示されるため、単独の検出結果としてではなく、実際のソフトウェアコンポーネントのコンテキストでセキュリティの問題を把握できます。\n\n### 2. レジストリ向けコンテナスキャン\n\n* 機能：`latest` タグで GitLab コンテナレジストリにプッシュされたイメージを自動的にスキャンします。\n* 最適な用途：手動のパイプラインを実行することなく、レジストリイメージの継続的なモニタリングを実施\n* 利用可能なプラン：Ultimate のみ\n* [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/#container-scanning-for-registry)\n\n`latest` タグが付いたコンテナイメージをプッシュすると、GitLab のセキュリティポリシーボットがデフォルトブランチに対してスキャンを自動的にトリガーします。パイプラインベースのスキャンとは異なり、このアプローチは継続的脆弱性スキャンと連携して、新たに公開されたアドバイザリーを監視します。\n\n#### レジストリ向けコンテナスキャンを有効にする方法\n\n1. **Secure > セキュリティ設定** に移動します。\n2. **レジストリ向けコンテナスキャン** セクションまでスクロールします。\n3. 機能をオンに切り替えます。\n\n![レジストリ向けコンテナスキャン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547512/vntrlhtmsh1ecnwni5ji.png \"レジストリ向けコンテナスキャンの切り替えスイッチ\")\n\n#### 前提条件\n\n* プロジェクトのメンテナーロール以上\n* プロジェクトが空でないこと（デフォルトブランチに少なくとも1つのコミットが必要）\n* コンテナレジストリの通知が設定済みであること\n* パッケージメタデータデータベースが設定済みであること（GitLab.com ではデフォルトで有効）\n\n脆弱性は脆弱性レポートの **コンテナレジストリの脆弱性** タブに表示されます。\n\n### 3. マルチコンテナスキャン\n\n* 機能：単一のパイプライン内で複数のコンテナイメージを並行してスキャンします。\n* 最適な用途：マイクロサービスアーキテクチャや複数のコンテナイメージを持つプロジェクト\n* 利用可能なプラン：Free、Premium、Ultimate（現在ベータ版）\n* [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/multi_container_scanning/)\n\nマルチコンテナスキャンは動的な子パイプラインを使用してスキャンを並行実行するため、複数のイメージをスキャンする際のパイプライン全体の実行時間を大幅に短縮できます。\n\n#### マルチコンテナスキャンを有効にする方法\n\n1. リポジトリのルートに `.gitlab-multi-image.yml` ファイルを作成します。\n\n```yaml\nscanTargets:\n  - name: alpine\n    tag: \"3.19\"\n  - name: python\n    tag: \"3.9-slim\"\n  - name: nginx\n    tag: \"1.25\"\n```\n\n2. `.gitlab-ci.yml` にテンプレートを追加します。\n\n```yaml\ninclude:\n  - template: Jobs/Multi-Container-Scanning.latest.gitlab-ci.yml\n```\n\n#### 詳細設定\n\n**プライベートレジストリからイメージをスキャンする：**\n\n```yaml\nauths:\n  registry.gitlab.com:\n    username: ${CI_REGISTRY_USER}\n    password: ${CI_REGISTRY_PASSWORD}\n\nscanTargets:\n  - name: registry.gitlab.com/private/image\n    tag: latest\n```\n\n**ライセンス情報を含める：**\n\n```yaml\nincludeLicenses: true\n\nscanTargets:\n  - name: postgres\n    tag: \"15-alpine\"\n```\n\n### 4. 継続的脆弱性スキャン\n\n* 機能：パイプラインを実行することなく、新しいセキュリティアドバイザリーが公開された際に自動的に脆弱性を作成します。\n* 最適な用途：デプロイ間のプロアクティブなセキュリティモニタリング\n* 利用可能なプラン：Ultimate のみ\n* [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/continuous_vulnerability_scanning/)\n\n従来のスキャンは、スキャン実行時の脆弱性しか検出できません。しかし、昨日スキャンしたパッケージに対して、明日新しい CVE が公開された場合はどうなるでしょうか。継続的脆弱性スキャンは、GitLab アドバイザリーデータベースを監視し、新しいアドバイザリーがコンポーネントに影響を与える際に自動的に脆弱性レコードを作成することでこの課題を解決します。\n\n#### 仕組み\n\n1. コンテナスキャンまたは依存関係スキャンジョブが CycloneDX SBOM を生成します。\n2. GitLab はこの SBOM からプロジェクトのコンポーネントを登録します。\n3. 新しいアドバイザリーが公開されると、GitLab はコンポーネントが影響を受けるかどうかを確認します。\n4. 脆弱性レポートに脆弱性が自動的に作成されます。\n\n#### 重要な考慮事項\n\n* スキャンは CI パイプラインではなく、バックグラウンドジョブ（Sidekiq）経由で実行されます。\n* 新しいコンポーネント検出には、過去14日以内に公開されたアドバイザリーのみが対象となります。\n* 脆弱性では「GitLab SBoM Vulnerability Scanner」がスキャナー名として使用されます。\n* 脆弱性を解決済みとしてマークするには、引き続きパイプラインベースのスキャンを実行する必要があります。\n\n### 5. 運用コンテナスキャン\n\n* 機能：スケジュールされた間隔で Kubernetes クラスター内の稼働中のコンテナをスキャンします。\n* 最適な用途：デプロイ後のセキュリティモニタリングとランタイム脆弱性の検出\n* 利用可能なプラン：Ultimate のみ\n* [ドキュメント](https://docs.gitlab.com/ja-jp/user/clusters/agent/vulnerabilities/)\n\n運用コンテナスキャンは、ビルド時のセキュリティとランタイムセキュリティの間のギャップを埋めます。GitLab Agent for Kubernetes を使用して、クラスター内で実際に稼働しているコンテナをスキャンし、デプロイ後に発生する脆弱性を検出します。\n\n#### 運用コンテナスキャンを有効にする方法\n\n[GitLab Kubernetes Agent](https://docs.gitlab.com/ja-jp/user/clusters/agent/install/) を使用している場合、エージェント設定ファイルに以下を追加できます。\n\n```yaml\ncontainer_scanning:\n  cadence: '0 0 * * *'  # 毎日深夜0時\n  vulnerability_report:\n    namespaces:\n      include:\n        - production\n        - staging\n```\n\nまた、GitLab Kubernetes Agent によるスケジュールスキャンを強制する[スキャン実行ポリシー](https://docs.gitlab.com/ja-jp/user/clusters/agent/vulnerabilities/#enable-via-scan-execution-policies)を作成することもできます。\n\n![スキャン実行ポリシー - 運用コンテナスキャン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547515/gsgvjcq4sas4dfc8ciqk.png \"運用コンテナスキャンのスキャン実行ポリシー条件\")\n\n#### 結果の確認\n\n* **運用 > Kubernetes クラスター** に移動します。\n* **エージェント** タブを選択し、エージェントを選択します。\n* **セキュリティ** タブを選択してクラスターの脆弱性を確認します。\n* 結果は **脆弱性レポート** の **運用上の脆弱性** タブにも表示されます。\n\n## GitLab セキュリティポリシーによるセキュリティ態勢の強化\n\nGitLab セキュリティポリシーを使用すると、自動化されたポリシー駆動型のコントロールを通じて、コンテナワークフロー全体で一貫したセキュリティ標準を適用できます。これらのポリシーは、要件を開発パイプラインに直接組み込むことでセキュリティをシフトレフトし、コードが本番環境に到達する前に脆弱性を検出・対処できるようにします。\n\n#### スキャン実行ポリシーとパイプラインポリシー\n\n[スキャン実行ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/scan_execution_policies/)は、プロジェクト全体でコンテナスキャンがいつ・どのように実行されるかを自動化します。すべてのマージリクエストでコンテナスキャンをトリガーし、メインブランチの定期的なスキャンをスケジュールするポリシーなどを定義できます。これらのポリシーにより、各プロジェクトの CI/CD パイプラインで手動でスキャンを設定することなく、包括的なカバレッジが確保されます。\n\n使用するスキャナーのバージョンを指定し、スキャンパラメーターを一元的に設定することで、新しいコンテナセキュリティの脅威に対応しながら組織全体の一貫性を維持できます。\n\n![スキャン実行ポリシーの設定](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/z36dntxslqem9udrynvx.png \"スキャン実行ポリシーの設定\")\n\n[パイプライン実行ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/pipeline_execution_policies/)は、コンプライアンス要件に基づいてパイプラインにカスタムジョブを注入（または上書き）するための柔軟なコントロールを提供します。\n\nこれらのポリシーを使用して、コンテナスキャンジョブをパイプラインに自動的に注入したり、コンテナの脆弱性がリスク許容度を超えた場合にビルドを失敗させたり、特定のブランチやタグに対して追加のセキュリティチェックをトリガーしたり、本番環境向けコンテナイメージのコンプライアンス要件を適用したりすることができます。パイプライン実行ポリシーは自動化されたガードレールとして機能し、手動操作なしですべてのコンテナデプロイメントにセキュリティ標準が一貫して適用されるようにします。\n\n![パイプライン実行ポリシー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/ddhhugzcr2swptgodof2.png \"パイプライン実行ポリシーのアクション\")\n\n#### マージリクエスト承認ポリシー\n\n[マージリクエスト承認ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/merge_request_approval_policies/)は、コンテナの脆弱性を含むマージリクエストを指定された承認者がレビューし、承認することを要求することでセキュリティゲートを適用します。\n\n重大度の高い脆弱性が検出された場合にマージをブロックするポリシーや、新しいコンテナの検出結果を導入するマージリクエストにセキュリティチームの承認を要求するポリシーを設定できます。これらのポリシーにより、低リスクな変更の開発速度を維持しながら、脆弱性のあるコンテナイメージがパイプラインを通じて進むことを防ぎます。\n\n![MRでブロックを実行するマージリクエスト承認ポリシー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/hgnbc1vl4ssqafqcyuzg.png \"MRでブロックを実行するマージリクエスト承認ポリシー\")\n\n## 適切なアプローチの選択\n\n| スキャンの種類   | 使用するタイミング   | 主なメリット                   |\n| --------- | ----------- | ------------------------ |\n| パイプラインベース | すべてのビルド時    | シフトレフトセキュリティ、脆弱なビルドをブロック |\n| レジストリスキャン | 継続的なモニタリング  | 保存されたイメージの新しい CVE を検出    |\n| マルチコンテナ   | マイクロサービス    | 並行スキャン、パイプラインの高速化        |\n| 継続的脆弱性    | デプロイ間       | プロアクティブなアドバイザリーモニタリング    |\n| 運用        | 本番環境のモニタリング | ランタイム脆弱性の検出              |\n\n包括的なセキュリティのためには、複数のアプローチを組み合わせることをお勧めします。開発中の問題を検出するためのパイプラインベースのスキャン、継続的なモニタリングのためのレジストリ向けコンテナスキャン、そして本番環境の可視性のための運用スキャンを組み合わせてご活用ください。\n\n## 今すぐ始める\n\nコンテナセキュリティへの最短ルートは、パイプラインベースのスキャンを有効にすることです。\n\n1. プロジェクトの **Secure > セキュリティ設定** に移動します。\n2. コンテナスキャンの **マージリクエストで設定** をクリックします。\n3. 作成されたマージリクエストをマージします。\n4. 次のパイプラインに脆弱性スキャンが含まれるようになります。\n\nその後、セキュリティ要件と GitLab のプランに応じて、追加のスキャンの種類を段階的に導入してください。\n\nコンテナセキュリティは一度実施すれば完了するものではなく、継続的なプロセスです。\nGitLab の包括的なコンテナスキャン機能を活用することで、ビルドからランタイムまでコンテナライフサイクルのあらゆる段階で脆弱性を検出できます。\n\n> GitLab がセキュリティ態勢の強化にどのように役立つかについての詳細は、[GitLab セキュリティ & ガバナンス ソリューションページ](https://about.gitlab.com/solutions/application-security-testing/)をご覧ください。",[756],"Fernando Diaz","2026-03-09","2026-03-05","GitLab コンテナスキャン完全ガイド：SBOM生成から運用監視まで5つのスキャン手法",[13,761],"tutorial","GitLab のさまざまなコンテナスキャン方法を詳しく解説し、コンテナライフサイクルの各段階でセキュリティを確保する方法をご紹介します。",{"slug":764,"featured":30,"template":15},"complete-guide-to-gitlab-container-scanning",{"content":766,"config":775},{"title":767,"description":768,"authors":769,"heroImage":771,"date":772,"body":773,"category":13,"tags":774},"GitLab.comのセキュリティ強化：多要素認証の必須化","Secure by Designへのコミットメントの一環として、GitLabが多要素認証（MFA）を必須化する方法と、それがユーザーに与える影響について解説します。",[770],"Kim Waters","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664923/Blog/Hero%20Images/security-checklist.png","2026-01-09","GitLab.comのすべてのユーザーアカウントのセキュリティ強化のため、GitLabでは、ユーザー名とパスワードを使用してサインインするすべてのユーザーとAPIエンドポイントに対して、多要素認証（MFA）を必須化します。\n\n## 多要素認証必須化の理由\n\n今回の変更は、GitLabの[Secure by Designへのコミットメント](https://about.gitlab.com/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/)における重要な取り組みの1つです。MFAは、ソフトウェア開発業界全体で継続的な脅威となっているクレデンシャルスタッフィング攻撃やアカウント乗っ取り攻撃に対する重要な防御手段となります。\n\n## 知っておくべき重要な情報\n\n### 何が変わるのか？\n\nGitLabは、ユーザー名とパスワードで認証するサインインに対して、MFAを必須化します。これにより、パスワードだけでなく、重要な第2の認証レイヤーが追加されます。\n\n### 適用されるケースとされないケース\n\n1. ***適用されるケース：*** ユーザー名とパスワードでGitLab.comにサインインする場合、またはパスワードを使用してAPIに認証する場合\n2. ***適用されないケース：*** アクセスにソーシャルサインオン（Googleなど）またはシングルサインオン（SSO）のみを使用している場合（*注意：SSOを使用していても、直接ログイン用のパスワードを設定している場合は、SSO以外のパスワードベースのログインに対してMFAが必要になります）*\n\n### ロールアウトのタイムライン\n\n1. 実装は今後数か月にわたって段階的に行われます。これは、ユーザーの予期しない中断や生産性の低下を最小限に抑え、アカウントのロックアウトを防ぐことを目的としています。ユーザーグループによって時期は異なりますが、近日中にMFAの有効化を求められます。各グループは、実行したアクション、またはコントリビュートしたコードに基づいて選択されます。以下の方法で通知されます。\n\n   * ✉️ メール通知 - 影響を受けるフェーズの前\n   * 🔔 定期的な製品内リマインダー - 14日前\n   * ⏱️ 一定期間後（メールが届きます） - MFAを有効にするまでGitLabへのアクセスがブロックされます\n\n### 必要な対応\n\n1. ユーザー名とパスワードでGitLab.comにサインインする場合：\n\n   * パスキー、認証アプリ、WebAuthnデバイス、またはメール認証など、利用可能なMFA方法の1つを今すぐ事前に設定することを強くおすすめします。これにより、最も安全でシームレスな移行が保証されます。\n   * GitLab.comの**ユーザー設定**にアクセスします。\n   * **アカウント**セクションを選択します。\n   * **2要素認証**を有効にし、希望する方法（認証アプリやWebAuthnデバイスなど）を設定します。\n   * 必要に応じてアクセスを回復できるよう、**リカバリーコードを安全に保存**してください。\n2. パスワードを使用してAPIに認証する場合：\n\n   * 個人アクセストークン（PAT）への切り替えを事前に行うことを強くおすすめします。詳細については、[ドキュメント](https://docs.gitlab.com/ja-jp/user/profile/account/two_factor_authentication_troubleshooting/#error-http-basic-access-denied-if-a-password-was-provided-for-git-authentication-)をご確認ください。\n\n## よくある質問\n\n*期限までにMFAを有効にしないとどうなりますか？*\n\n* サインインする前にMFAの設定が必要になります。\n\n*CI/CDパイプラインや自動化に影響はありますか？*\n\n* はい、パスワードの代わりにPATまたはデプロイトークンを使用していない場合は影響があります。\n\n*SSOを使用していますが、直接サインインすることもあります。その場合、MFAは必要ですか？*\n\n* はい、フォールバックシナリオを含む、パスワードベースの認証にはMFAが必要です。\n\n*どのようなMFAリカバリーオプションが利用できますか？*\n\n* [トラブルシューティングドキュメント](https://docs.gitlab.com/ja-jp/user/profile/account/two_factor_authentication_troubleshooting/#recovery-options-and-2fa-reset)をご確認ください。*\n\n具体的なタイムラインとその他のリソースについては、ロールアウト日までに段階的に共有される予定です。この重要な変更についてご覧いただき、ありがとうございます。",[13,24],{"featured":17,"template":15,"slug":776},"strengthening-gitlab-com-security-mandatory-multi-factor-authentication",{"promotions":778},[779,793,804,815],{"id":780,"categories":781,"header":783,"text":784,"button":785,"image":790},"ai-modernization",[782],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":786,"config":787},"Get your AI maturity score",{"href":788,"dataGaName":789,"dataGaLocation":256},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":791},{"src":792},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":794,"categories":795,"header":796,"text":784,"button":797,"image":801},"devops-modernization",[24,581],"Are you just managing tools or shipping innovation?",{"text":798,"config":799},"Get your DevOps maturity score",{"href":800,"dataGaName":789,"dataGaLocation":256},"/assessments/devops-modernization-assessment/",{"config":802},{"src":803},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":805,"categories":806,"header":807,"text":784,"button":808,"image":812},"security-modernization",[13],"Are you trading speed for security?",{"text":809,"config":810},"Get your security maturity score",{"href":811,"dataGaName":789,"dataGaLocation":256},"/assessments/security-modernization-assessment/",{"config":813},{"src":814},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":816,"paths":817,"header":820,"text":821,"button":822,"image":827},"github-azure-migration",[818,819],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":823,"config":824},"See how GitLab compares to GitHub",{"href":825,"dataGaName":826,"dataGaLocation":256},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":828},{"src":803},{"header":830,"blurb":831,"button":832,"secondaryButton":836},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":50,"config":833},{"href":834,"dataGaName":53,"dataGaLocation":835},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/ja-jp/","feature",{"text":55,"config":837},{"href":57,"dataGaName":58,"dataGaLocation":835},1777934948947]