[{"data":1,"prerenderedAt":720},["ShallowReactive",2],{"/en-us/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/":3,"navigation-en-us":37,"banner-en-us":465,"footer-en-us":482,"Fernando Diaz":692,"next-steps-en-us":705},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":16,"config":26,"_id":30,"_type":31,"title":32,"_source":33,"_file":34,"_stem":35,"_extension":36},"/en-us/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab","blog",false,"",{"title":9,"description":10,"ogTitle":9,"ogDescription":10,"noIndex":6,"ogImage":11,"ogUrl":12,"ogSiteName":13,"ogType":14,"canonicalUrls":12,"schema":15},"The ultimate guide to least privilege access with GitLab","This tutorial demonstrates how to achieve least privilege access using custom roles, security policies, compliance pipelines, branch protections, and more.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099438/Blog/Hero%20Images/Blog/Hero%20Images/built-in-security_built-in-security.jpeg_1750099438377.jpg","https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The ultimate guide to least privilege access with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-03-06\",\n      }",{"title":9,"description":10,"authors":17,"heroImage":11,"date":19,"body":20,"category":21,"tags":22},[18],"Fernando Diaz","2024-03-06","The principle of least privilege\n([PoLP](https://csrc.nist.gov/glossary/term/least_privilege)) is a concept\nin which a user's access rights should be limited to the bare minimum needed\nfor them to complete the tasks required within their respective roles. By\nimplementing PoLP you can enhance your organization's [security\nposture](https://csrc.nist.gov/glossary/term/security_posture),\ncomplementing zero trust, in the following ways:\n\n\n- **Reduction of attack surface:** If credentials are compromised, the\nbreach will be limited to only the paths where the compromised account has\naccess.\n\n- **Protection against human error:** Users will not be able to perform\nactions that are not required for their role.\n\n- **Adherence to compliance:** Separation of duties and least privilege best\npractices are required for several compliance mandates such as SOC2 and\nHIPAA.\n\n- **Reduced system downtime:** By preventing everyone from accessing\ncritical parts of the software development lifecycle (SDLC), there is less\nlikelihood of downtime.\n\n\nGitLab provides a variety of different features that allow you to customize\nthe actions a user can perform which assist in the achievement of PoLP.\nThese features include:\n\n\n- **[Custom roles and granular security\npermissions](#custom-roles-and-granular-security-permissions):** Allows\ncreation of roles with permissions that are specific to particular functions\nrequired by the organization.\n\n- **[Security policies](#security-policies):** Allows policies to be created\nthat prevent insecure code from being merged into production branches\nwithout approval, and run security scanners regardless of your pipeline\ndefinition.\n\n- **[Branch protections and Code\nOwners](#branch-protections-and-code-owners):** Imposes further restrictions\non certain branches to control permissions such as who can merge, push, etc.\nto defined branches.\n\n- **[Compliance pipelines and\nframeworks](#compliance-pipelines-and-frameworks):** Identifies that your\nproject has certain compliance requirements or needs additional oversight,\nenforcing a pipeline configuration to the projects on which it is applied.\n\n\nIn this blog post, you'll learn each of the features mentioned, how they\nimprove your organization's security posture, as well as how to implement\nthem.\n\n\nWatch my video, which introduces you to achieving PoLP with GitLab:\n\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/jvZ3eqWMeSY?si=DedSYiBNy2kTLJKo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\n## Custom roles and granular security permissions\n\n\nGitLab allows you to create [custom\nroles](https://docs.gitlab.com/ee/user/custom_roles.html), which apply\nadditional permissions to base roles to meet the security needs of your\norganization. The available [base\nroles](https://docs.gitlab.com/ee/user/permissions.html#roles) are as\nfollows:\n\n\n- Guest\n\n- Reporter\n\n- Developer\n\n- Maintainer\n\n- Owner\n\n\nEach base role applies a particular set of permissions to a user. Base roles\napply different permissions for [group\nmembers](https://docs.gitlab.com/ee/user/permissions.html#group-members-permissions),\n[project\nmembers](https://docs.gitlab.com/ee/user/permissions.html#project-members-permissions),\nand in [project\nfeatures](https://docs.gitlab.com/ee/user/permissions.html#project-features-permissions).\nFor example, the table below shows which roles can view the project\n[dependency\nlist](https://docs.gitlab.com/ee/user/application_security/dependency_list/):\n\n\n| Base role    | Can view project dependency list     |\n\n| ---------- | ---------- |\n\n| Guest      | ❌       |\n\n| Reporter      | ❌       |\n\n| Developer      | ✅       |\n\n| Maintainer      | ✅       |\n\n| Owner       | ✅     |\n\n\n\u003Cbr>\u003C/br>\n\nThe dependency list also known as a software bill of materials\n([SBOM](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)),\ndisplays your project's dependencies\n\nand key details about those dependencies. It makes sense that only those\nactively working on a project should\n\nbe able to see what dependencies are present to limit any exploitation of\nyour application using its dependencies.\n\n\nHowever, there are cases in which a Guest may need to see the SBOM to assist\nthe organization in\n\n[achieving\ncompliance](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/).\nBy using custom roles, a new role can be created with all the limited\npermissions of the Guest role, and additionally, the ability to view the\nproject dependency list can be added. Therefore, we have a Guest assisting\nus with compliance with the least privileged access required for their job.\n\n\nWatch my video on custom roles and granular security permissions with\nGitLab:\n\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/WyrhkpO5WkI?si=4B4mNYNK9UyNrru8\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\n### Granular permissions\n\n\nAs of the GitLab 16.8 release, the following granular permissions can be\nadded to any base role:\n\n\n- Viewing project code\n\n- Viewing vulnerability reports\n\n- Changing the status of vulnerabilities\n\n- Viewing SBOMs\n\n- Approving merge requests\n\n- Managing project/group access tokens\n\n- Adding/removing group members\n\n- Archiving/unarchiving/removing projects\n\n- Admin Terraform state\n\n\nWe will continue to add [more granular\npermissions](https://docs.gitlab.com/ee/user/custom_roles/abilities.html)\nwith each GitLab release. You can learn more about our roadmap for this\nfeature by referring to the [Granular Security Permissions\nEpic](https://gitlab.com/groups/gitlab-org/-/epics/10684) and provide\nfeedback in the [customer feedback\nIssue](https://gitlab.com/gitlab-org/gitlab/-/issues/391760). You also have\nthe ability to contribute to GitLab and [develop your own granular\npermissions](https://docs.gitlab.com/ee/development/permissions/custom_roles.html).\n\n\n### Implementation prerequisites\n\nThe requirements for implementing custom roles are as follows: \n\n- Owner role in the top-level group in which you are creating the custom\nrole\n\n- Administrator for the self-managed instance in which you are creating the\ncustom role\n\n- GitLab Ultimate tier in the top-level group\n\n- A [personal access token with the API\nscope](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token)\n\n\nTo see custom roles in action requires:\n\n- a private project within the top-level group or its subgroups\n\n- a guest user within the private project\n\n\nWhen you enable a custom role for a user with the Guest role, that user has\naccess to elevated permissions, and therefore:\n\n- is considered a billable user on self-managed GitLab\n\n- uses a seat on GitLab.com\n\n\n### Creating the custom role with granular permissions\n\n\nNow that you know the benefits of implementing custom roles with granular\npermissions, let's implement them within our GitLab instance:\n\n\n1. On the left sidebar, select **Search or go to**.\n    - In GitLab SaaS find and select the top-level group in which you want to create a custom role.\n    - In GitLab Self-Managed find and select **Admin Area**.\n2. Select **Settings > Roles and Permissions**.\n    - In GitLab Self-Managed use the top dropdown list to find and select the top-level group in which you want to create a custom role.\n3. Select **Add new role**.\n\n4. Under Base role to use as a template, select **Guest** for this tutorial.\n\n5. Under Role name, enter the custom role’s title.\n\n6. Under Permissions for the custom role, select **Read Vulnerability** for\nthis tutorial.\n\n7. Select **Create a new role**.\n\n\n![Create new role\nscreen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099455072.png)\n\n\n\u003Ccenter>\u003Ci>Interface for creating a custom role\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\nAfter creating the role you should be able to see the new custom role along\nwith its ID, Base role, and Permissions. Be sure to save the ID as it will\nbe used when we assign the custom role to a guest user.\n\n\n![Custom role\nscreen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099455073.png)\n\n\n\u003Ccenter>\u003Ci>Security Auditor role created\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p>\n\n\nNow we must assign the custom role to a group or project member. This can be\ndone as follows:\n\n1. Invite a user as a direct member with the Guest role to your top-level\ngroup where the custom role was created.\n\n2. You can invite them to a sub-group or private project within the\ntop-level group as well.\n\n* The guest user should not be able to see any code within the project they\nhave been assigned to.\n\n* Open your terminal.\n\n3. Export the required environment variables:\n\n* Your [personal access token with API\nscope](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token)\n\n\n```\n\n$ export TOKEN=glpat-XXXXXXXXXXXX\n\n$ echo $TOKEN\n\nglpat-XXXXXXXXXXXX\n\n\n```\n\n\n* The ID of the user we will be granting a custom role to. You can obtain\nthe user id by providing the username to the [User\nAPI](https://docs.gitlab.com/ee/api/users.html#list-users). For more\ninformation on using the GitLab API, see the [REST API\ndocumentation](https://docs.gitlab.com/ee/api/rest/).\n\n\n```\n\n$ curl \"https://gitlab.example.com/api/v4/users?username=fjdiaz\"\n\n[{\"id\":4710074,\"username\":\"fjdiaz\",\"name\":\"Fern\",\"state\":\"active\",\"locked\":false,\"avatar_url\":\"https://gitlab.com/uploads/-/system/user/avatar/4710074/avatar.png\",\"web_url\":\"https://gitlab.com/fjdiaz\"}]\n\n\n$ export USER_ID=4710074\n\n$ echo $USER_ID\n\n4710074\n\n```\n\n\n* The ID of the custom role. You can obtain the custom role ID from the ID\ncolumn in the [custom roles\nUI](https://docs.gitlab.com/ee/user/custom_roles.html#gitlab-saas) or the\n[member roles\nAPI](https://docs.gitlab.com/ee/api/member_roles.html#add-a-member-role-to-a-group).\n\n\n```\n\n$ export CUSTOM_ROLE_ID=1000782\n\n$ echo $CUSTOM_ROLE_ID\n\n1000782\n\n```\n\n\n* The ID of your group or project. You can obtain the group id from the\n[group UI](https://docs.gitlab.com/ee/user/group/#get-the-group-id) or using\nthe [groups API](https://docs.gitlab.com/ee/api/groups.html). You can obtain\nthe project ID from the [project\nUI](https://docs.gitlab.com/ee/user/project/working_with_projects.html#access-the-project-overview-page-by-using-the-project-id)\nor using the [projects API](https://docs.gitlab.com/ee/api/projects.html).\n\n\n```\n\n$ export GROUP_ID=10087220\n\n$ echo $GROUP_ID\n\n10087220\n\n\n$ export PROJECT_ID=45738177\n\n$ echo $PROJECT_ID\n\n45738177\n\n```\n\n\n4. Associate the guest user with the custom role using the appropriate\n[group or project\nAPIs](https://docs.gitlab.com/ee/api/members.html#edit-a-member-of-a-group-or-project).\n\n\n* If the user just needs to role in a project, update the project\nmembership:\n\n\n```\n\n\"Authorization: Bearer $TOKEN\" --data '{\"member_role_id\": $CUSTOM_ROLE_ID,\n\"access_level\": 10}'\n\"https://gitlab.example.com/api/v4/projects/$PROJECT_ID/members/$USER_ID\"\n\n```\n\n\n* If the user just needs to role in a group, update the group membership:\n\n\n```\n\n$ curl --request PUT --header \"Content-Type: application/json\" --header\n\"Authorization: Bearer $TOKEN\" --data '{\"member_role_id\": $CUSTOM_ROLE_ID,\n\"access_level\": 10}'\n\"https://gitlab.example.com/api/v4/groups/$GROUP_ID/members/$USER_ID\"\n\n```\n\n\nNow that the custom role has been applied to a guest user, when they login,\nthey can see the Vulnerability dashboard present in the Secure tab. Notice,\nhowever, that they are still not allowed to see the source code. \n\n\nThis is useful because it allows users to audit the system without being\nable to make changes to the code base, which applies the PoLP for those\nauditing the system for vulnerabilities.\n\n\n## Security policies\n\nGitLab provides [security\npolicies](https://docs.gitlab.com/ee/user/application_security/policies/) to\nhelp you achieve least privilege access. There are two different types of\nsecurity policies provided by GitLab:\n\n- [Scan Execution\npolicies](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html)\nallow project maintainers and administrators the confidence of knowing that\nthe scans they set up have not been changed, altered, or disabled.\n\n- [Merge Request Approval\npolicies](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html)\nprevent insecure code from being merged into production without appropriate\napproval.\n\n\nSome examples of how both policy types can be used in unison to provide\nleast privilege access are as follows:\n\n- remove the ability for developers to disable security scanners\n\n- remove the ability for developers to merge insecure code\n\n\nPolicies are stored in a separate repo from the project they are being\napplied to called the Security Policy Project (SPP). This allows for\nseparate permissions to be set to the SPP vs. the application repo, thus\nstrengthening your ability to separate duties and apply PoLP.\n\n\n![Security policy\nhierarchy](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image19_aHR0cHM6_1750099455074.png)\n\n\n\u003Ccenter>\u003Ci>Security policy hierarchy\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\nTo enforce the policies contained in an SPP you link it to a project,\nsubgroup, group, or multiples of each. An SPP can contain multiple policies\nbut they are enforced together. An SPP enforced on a group or subgroup\napplies to everything below the hierarchy, including all subgroups and their\nprojects.\n\n\nSecurity policies can be managed via the policy management UI as well as via\nyaml. Using the policy editor you can create, edit, and delete policies.\n\n\n![Policy management\ninterface](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image20_aHR0cHM6_1750099455076.png)\n\n\n\u003Ccenter>\u003Ci>Policy management interface\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\nFeel free to leverage the [Simple Notes demo\nenvironment](https://gitlab.com/gitlab-de/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\nto try this yourself by following the provided [DevSecOps\ntutorial](https://gitlab-de.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/).\n\n\n### Creating a Scan Execution policy\n\nNow let's take a look at how to create a Scan Execution policy. Before\ngetting started make sure you have met the following criteria:\n\n- GitLab Ultimate tier in the top-level group\n\n- Owner role to create/assign an SPP\n\n- Developer role or greater to create/edit/delete individual security\npolicies\n\n\nWe will be creating a policy that automatically runs a SAST scan with each\npipeline, regardless of the SAST template is defined within the\ngitlab-ci.yml:\n\n\n1. On the left sidebar, select **Search or go to** and search for the\nproject to which you wish to add a policy.\n\n2. On the project left sidebar, go to **Secure > Policies**.\n\n3. Select **New policy**.\n\n4.  In the **Scan Execution Policy** section, select **Select policy**.\n\n5. Complete the fields:\n    - **Name:** The name of the policy\n    - **Description:** The description of the Policy\n    - **Policy status:** Whether it is enabled or not\n    - **Actions:** What actions to take when the defined conditions are met\n\n![Scan Execution policy\nactions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image15_aHR0cHM6_1750099455077.png)\n\n \u003Ccenter>\u003Ci>Scan Execution policy actions\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n  - **Conditions:** Conditions which must be met (a pipeline is triggered or on a set schedule) in order for an action to take place.\n\n    ![Scan Execution policy conditions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750099455078.png)\n \u003Ccenter>\u003Ci>Scan Execution policy conditions\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n- Press the **Configure with a merge request** button.\n\n\nNow that the policy has been created, all we need to do is run a pipeline to\nsee that SAST will be present even if it is not defined in the\n.gitlab-ci.yml.\n\n\n### Creating a Merge Request Approval policy\n\n\nNow let's take a look at how to create a Merge Request Approval policy.\nBefore getting started make sure you have met the following criteria:\n\n- GitLab Ultimate tier in the top-level group\n\n- Owner role to create/assign an SPP\n\n- Developer role or greater to create/edit/delete individual security\npolicies\n\n- Security scanners added to project\n\n\nWe will be creating a policy that requires approval from project maintainers\nif any security scanner detects a vulnerability when compared with any\nbranch:\n\n\n1. On the left sidebar, select **Search or go to** and search for the\nproject to which you wish to add a policy.\n\n2. On the project left sidebar, go to **Secure > Policies**\n\n3. Select **New policy**\n\n4. In the **Merge Request Approval policy** section, select **Select\npolicy**.\n\n5. Complete the fields:\n    - **Name:** The name of the policy\n    - **Description:** The description of the policy\n    - **Policy status:** Whether it is enabled or not\n    - **Rules:** The conditions which must be met for an action (require approval) to take place.\n\n![Merge Request Approval policy\nrules](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image17_aHR0cHM6_1750099455079.png)\n\n\n\u003Ccenter>\u003Ci>Merge Request Approval policy rules\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n   - **Actions:** The action to be taken whenever the conditions in the rules (defined vulnerabilities/licenses detected) are met.\n\n![Merge Request Approval  policy\nactions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750099455080.png)\n\n\u003Ccenter>\u003Ci>Merge Request Approval  policy actions\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n   - **Override project approval settings:** If selected, the following choices will overwrite project settings but only affect the branches selected in the policy.\n\n![Merge Request Approval policy approval\nsettings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image21_aHR0cHM6_1750099455081.png)\n\n\n\u003Ccenter>\u003Ci>Merge Request Approval policy approval\nsettings\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\n6. Press the **Configure with a merge request** button.\n\n\nNow that the policy has been created, all we need to do is run a pipeline\nand if SAST detects any vulnerabilities then approvals will be required from\nthe selected approver before the code change can be merged. Merge Request\nApproval policies can be used with all GitLab security scanners, including\nlicense scanning.\n\n\n![Merge Request Approval policies blocking code from being merged in an\nMR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099455082.png)\n\n\n\u003Ccenter>\u003Ci>Merge Request Approval policies blocking code from being merged\nin an MR\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\n## Branch protections and Code Owners\n\n[Branch\nprotections](https://docs.gitlab.com/ee/user/project/protected_branches.html)\nallow you to impose additional restrictions on particular branches within\nyour repository. This further strengthens the PoLP for the interactions on a\nparticular set of branches. \n\n\nFor example, a protected branch can control:\n\n- which users can merge into the branch\n\n- which users can push to the branch\n\n- if users can force push to the branch\n\n- if changes to files listed in the CODEOWNERS file can be pushed directly\nto the branch\n\n- which users can unprotect the branch\n\n\n### Applying branch protections\n\n\nBranch protections are available in all tiers and offerings of GitLab.\nBranch protections can be applied to a single project or a group of\nprojects. You can apply branch protections for required roles to push and\nmerge as follows:\n\n\n1. On the left sidebar, select **Search or go to** and find your project or\ngroup.\n\n2. Select **Settings > Repository**.\n\n3. Expand **Protected branches**.\n\n4. Select **Add protected branch**.\n    - For groups, from the **Branch** text box, type the branch name or a wildcard.\n    - For projects, from the **Branch** dropdown list, select the branch you want to protect.\n5. From the **Allowed to merge** list, select a role that can merge into\nthis branch.\n\n6. From the **Allowed to push and merge** list, select a role that can push\nto this branch.\n\n7. Select **Protect**.\n\n\nYou should now see the protected branch added to the list.\n\n\n![Protected branches\nsettings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image14_aHR0cHM6_1750099455082.png)\n\n\n\u003Ccenter>\u003Ci>Protected branches settings\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\nThe Owner role is required to add branch protections to a group and the\nMaintainer role or greater is required to add branch protections to a\nproject.\n\n\n### Code Owners\n\nIf you want to further limit what files developers can perform changes on,\none of the best features to implement is [Code\nOwners](https://docs.gitlab.com/ee/user/project/codeowners/). Code Owners\nallows you to define who has the expertise for specific parts of your\nproject’s codebase. Defining the owners of files and directories in Code\nOwners will:\n\n\n- require owners to approve changes as well as merge requests before they\nmerge into a protected branch\n\n- identify owners by displaying the Code Owner names on the files and\ndirectories they own\n\n\nTo set up Code Owners, follow these steps:\n\n1. Create a CODEOWNERS file in your preferred location.\n\n2. Define some rules in the file following the Code Owners syntax reference.\nYou can configure all eligible approvers' approval rules and require Code\nOwner approval on a protected branch.\n\n3. Commit your changes, and push them up to GitLab.\n\n\nNow, when looking at files, you can see who the Code Owners are for a\nparticular file.\n\n\n![Code Owners displayed for\nfile](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750099455083.png)\n\n\n\u003Ccenter>\u003Ci>Code Owners displayed for file\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\nIf you implement Code Owner approvals, then when creating a merge request,\nthe Code Owners must approve before the code can be merged.\n\n\n![Code Owners\napprovals](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750099455084.png)\n\n\n\u003Ccenter>\u003Ci>Code Owners approvals\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\n### Additional approval settings\n\nThere are additional approval settings that can be applied before code can\nbe committed with a merge request. These additional approval settings are as\nfollows:\n\n- prevent approval by author\n\n- prevent approvals by users who add commits\n\n- prevent editing approval rules in merge requests\n\n- require user re-authentication (password or SAML) to approve\n\n\nAdditionally, whenever a commit is added, you can:\n\n- keep approvals\n\n- remove all approvals\n\n- remove approvals by Code Owners if their files changed\n\n\n![Additional Approval\nsettings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image12_aHR0cHM6_1750099455084.png)\n\n\n\u003Ccenter>\u003Ci>Additional Approval settings\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\nTo configure additional approval settings you can perform the following\nsteps:\n\n1. On the left sidebar, select **Search or go to** and find your project.\n\n2. Select **Settings > Merge requests**.\n\n3. Scroll down to the **Merge request approvals** section.\n\n4. Under **Approval settings** select the approval settings you would like\nto apply.\n\n5. Press the **Save changes** button.\n\n\nThese can also be applied to your top-level group by performing the\nfollowing steps:\n\n1. On the left sidebar, select **Search or go to** and find your top-level\ngroup.\n\n2. Select **Settings > General**.\n\n3. Expand the **Merge request approvals** section.\n\n4. Under **Approval settings** select the approval settings you would like\nto apply.\n\n5. Press the **Save changes** button.\n\n\nBy leveraging these approval settings you can make sure that code always\nobtains oversight by a person who was not involved in creating the code,\nthereby preventing a conflict of interest.\n\n\n## Compliance pipelines and frameworks\n\nYou can create a compliance framework that is a label to identify that your\nproject has certain compliance requirements or needs additional oversight.\nThe label can optionally enforce compliance pipeline configuration to the\nprojects on which it is applied.\n\n\nFeel free to leverage the [Compliance Frameworks\nDemo](https://gitlab.com/gitlab-de/tutorials/security-and-governance/compliance-frameworks)\ngroup to see an example of compliance frameworks and their usage.\n\n\n### Create a compliance pipeline\n\nTo create a compliance pipeline, all you need to do is create a new project\nwhich will store a `.gitlab-ci.yml` file that we wish to use in another\nproject. The new compliance pipeline project can have separate permissions\nfrom the project to which you will apply it. This is beneficial because it\nprevents developers from making changes to pipelines that must run.\n\n\nYou can see I have created the following [pipeline\ndefinition](https://gitlab.com/gitlab-de/tutorials/security-and-governance/compliance-frameworks)\nwhich:\n\n- runs the SAST security scanner\n\n- runs the secret detection scanner\n\n- runs a SOC2 compliance job\n\n- runs the original pipeline defined in the project to which we will apply\nthis pipeline. This allows developers to focus on the actual application\ndevelopment and the compliance team to focus on defining the SOC2 rules.\n\n\n### Create and apply a compliance framework\n\nNow that the compliance pipeline for SOC2 has been defined, we must define a\ncompliance framework and apply it to our project. In this case, I will apply\nit to my Accounting Department project.\n\n\nTo create a compliance framework label, follow these steps:\n\n1. On the left sidebar, select **Search or go to** and find your group.\n\n2. Select **Settings > General**.\n\n3. Expand the **Compliance frameworks** section.\n\n4. Click the **Add framework** button.\n\n5. Create a new compliance framework and populate the following sections:\n    - **Name:** The name of your compliance framework\n    - **Description:** A description of your compliance framework\n    - **Compliance pipeline configuration:** The location of the compliance pipeline to run. \n    - **Background color:** A color for the compliance framework label\n\n![PoLP - image\n15](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750099455085.png)\n\n   \u003Ccenter>\u003Ci>Creating a compliance framework\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n6. Press the **Add framework** button.\n\n\nAnd now you should see your newly added framework under active compliance\nframeworks.\n\n\n![Active compliance\nframeworks](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750099455085.png)\n\n\n\u003Ccenter>\u003Ci>Active compliance frameworks\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\nNow let’s go ahead and assign this compliance label to our Accounting\nDepartment project:\n\n\n1. On the left sidebar, select **Search or go to** and find your project.\n\n2. Select **Settings > General**.\n\n3. Expand **Compliance frameworks**.\n\n4. Select the compliance framework created above.\n\n\n![Adding a compliance\nframework](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099455086.png)\n\n\n\u003Ccenter>\u003Ci>Adding a compliance framework\u003C/i>\u003C/center>\n\n\n5. Select **Save changes**.\n\n\nThe project should now have the compliance framework label applied. \n\n\n![Project running a compliance\npipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750099455086.png)\n\n\n\u003Ccenter>\u003Ci>Project running a compliance pipeline\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\nThis enables separation of duties and prevents compliance pipelines from\nbeing altered by those without permissions.\n\n\nSecurity Policy Scope and Pipeline Execution\n\nOver the past several releases, GitLab has introduced two experimental\nfeatures, Security Policy Scope and Pipeline Execution, to make it even\neasier to adhere to PoLP. These features are very similar to Compliance\nPipelines and Compliance Frameworks and can be managed from GitLab’s\nsecurity policy UI.\n\n\n**Note:** These features are currently considered experimental. An\nexperiment is a feature that is in the process of being developed. It is not\nproduction ready. We encourage users to try experimental features and\nprovide feedback.\n\n\nThe [pipeline execution policy\naction](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html#pipeline-execution-policy-action)\nintroduces a new scan action type into Scan Execution policies for creating\nand enforcing custom CI in your target development projects. You can execute\na custom pipeline along with your current pipeline. This allows you to\nenforce compliance by always forcing particular actions to run that are not\njust security scanners and that cannot be overwritten by those without\npermissions.\n\n\n![Pipeline Execution policy scope\nselection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image18_aHR0cHM6_1750099455087.png)\n\n\u003Ccenter>\u003Ci>Pipeline Execution policy scope selection - insert code\nblock\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\n![Pipeline Execution policy scope\nselection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099455/Blog/Content%20Images/Blog/Content%20Images/image13_aHR0cHM6_1750099455087.png)\n\n\u003Ccenter>\u003Ci>Pipeline Execution policy scope selection - link existing CI\nfile\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\nThe [Security policy\nscope](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html#security-policy-scopes)\ncan be applied to either Merge Request Approval or Scan Execution policies.\nScopes enable you to administer policies with a particular scope, meaning\nyou can:\n\n\n- Include only projects containing a compliance framework label\n\n- Include or exclude selected projects from enforcement\n\n\nTo enable these experimental features, follow these steps:\n\n1. On the left sidebar, select **Search or go to** and find your top-level\ngroup.\n\n2. Select **Settings > General**.\n\n3. Expand **Permissions and group features**.\n\n4. Scroll down to the **Security policy management** section.\n\n5. Select the following checkboxes\n\n**Security policy pipeline execution action:** Create and enforce custom CI\njobs and scripts using this new policy action.\n\n6. **Security policy scopes:** Granularly scope each policy you create to\nprojects containing a compliance framework label, or a list of projects.\n\n7. **Enforce for all subgroups (optional):** Subgroups cannot change these\nsettings.\n\n8. Scroll down to the **Experiment and Beta features** section.\n\n9. Select the **Use Experiment and Beta features** checkbox.\n\n10. Scroll down and press the **Save changes** button.\n\n\nNow, whenever you are creating a security policy, the following options will\nbe available:\n\n\n- Inserting a CI code block (Scan Execution policy only)\n\n- Loading CI/CD code from file (Scan Execution policy only)\n\n- Linking an existing CI file from another project (Scan Execution policy\nonly)\n\n- Scoping a policy to projects with selected compliance framework (Group\nLevel only)\n\n- Scoping a policy towards specific projects (Group Level only)\n\n- Scoping a policy towards all projects in group (Group Level only)\n\n\nTo learn more about these features, check out the following documentation:\n\n- [Pipeline Execution Policy action (Scan Execution\npolicy)](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html#pipeline-execution-policy-action)\n\n- [Security Policy Scopes (Scan Execution\npolicy)](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html#security-policy-scopes)\n\n- [Security Policy Scopes (Merge Request Approval\npolicy)](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html#security-policy-scopes)\n\n\n## Additional resources\n\n\nThanks for reading! These are some of the ways that GitLab allows you to\nstrengthen your organization's security posture through the enablement of\nPoLP. To learn more about GitLab and the other ways we can strengthen your\norganization's security throughout all parts of the SDLC, check out the\nfollowing links:\n\n\n- [GitLab Security and\nCompliance](https://about.gitlab.com/solutions/security-compliance/)\n\n- [GitLab Application Security\nDocumentation](https://docs.gitlab.com/ee/user/application_security/)\n\n- [GitLab DevSecOps Demo\nProject](https://gitlab.com/gitlab-de/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n\n- [GitLab DevSecOps\nTutorial](https://gitlab-de.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/)\n\n- [GitLab Roles and Permissions\nDocumentation](https://docs.gitlab.com/ee/user/permissions.html)\n\n- [GitLab Custom Roles\nDocumentation](https://docs.gitlab.com/ee/user/custom_roles.html)\n\n- [GitLab Security Policies\nDocumentation](https://docs.gitlab.com/ee/user/application_security/policies/)\n\n- [GitLab Compliance Frameworks\nDocumentation](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html)\n\n- [GitLab Code Owners\nDocumentation](https://docs.gitlab.com/ee/user/project/codeowners/)\n\n- [GitLab Branch Protections\nDocumentation](https://docs.gitlab.com/ee/user/project/protected_branches.html)\n","security",[23,24,21,25],"zero trust","tutorial","features",{"slug":27,"featured":28,"template":29},"the-ultimate-guide-to-least-privilege-access-with-gitlab",true,"BlogPost","content:en-us:blog:the-ultimate-guide-to-least-privilege-access-with-gitlab.yml","yaml","The Ultimate Guide To Least Privilege Access With Gitlab","content","en-us/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab.yml","en-us/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab","yml",{"_path":38,"_dir":39,"_draft":6,"_partial":6,"_locale":7,"data":40,"_id":461,"_type":31,"title":462,"_source":33,"_file":463,"_stem":464,"_extension":36},"/shared/en-us/main-navigation","en-us",{"logo":41,"freeTrial":46,"sales":51,"login":56,"items":61,"search":392,"minimal":423,"duo":442,"pricingDeployment":451},{"config":42},{"href":43,"dataGaName":44,"dataGaLocation":45},"/","gitlab logo","header",{"text":47,"config":48},"Get free trial",{"href":49,"dataGaName":50,"dataGaLocation":45},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":52,"config":53},"Talk to sales",{"href":54,"dataGaName":55,"dataGaLocation":45},"/sales/","sales",{"text":57,"config":58},"Sign in",{"href":59,"dataGaName":60,"dataGaLocation":45},"https://gitlab.com/users/sign_in/","sign in",[62,106,203,208,313,373],{"text":63,"config":64,"cards":66,"footer":89},"Platform",{"dataNavLevelOne":65},"platform",[67,73,81],{"title":63,"description":68,"link":69},"The most comprehensive AI-powered DevSecOps Platform",{"text":70,"config":71},"Explore our Platform",{"href":72,"dataGaName":65,"dataGaLocation":45},"/platform/",{"title":74,"description":75,"link":76},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":77,"config":78},"Meet GitLab Duo",{"href":79,"dataGaName":80,"dataGaLocation":45},"/gitlab-duo/","gitlab duo ai",{"title":82,"description":83,"link":84},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":85,"config":86},"Learn more",{"href":87,"dataGaName":88,"dataGaLocation":45},"/why-gitlab/","why gitlab",{"title":90,"items":91},"Get started with",[92,97,102],{"text":93,"config":94},"Platform Engineering",{"href":95,"dataGaName":96,"dataGaLocation":45},"/solutions/platform-engineering/","platform engineering",{"text":98,"config":99},"Developer Experience",{"href":100,"dataGaName":101,"dataGaLocation":45},"/developer-experience/","Developer experience",{"text":103,"config":104},"MLOps",{"href":105,"dataGaName":103,"dataGaLocation":45},"/topics/devops/the-role-of-ai-in-devops/",{"text":107,"left":28,"config":108,"link":110,"lists":114,"footer":185},"Product",{"dataNavLevelOne":109},"solutions",{"text":111,"config":112},"View all Solutions",{"href":113,"dataGaName":109,"dataGaLocation":45},"/solutions/",[115,140,164],{"title":116,"description":117,"link":118,"items":123},"Automation","CI/CD and automation to accelerate deployment",{"config":119},{"icon":120,"href":121,"dataGaName":122,"dataGaLocation":45},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[124,128,132,136],{"text":125,"config":126},"CI/CD",{"href":127,"dataGaLocation":45,"dataGaName":125},"/solutions/continuous-integration/",{"text":129,"config":130},"AI-Assisted Development",{"href":79,"dataGaLocation":45,"dataGaName":131},"AI assisted development",{"text":133,"config":134},"Source Code Management",{"href":135,"dataGaLocation":45,"dataGaName":133},"/solutions/source-code-management/",{"text":137,"config":138},"Automated Software Delivery",{"href":121,"dataGaLocation":45,"dataGaName":139},"Automated software delivery",{"title":141,"description":142,"link":143,"items":148},"Security","Deliver code faster without compromising security",{"config":144},{"href":145,"dataGaName":146,"dataGaLocation":45,"icon":147},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[149,154,159],{"text":150,"config":151},"Application Security Testing",{"href":152,"dataGaName":153,"dataGaLocation":45},"/solutions/application-security-testing/","Application security testing",{"text":155,"config":156},"Software Supply Chain Security",{"href":157,"dataGaLocation":45,"dataGaName":158},"/solutions/supply-chain/","Software supply chain security",{"text":160,"config":161},"Software Compliance",{"href":162,"dataGaName":163,"dataGaLocation":45},"/solutions/software-compliance/","software compliance",{"title":165,"link":166,"items":171},"Measurement",{"config":167},{"icon":168,"href":169,"dataGaName":170,"dataGaLocation":45},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[172,176,180],{"text":173,"config":174},"Visibility & Measurement",{"href":169,"dataGaLocation":45,"dataGaName":175},"Visibility and Measurement",{"text":177,"config":178},"Value Stream Management",{"href":179,"dataGaLocation":45,"dataGaName":177},"/solutions/value-stream-management/",{"text":181,"config":182},"Analytics & Insights",{"href":183,"dataGaLocation":45,"dataGaName":184},"/solutions/analytics-and-insights/","Analytics and insights",{"title":186,"items":187},"GitLab for",[188,193,198],{"text":189,"config":190},"Enterprise",{"href":191,"dataGaLocation":45,"dataGaName":192},"/enterprise/","enterprise",{"text":194,"config":195},"Small Business",{"href":196,"dataGaLocation":45,"dataGaName":197},"/small-business/","small business",{"text":199,"config":200},"Public Sector",{"href":201,"dataGaLocation":45,"dataGaName":202},"/solutions/public-sector/","public sector",{"text":204,"config":205},"Pricing",{"href":206,"dataGaName":207,"dataGaLocation":45,"dataNavLevelOne":207},"/pricing/","pricing",{"text":209,"config":210,"link":212,"lists":216,"feature":300},"Resources",{"dataNavLevelOne":211},"resources",{"text":213,"config":214},"View all resources",{"href":215,"dataGaName":211,"dataGaLocation":45},"/resources/",[217,250,272],{"title":218,"items":219},"Getting started",[220,225,230,235,240,245],{"text":221,"config":222},"Install",{"href":223,"dataGaName":224,"dataGaLocation":45},"/install/","install",{"text":226,"config":227},"Quick start guides",{"href":228,"dataGaName":229,"dataGaLocation":45},"/get-started/","quick setup checklists",{"text":231,"config":232},"Learn",{"href":233,"dataGaLocation":45,"dataGaName":234},"https://university.gitlab.com/","learn",{"text":236,"config":237},"Product documentation",{"href":238,"dataGaName":239,"dataGaLocation":45},"https://docs.gitlab.com/","product documentation",{"text":241,"config":242},"Best practice videos",{"href":243,"dataGaName":244,"dataGaLocation":45},"/getting-started-videos/","best practice videos",{"text":246,"config":247},"Integrations",{"href":248,"dataGaName":249,"dataGaLocation":45},"/integrations/","integrations",{"title":251,"items":252},"Discover",[253,258,262,267],{"text":254,"config":255},"Customer success stories",{"href":256,"dataGaName":257,"dataGaLocation":45},"/customers/","customer success stories",{"text":259,"config":260},"Blog",{"href":261,"dataGaName":5,"dataGaLocation":45},"/blog/",{"text":263,"config":264},"Remote",{"href":265,"dataGaName":266,"dataGaLocation":45},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":268,"config":269},"TeamOps",{"href":270,"dataGaName":271,"dataGaLocation":45},"/teamops/","teamops",{"title":273,"items":274},"Connect",[275,280,285,290,295],{"text":276,"config":277},"GitLab Services",{"href":278,"dataGaName":279,"dataGaLocation":45},"/services/","services",{"text":281,"config":282},"Community",{"href":283,"dataGaName":284,"dataGaLocation":45},"/community/","community",{"text":286,"config":287},"Forum",{"href":288,"dataGaName":289,"dataGaLocation":45},"https://forum.gitlab.com/","forum",{"text":291,"config":292},"Events",{"href":293,"dataGaName":294,"dataGaLocation":45},"/events/","events",{"text":296,"config":297},"Partners",{"href":298,"dataGaName":299,"dataGaLocation":45},"/partners/","partners",{"backgroundColor":301,"textColor":302,"text":303,"image":304,"link":308},"#2f2a6b","#fff","Insights for the future of software development",{"altText":305,"config":306},"the source promo card",{"src":307},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":309,"config":310},"Read the latest",{"href":311,"dataGaName":312,"dataGaLocation":45},"/the-source/","the source",{"text":314,"config":315,"lists":317},"Company",{"dataNavLevelOne":316},"company",[318],{"items":319},[320,325,331,333,338,343,348,353,358,363,368],{"text":321,"config":322},"About",{"href":323,"dataGaName":324,"dataGaLocation":45},"/company/","about",{"text":326,"config":327,"footerGa":330},"Jobs",{"href":328,"dataGaName":329,"dataGaLocation":45},"/jobs/","jobs",{"dataGaName":329},{"text":291,"config":332},{"href":293,"dataGaName":294,"dataGaLocation":45},{"text":334,"config":335},"Leadership",{"href":336,"dataGaName":337,"dataGaLocation":45},"/company/team/e-group/","leadership",{"text":339,"config":340},"Team",{"href":341,"dataGaName":342,"dataGaLocation":45},"/company/team/","team",{"text":344,"config":345},"Handbook",{"href":346,"dataGaName":347,"dataGaLocation":45},"https://handbook.gitlab.com/","handbook",{"text":349,"config":350},"Investor relations",{"href":351,"dataGaName":352,"dataGaLocation":45},"https://ir.gitlab.com/","investor relations",{"text":354,"config":355},"Trust Center",{"href":356,"dataGaName":357,"dataGaLocation":45},"/security/","trust center",{"text":359,"config":360},"AI Transparency Center",{"href":361,"dataGaName":362,"dataGaLocation":45},"/ai-transparency-center/","ai transparency center",{"text":364,"config":365},"Newsletter",{"href":366,"dataGaName":367,"dataGaLocation":45},"/company/contact/","newsletter",{"text":369,"config":370},"Press",{"href":371,"dataGaName":372,"dataGaLocation":45},"/press/","press",{"text":374,"config":375,"lists":376},"Contact us",{"dataNavLevelOne":316},[377],{"items":378},[379,382,387],{"text":52,"config":380},{"href":54,"dataGaName":381,"dataGaLocation":45},"talk to sales",{"text":383,"config":384},"Get help",{"href":385,"dataGaName":386,"dataGaLocation":45},"/support/","get help",{"text":388,"config":389},"Customer portal",{"href":390,"dataGaName":391,"dataGaLocation":45},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":393,"login":394,"suggestions":401},"Close",{"text":395,"link":396},"To search repositories and projects, login to",{"text":397,"config":398},"gitlab.com",{"href":59,"dataGaName":399,"dataGaLocation":400},"search login","search",{"text":402,"default":403},"Suggestions",[404,406,410,412,416,420],{"text":74,"config":405},{"href":79,"dataGaName":74,"dataGaLocation":400},{"text":407,"config":408},"Code Suggestions (AI)",{"href":409,"dataGaName":407,"dataGaLocation":400},"/solutions/code-suggestions/",{"text":125,"config":411},{"href":127,"dataGaName":125,"dataGaLocation":400},{"text":413,"config":414},"GitLab on AWS",{"href":415,"dataGaName":413,"dataGaLocation":400},"/partners/technology-partners/aws/",{"text":417,"config":418},"GitLab on Google Cloud",{"href":419,"dataGaName":417,"dataGaLocation":400},"/partners/technology-partners/google-cloud-platform/",{"text":421,"config":422},"Why GitLab?",{"href":87,"dataGaName":421,"dataGaLocation":400},{"freeTrial":424,"mobileIcon":429,"desktopIcon":434,"secondaryButton":437},{"text":425,"config":426},"Start free trial",{"href":427,"dataGaName":50,"dataGaLocation":428},"https://gitlab.com/-/trials/new/","nav",{"altText":430,"config":431},"Gitlab Icon",{"src":432,"dataGaName":433,"dataGaLocation":428},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":430,"config":435},{"src":436,"dataGaName":433,"dataGaLocation":428},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":438,"config":439},"Get Started",{"href":440,"dataGaName":441,"dataGaLocation":428},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":443,"mobileIcon":447,"desktopIcon":449},{"text":444,"config":445},"Learn more about GitLab Duo",{"href":79,"dataGaName":446,"dataGaLocation":428},"gitlab duo",{"altText":430,"config":448},{"src":432,"dataGaName":433,"dataGaLocation":428},{"altText":430,"config":450},{"src":436,"dataGaName":433,"dataGaLocation":428},{"freeTrial":452,"mobileIcon":457,"desktopIcon":459},{"text":453,"config":454},"Back to pricing",{"href":206,"dataGaName":455,"dataGaLocation":428,"icon":456},"back to pricing","GoBack",{"altText":430,"config":458},{"src":432,"dataGaName":433,"dataGaLocation":428},{"altText":430,"config":460},{"src":436,"dataGaName":433,"dataGaLocation":428},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":466,"_dir":39,"_draft":6,"_partial":6,"_locale":7,"title":467,"button":468,"image":473,"config":477,"_id":479,"_type":31,"_source":33,"_file":480,"_stem":481,"_extension":36},"/shared/en-us/banner","is now in public beta!",{"text":469,"config":470},"Try the Beta",{"href":471,"dataGaName":472,"dataGaLocation":45},"/gitlab-duo/agent-platform/","duo banner",{"altText":474,"config":475},"GitLab Duo Agent Platform",{"src":476},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1753720689/somrf9zaunk0xlt7ne4x.svg",{"layout":478},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":483,"_dir":39,"_draft":6,"_partial":6,"_locale":7,"data":484,"_id":688,"_type":31,"title":689,"_source":33,"_file":690,"_stem":691,"_extension":36},"/shared/en-us/main-footer",{"text":485,"source":486,"edit":492,"contribute":497,"config":502,"items":507,"minimal":680},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":487,"config":488},"View page source",{"href":489,"dataGaName":490,"dataGaLocation":491},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":493,"config":494},"Edit this page",{"href":495,"dataGaName":496,"dataGaLocation":491},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":498,"config":499},"Please contribute",{"href":500,"dataGaName":501,"dataGaLocation":491},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":503,"facebook":504,"youtube":505,"linkedin":506},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[508,531,587,616,650],{"title":63,"links":509,"subMenu":514},[510],{"text":511,"config":512},"DevSecOps platform",{"href":72,"dataGaName":513,"dataGaLocation":491},"devsecops platform",[515],{"title":204,"links":516},[517,521,526],{"text":518,"config":519},"View plans",{"href":206,"dataGaName":520,"dataGaLocation":491},"view plans",{"text":522,"config":523},"Why Premium?",{"href":524,"dataGaName":525,"dataGaLocation":491},"/pricing/premium/","why premium",{"text":527,"config":528},"Why Ultimate?",{"href":529,"dataGaName":530,"dataGaLocation":491},"/pricing/ultimate/","why ultimate",{"title":532,"links":533},"Solutions",[534,539,541,543,548,553,557,560,564,569,571,574,577,582],{"text":535,"config":536},"Digital transformation",{"href":537,"dataGaName":538,"dataGaLocation":491},"/topics/digital-transformation/","digital transformation",{"text":150,"config":540},{"href":152,"dataGaName":150,"dataGaLocation":491},{"text":139,"config":542},{"href":121,"dataGaName":122,"dataGaLocation":491},{"text":544,"config":545},"Agile development",{"href":546,"dataGaName":547,"dataGaLocation":491},"/solutions/agile-delivery/","agile delivery",{"text":549,"config":550},"Cloud transformation",{"href":551,"dataGaName":552,"dataGaLocation":491},"/topics/cloud-native/","cloud transformation",{"text":554,"config":555},"SCM",{"href":135,"dataGaName":556,"dataGaLocation":491},"source code management",{"text":125,"config":558},{"href":127,"dataGaName":559,"dataGaLocation":491},"continuous integration & delivery",{"text":561,"config":562},"Value stream management",{"href":179,"dataGaName":563,"dataGaLocation":491},"value stream management",{"text":565,"config":566},"GitOps",{"href":567,"dataGaName":568,"dataGaLocation":491},"/solutions/gitops/","gitops",{"text":189,"config":570},{"href":191,"dataGaName":192,"dataGaLocation":491},{"text":572,"config":573},"Small business",{"href":196,"dataGaName":197,"dataGaLocation":491},{"text":575,"config":576},"Public sector",{"href":201,"dataGaName":202,"dataGaLocation":491},{"text":578,"config":579},"Education",{"href":580,"dataGaName":581,"dataGaLocation":491},"/solutions/education/","education",{"text":583,"config":584},"Financial services",{"href":585,"dataGaName":586,"dataGaLocation":491},"/solutions/finance/","financial services",{"title":209,"links":588},[589,591,593,595,598,600,602,604,606,608,610,612,614],{"text":221,"config":590},{"href":223,"dataGaName":224,"dataGaLocation":491},{"text":226,"config":592},{"href":228,"dataGaName":229,"dataGaLocation":491},{"text":231,"config":594},{"href":233,"dataGaName":234,"dataGaLocation":491},{"text":236,"config":596},{"href":238,"dataGaName":597,"dataGaLocation":491},"docs",{"text":259,"config":599},{"href":261,"dataGaName":5,"dataGaLocation":491},{"text":254,"config":601},{"href":256,"dataGaName":257,"dataGaLocation":491},{"text":263,"config":603},{"href":265,"dataGaName":266,"dataGaLocation":491},{"text":276,"config":605},{"href":278,"dataGaName":279,"dataGaLocation":491},{"text":268,"config":607},{"href":270,"dataGaName":271,"dataGaLocation":491},{"text":281,"config":609},{"href":283,"dataGaName":284,"dataGaLocation":491},{"text":286,"config":611},{"href":288,"dataGaName":289,"dataGaLocation":491},{"text":291,"config":613},{"href":293,"dataGaName":294,"dataGaLocation":491},{"text":296,"config":615},{"href":298,"dataGaName":299,"dataGaLocation":491},{"title":314,"links":617},[618,620,622,624,626,628,630,634,639,641,643,645],{"text":321,"config":619},{"href":323,"dataGaName":316,"dataGaLocation":491},{"text":326,"config":621},{"href":328,"dataGaName":329,"dataGaLocation":491},{"text":334,"config":623},{"href":336,"dataGaName":337,"dataGaLocation":491},{"text":339,"config":625},{"href":341,"dataGaName":342,"dataGaLocation":491},{"text":344,"config":627},{"href":346,"dataGaName":347,"dataGaLocation":491},{"text":349,"config":629},{"href":351,"dataGaName":352,"dataGaLocation":491},{"text":631,"config":632},"Sustainability",{"href":633,"dataGaName":631,"dataGaLocation":491},"/sustainability/",{"text":635,"config":636},"Diversity, inclusion and belonging (DIB)",{"href":637,"dataGaName":638,"dataGaLocation":491},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":354,"config":640},{"href":356,"dataGaName":357,"dataGaLocation":491},{"text":364,"config":642},{"href":366,"dataGaName":367,"dataGaLocation":491},{"text":369,"config":644},{"href":371,"dataGaName":372,"dataGaLocation":491},{"text":646,"config":647},"Modern Slavery Transparency Statement",{"href":648,"dataGaName":649,"dataGaLocation":491},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":651,"links":652},"Contact Us",[653,656,658,660,665,670,675],{"text":654,"config":655},"Contact an expert",{"href":54,"dataGaName":55,"dataGaLocation":491},{"text":383,"config":657},{"href":385,"dataGaName":386,"dataGaLocation":491},{"text":388,"config":659},{"href":390,"dataGaName":391,"dataGaLocation":491},{"text":661,"config":662},"Status",{"href":663,"dataGaName":664,"dataGaLocation":491},"https://status.gitlab.com/","status",{"text":666,"config":667},"Terms of use",{"href":668,"dataGaName":669,"dataGaLocation":491},"/terms/","terms of use",{"text":671,"config":672},"Privacy statement",{"href":673,"dataGaName":674,"dataGaLocation":491},"/privacy/","privacy statement",{"text":676,"config":677},"Cookie preferences",{"dataGaName":678,"dataGaLocation":491,"id":679,"isOneTrustButton":28},"cookie preferences","ot-sdk-btn",{"items":681},[682,684,686],{"text":666,"config":683},{"href":668,"dataGaName":669,"dataGaLocation":491},{"text":671,"config":685},{"href":673,"dataGaName":674,"dataGaLocation":491},{"text":676,"config":687},{"dataGaName":678,"dataGaLocation":491,"id":679,"isOneTrustButton":28},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",[693],{"_path":694,"_dir":695,"_draft":6,"_partial":6,"_locale":7,"content":696,"config":700,"_id":702,"_type":31,"title":18,"_source":33,"_file":703,"_stem":704,"_extension":36},"/en-us/blog/authors/fernando-diaz","authors",{"name":18,"config":697},{"headshot":698,"ctfId":699},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659556/Blog/Author%20Headshots/fern_diaz.png","fjdiaz",{"template":701},"BlogAuthor","content:en-us:blog:authors:fernando-diaz.yml","en-us/blog/authors/fernando-diaz.yml","en-us/blog/authors/fernando-diaz",{"_path":706,"_dir":39,"_draft":6,"_partial":6,"_locale":7,"header":707,"eyebrow":708,"blurb":709,"button":710,"secondaryButton":714,"_id":716,"_type":31,"title":717,"_source":33,"_file":718,"_stem":719,"_extension":36},"/shared/en-us/next-steps","Start shipping better software faster","50%+ of the Fortune 100 trust GitLab","See what your team can do with the intelligent\n\n\nDevSecOps platform.\n",{"text":47,"config":711},{"href":712,"dataGaName":50,"dataGaLocation":713},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":52,"config":715},{"href":54,"dataGaName":55,"dataGaLocation":713},"content:shared:en-us:next-steps.yml","Next Steps","shared/en-us/next-steps.yml","shared/en-us/next-steps",1758326265342]