[{"data":1,"prerenderedAt":804},["ShallowReactive",2],{"/en-us/blog/how-to-choose-the-right-security-scanning-approach":3,"navigation-en-us":39,"banner-en-us":438,"footer-en-us":448,"blog-post-authors-en-us-Matt Genelin|Mathias Ewald":689,"blog-related-posts-en-us-how-to-choose-the-right-security-scanning-approach":715,"assessment-promotions-en-us":756,"next-steps-en-us":794},{"id":4,"title":5,"authorSlugs":6,"body":9,"categorySlug":10,"config":11,"content":15,"description":9,"extension":27,"isFeatured":13,"meta":28,"navigation":13,"path":29,"publishedDate":22,"seo":30,"stem":35,"tagSlugs":36,"__hash__":38},"blogPosts/en-us/blog/how-to-choose-the-right-security-scanning-approach.yml","How To Choose The Right Security Scanning Approach",[7,8],"matt-genelin","mathias-ewald",null,"security",{"slug":12,"featured":13,"template":14},"how-to-choose-the-right-security-scanning-approach",true,"BlogPost",{"title":16,"description":17,"authors":18,"heroImage":21,"date":22,"body":23,"category":10,"tags":24},"How to choose the right security scanning approach","GitLab offers multiple scanning methods for CI/CD pipelines, including compliance frameworks and scan and pipeline execution policies. Learn the basics, configurations, and advantages/disadvantages.",[19,20],"Matt Genelin","Mathias Ewald","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097969/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_282096522_securitycompliance.jpeg_1750097968823.jpg","2024-08-26","Integrating security scans into your CI/CD pipeline is crucial for maintaining robust and secure applications. But who's responsible for those scans? Who is responsible for adding them into every CI/CD pipeline for all projects? And who decides which identified vulnerability may pass or needs fixing? For organizations in regulated industries, these are critical questions.\n\nIn this article, you'll learn how GitLab [CI/CD](https://about.gitlab.com/topics/ci-cd/) enables each person in the software development lifecycle to incorporate security scanning. You'll also discover the advantages and disadvantages of the various options available to add scanning to GitLab project pipelines. Code examples will help you kickstart security scanning on the GitLab DevSecOps platform.\n\nArticle contents:\n- [The basics of setting up security scanning](#the-basics-of-setting-up-security-scanning)\n- [Pipeline includes](#pipeline-includes)\n- [Compliance frameworks](#compliance-frameworks)\n- [Policies](#policies)\n- [Get started with security scanning](#get-started-with-security-scanning)\n\n## The basics of setting up security scanning\n\nGitLab uses [fictional personas](https://handbook.gitlab.com/handbook/product/personas/#user-personas) to describe the individual team member who would typically use a given security feature or approach. By exploring the perspective of a **Software Developer (Sasha)**, **Application Security Engineer (Amy)**, or **Platform Engineer (Priyanka)**, you can better understand the needs of each role on your team.\n\nGitLab follows a \"pipeline-per-project\" principle, stored in the file named `.gitlab-ci.yml`. This file contains the project's CI/CD pipeline definition and is revision controlled like any other file in the project. You'll learn about these project pipelines, as well as compliance pipelines and policy pipelines. While compliance pipelines and policy pipelines also refer to the YAML files in GitLab projects, they typically have a different file name and serve a different purpose.\n\nReaders already familiar with security scanning in GitLab will find clarity in the security pipeline choices available in the context of your team/organization. Therefore, we will discuss each of the approaches with respect to the following criteria:\n\n- **Ease of use:** How easy is it to add security scanning to project pipelines? Is it a reasonable task for Sasha, or something that Amy and Priyanka should handle?\n\n- **Customization:** How deeply can scanner configurations be customized using that approach? While default configurations that make sense and cover a wide range of customer needs are worth gold, the time often comes when scanner configurations need adjustments.\n\n- **Enforcement:** Is this approach suitable to companies operating in regulated industries or that otherwise have global policies in place? Can we ensure each relevant project runs Scanner X with Configuration Y?\n\n## Pipeline includes\n\n[GitLab project pipeline includes](https://docs.gitlab.com/ee/ci/yaml/includes.html) are a mechanism that allows the integration of external pipelines into the `.gitlab-ci.yaml` project pipeline. This is similar to including a library in many programming languages. This powerful feature enables the seamless incorporation of your own templates, as well as GitLab-provided templates, to be used as building blocks for your pipelines. Includes can be used in project pipelines or other pipeline files. An example of a commonly included external pipeline is including a security scanning pipeline into a GitLab project pipeline.\n\nHere are the common types of includes, which use the security scanner example.\n\n### Templates\n\nGitLab offers ready-to-use [templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Jobs) that can be included in a project pipeline to make it easier for teams to add in various pre-built elements. The following is example code:\n\n```yaml\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n  - template: Jobs/SAST.gitlab-ci.yml\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\n```\n\nThis code includes GitLab's templates for [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/), [Static Application Security Testing](https://docs.gitlab.com/ee/user/application_security/sast/), [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), and [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/) – all in only five lines of code. \n\nTo modify the behavior of jobs included via templates, you can either use variables or use [GitLab's property merging capabilities](https://docs.gitlab.com/ee/ci/yaml/includes.html#merge-method-for-include).\n\nYou will find an example of modifying the GitLab Container Scanning pipeline using variables below. The [template for Container Scanning](https://gitlab.com/gitlab-org/gitlab/-/blob/59f08760feaab1eb0489f694d4f28408af9c2e8d/lib/gitlab/ci/templates/Jobs/Container-Scanning.gitlab-ci.yml) needs to know the location of the image and uses a variable named `CS_IMAGE` for that as is documented in the template code linked above.\n\n```yaml\nvariables:\n  CS_IMAGE: \"$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA\"\n\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\n```\n\nThe project pipeline variables are available to included job templates by defining the `CS_IMAGE` variable before the included pipeline template. The Container Scanning template inherits the `CS_IMAGE` variable value. \n\nIf we wanted to make changes to the [`allow_failure` property defined here](https://gitlab.com/gitlab-org/gitlab/-/blob/59f08760feaab1eb0489f694d4f28408af9c2e8d/lib/gitlab/ci/templates/Jobs/Container-Scanning.gitlab-ci.yml#L38), we would need to resort to property merging since the job templates employ no variable for the value. (The `allow_failure` property is a property generally available on every GitLab pipeline job. Please check the [documentation](https://docs.gitlab.com/ee/ci/yaml/#allow_failure) for details.)\n\nIn this example, `allow_failure` is set to `false`, meaning the entire pipeline stops on a container scanning failure. This stops any unscanned containers from moving forward in the pipeline.\n\n```yaml\ninclude:\n  # Includes a job called \"container_scanning\"\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\n# Define a job with same name for merging\ncontainer_scanning:\n  allow_failure: false\n\n```\n\nGitLab will load the job template and – as defined in the template code – register a job called `container_scanning`. As the pipeline definition declares another job with that name, GitLab will merge that specification with the already registered job.\n\nWhile this feature offers many possibilities, it also makes it impossible to protect certain properties from being overwritten. We are only at the point of modifying the project pipeline, so there's no control over that anyway. But later on, you will see that this can pose a challenge when security needs to be enforced on a project.\n\n### Components\n\nTemplates are a great start for sharing repeatable GitLab pipelines. To further abstract reusable code across an entire organization or a GitLab instance, [GitLab introduced components](https://docs.gitlab.com/ee/ci/components/). Components are the next logical step in GitLab's evolution of pipelines. Components are designed to simplify the creation and use of functional building blocks to use in pipelines, or even to package and ship entire pipelines if needed. They offer a well-defined interface, which accepts \"inputs\" for configuration. Otherwise, the component is completely isolated, which makes them a great candidate to share work within an organization and to be searchable and reusable building blocks.\n\nDevelopers can use the [CI/CD Catalog](https://gitlab.com/explore/catalog) to browse and search the collection of publicly available GitLab components, which are components officially built and maintained by GitLab. GitLab uses the CI/CD Catalog [to publish our shipped components](https://gitlab.com/components) such as security scanners alongside community-provided components.\n\nComponents are consumed similarly to templates via the `include` keyword. In an example above, we showed how the container scanning job requires knowledge of the image location. This \"input\" uses the component for [container scanning](https://gitlab.com/components/container-scanning/-/blob/19fd5b83bc631cb9890b4fadb08d31b3150853ce/templates/container-scanning.yml) is called `cs_image`. The configuration equivalent to the previous example looks like this:\n\n```yaml\ninclude:\n  - component: $CI_SERVER_FQDN/components/sast/sast@2.0.2\n  - component: $CI_SERVER_FQDN/components/dependency-scanning/cargo@0.2.0\n  - component: $CI_SERVER_FQDN/components/secret-detection/secret-detection@1.1.2\n  - component: $CI_SERVER_FQDN/components/container-scanning/container-scanning@4.1.0\n    inputs:\n      cs_image: \"$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA\"\n\n```\nIn this example, the SAST component is pinned at Version 2.0.2, the Dependency Scanning component at Version 0.2.0, the Secret Detection component at Version 1.1.2, and the Container Scanning component at Version 4.1.0. `~latest` [and more tags are available](https://docs.gitlab.com/ee/ci/components/#component-versions) for bleeding-edge component usage and other development needs.\n\nWhether you use templates or components, your pipeline might look like the image below. The top four jobs in the test stage are the result of the four include statements in the code above.\n\n![An example pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097984/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097983863.png)\n\n### Advantages and disadvantages of using pipeline includes\n\n#### Ease of use\n\nOne of the benefits of using pipeline includes in GitLab is their ease of use. We have seen how, with essentially six lines of code, we included four commonly used security scanners. All the complex logic and setup are handled within the templates or components, saving Sacha time and effort by providing a ready-to-use solution.\n\n#### Customization\n\nWhile templates offer the highest flexibility (variables and merging), it's important to remember that with \"great power comes great responsibility.\" The flexibility of templates supports extensive customization, but requires careful management and oversight to avoid unexpected results.\n\nIn contrast, components provide a more structured mechanism for authoring, sharing, and maintaining building blocks for a broader audience. Components, while not as customizable, enhance stability and reliability, and are a valuable, reusable, and repeatable feature. \n\n#### Enforcement\n\nAs the name _include_ suggests, it is the GitLab project pipeline that needs to include templates or components. While scanner templates are straightforward to use, Amy and Priyanka cannot be sure Sacha has included them properly, or even at all. Enforcement of scanner usage is needed.\n\nFor regulated industries, managing security in project pipelines is not an approach that provides the necessary audit trail or enforcement.\n\n## Compliance frameworks\n\nGitLab identified the gap between the ability to enforce security scans on project pipelines and the need to [adhere to regulatory compliance frameworks](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/) such as PCI DSS, NIST, and many more. The introduction of compliance frameworks as functionality caters to precisely this challenge.\n\nAt first glance, a compliance framework in GitLab is merely a label attached to a project, which would typically be named after the regulatory framework it is supposed to implement. The magic is added with the link between that label and a compliance pipeline YAML file, which is responsible for implementing the necessary steps to ensure compliance. \n\nThe mechanism is straightforward: Every time the project pipeline is triggered, GitLab executes the compliance pipeline instead. The compliance pipeline runs with both the [CI/CD variables](https://docs.gitlab.com/ee/ci/variables/) and [predefined CI/CD variables](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) of the project pipeline.\n\nThis allows for two main design patterns: a \"wrapping pipeline,\" where the compliance pipeline includes the project pipeline, and an \"overriding pipeline,\" where it does not. \n\n**Note:** Compliance pipelines have been deprecated in GitLab Version 17.3 and are scheduled for removal in Version 19.0. At this point, we cannot recommend implementing this approach for new development platforms. However, you might already be using them, making it worth reading this section.\n\n### Wrapping pipelines\n\nIn the wrapping approach, the compliance pipeline defines its own jobs according to specific compliance needs. It includes the project pipeline in the same way we have seen templates included in the previous section. This setup is possible because the predefined CI/CD variables originate from the project pipeline, allowing the system to identify the pipeline definition's location for inclusion.\n\nHere is an example of what a simple compliance pipeline might look like. \n\n```yaml\ninclude:\n  - component: $CI_SERVER_FQDN/components/sast/sast@2.0.2\n  - component: $CI_SERVER_FQDN/components/dependency-scanning/cargo@0.2.0\n  - component: $CI_SERVER_FQDN/components/secret-detection/secret-detection@1.1.2\n  - component: $CI_SERVER_FQDN/components/container-scanning/container-scanning@4.1.0\n  - project: '$CI_PROJECT_PATH'\n    file: '$CI_CONFIG_PATH'\n    ref: '$CI_COMMIT_SHA'\n\n```\n\nThe last three lines include the project pipeline based on available variables.\n\n### Overriding pipelines\n\nUnlike wrapping pipelines, which include the project pipeline, overriding pipelines ignore it entirely and run only their own jobs. This type of pipeline defines each step, encompassing all necessary jobs to build, test, and deploy the application.\n\nBelow we see a mock compliance pipeline that illustrates this approach.\n\n```yaml\nstages: [\"build\", \"test\", \"deploy\"]\n\ninclude:\n  - component: $CI_SERVER_FQDN/components/sast/sast@2.0.2\n  - component: $CI_SERVER_FQDN/components/dependency-scanning/cargo@0.2.0\n  - component: $CI_SERVER_FQDN/components/secret-detection/secret-detection@1.1.2\n  - component: $CI_SERVER_FQDN/components/container-scanning/container-scanning@4.1.0\n\nbuild-job:\n  stage: build\n  script: echo \"Building the container image\"\n\ntest-job:\n  stage: test\n  script: echo \"Running unit tests\"\n\ndeploy-job:\n  stage: deploy\n  script: echo \"Deploying app\"\n\n```\n\n### Advantages and disadvantages of compliance frameworks\n\n#### Ease of use\n\nWhile compliance frameworks aren't terribly complicated, they aren't as straightforward and simple as pipeline includes. They're meant to be written and assigned to projects by Amy and Priyanka, who now need to interact with pipeline YAML code. A framework needs to be declared in the top-level namespace and compliance pipelines need to be created and maintained, and compliance frameworks need to be attached to the right projects. \n\n#### Customization\n\nAmy and Priyanka are the authors of compliance pipelines. Like Sacha in the previous section on includes, they have full control over what they include and how they include it, giving them maximum customizability of compliance jobs such as security scanners.\n\n#### Enforcement\nThis aspect of enforcing pipelines questions whether developers can tamper with security jobs? In an environment with a strong separation of duties, this nuance requires some extra attention. To answer this, we need to look at each pattern separately:\n\n##### Wrapping pipelines\nAs seen before, project pipelines are included in compliance pipelines. In addition to group- or project-level CI/CD variables, every element of that project pipeline must be considered a potential threat to the compliance pipeline. Obviously, variables and jobs stick out as primary candidates. And, in fact, they can and will influence security job behavior if used maliciously.\n\nHere is a simple example to illustrate the issue.\n\nCompliance pipeline:\n```yaml\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n  - project: '$CI_PROJECT_PATH'\n    file: '$CI_CONFIG_PATH'\n    ref: '$CI_COMMIT_SHA'\n\n```\n\nProject pipeline:\n```yaml\nvariables:\n  SECRET_DETECTION_DISABLED: true\n\nsemgrep-sast:\n  rules:\n    - when: never\n\n```\n\nThis project pipeline declares a variable `SECRET_DETECTION_DISABLED` (this could be done via project or croup-level CI/CD variables, too), which is evaluated in the included secret detection template. Further, the last three lines use the merging mechanism discussed previously, to not execute the job at all. Kind of redundant, we know.\n\nBoth overrides could be prevented using components, but you get the idea. Components, too, are receptive to such attacks via their inputs' default values, which often use variables, too! Let's take a look at how this could be taken advantage of.\n\nCompliance pipeline:\n```yaml\ninclude:\n  - component: $CI_SERVER_FQDN/components/sast/sast@2.0.2\n  - component: $CI_SERVER_FQDN/components/secret-detection/secret-detection@1.1.2\n  - project: '$CI_PROJECT_PATH'\n    file: '$CI_CONFIG_PATH'\n    ref: '$CI_COMMIT_SHA'\n\n```\n\nProject pipeline:\n```yaml\nvariables:\n  CI_TEMPLATE_REGISTRY_HOST: \"docker.io\"\n\n```\n\nTo understand what is happening here, look at the [SAST scanner component's Line 6](https://gitlab.com/components/sast/-/blob/main/templates/sast.yml?ref_type=heads#L6):\n\n```yaml\nspec:\n  inputs:\n    stage:\n      default: test\n    image_prefix:\n      default: \"$CI_TEMPLATE_REGISTRY_HOST/security-products\"\n\n```\n\nThe `image_prefix` input uses the `CI_TEMPLATE_REGISTRY_HOST` to build the default value. By setting this variable to a false value in the same way we set `SECRET_DETECTION_DISABLED` to `true` before, Sacha may cause the job to load a wrong image and break SAST testing.\n\nTo prevent this override ability by the developer role, avoid templates in favor of components. This approach covers many developer-induced loopholes. To be certain of compliance, hardcode values for component inputs.\n\n##### Overriding pipelines\n\nThis type is an entirely different beast. Developers get no chance of injecting actual pipeline code into the compliance pipeline. However, compliance pipelines do run with the project's CI/CD variables. Hence, any variable specified on the group- or project-level might modify the compliance pipeline's behavior. With `SECRET_DETECTION_DISABLED` set to `true` in the project CI/CD variables, the following compliance pipeline can be modified again:\n\n```yaml\nstages: [\"build\", \"test\", \"deploy\"]\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n\nbuild-job: ...\ntest-job: ...\ndeploy-job: ...\n```\n\nComponents can solve this particular problem, but, as before, component inputs may use CI/CD variables developers can set. Compliance pipeline authors need to identify and take care of these situations. \n\n## Policies\n\nCompliance pipelines' shortcomings have led to the next step for managing compliance: [policies](https://docs.gitlab.com/ee/user/application_security/policies/).\n\nGitLab introduced [policies](https://docs.gitlab.com/ee/user/application_security/policies/) as the way forward. Authors store a set of policies in a separate project as YAML files and apply them to projects on the group or project level. This gives Amy and Priyanka the flexibility to target individual projects with specific requirements but also to ensure compliance across the entire organization if needed. Access to the policy project can be controlled within the policy project and audited within GitLab.\n\nPolicies come in different types for different purposes. The types we are interested in right now are scan execution policies (SEP) and pipeline execution policies (PEP).\n\n### Scan execution policies\n\nAs the name suggests, SEPs require a particular scan – or set of scans – to be executed as part of the project pipeline and inject the respective scan jobs into the pipelines of associated projects. They include the respective [template](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Jobs) in the pipeline according to variables and rules set by Amy and Priyanka.\n\nGitLab supports policy authors with a comprehensive user interface in addition to a YAML-based Git workflow. The following screenshot and code snippet illustrate a very basic example of a SEP:\n\n![Scan execution policy example](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097984/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097983864.png)\n\n```yaml\nname: Secret Scanner\ndescription: ''\nenabled: true\nactions:\n- scan: secret_detection\nrules:\n- type: pipeline\n  branches:\n  - \"*\"\n\n```\n\nFor more details on SEP settings in the UI and YAML, please refer to the [policy documentation](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html).\n\n#### Advantages and disadvantages of scan execution policies\n\n##### Ease of use\nSEPs provide a lightweight, easy-to-use mechanism that enforces security on existing and new CI/CD pipelines across the organization or on a granular level. The UI support makes them a viable tool for all relevant personas.\n\n##### Customization\nSEPs are restricted to predefined scanner jobs, and there is no option to extend this list with custom jobs at this point. This limitation can be restrictive for teams with unique scanning requirements that fall outside the standard options.\n\n##### Enforcement\n\nOnce an SEP is applied to a project (directly or indirectly), Sacha has no way to get rid of that scan job. Though, there may be ways to – intentionally or not – manipulate the scan job's behavior.\n\nJobs injected via SEPs generally are receptive to CI/CD variables and adhere to the general rules of [variable precedence](https://docs.gitlab.com/ee/ci/variables/index.html#cicd-variable-precedence). For this injection, Policies incorporate logic that denies changing some predefined variables as described [here](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html#cicd-variables) and generally deny the configuration of variables that follow certain patterns such as `_DISABLED` or  `_EXCLUDED_PATHS`.\n\nDespite these security measures, inconsiderate use of policies may still open opportunities for tampering: In my test, I was able to set a project-level CI/CD variable `SECURE_ANALYZERS_PREFIX` to a bad value (a non-existing location) and as you can see [here](https://gitlab.com/gitlab-org/gitlab/-/blob/a2d4b8df0095c1363a105a1fa212daf227eca063/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml), the secret detection template uses that to build the location of the scanner image.\n\nWhile the scan job does get included in the pipeline run, it crashes very early and, therefore, provides no scan results. Due to the [`allow_failure: true` configuration](https://gitlab.com/gitlab-org/gitlab/-/blob/a2d4b8df0095c1363a105a1fa212daf227eca063/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml#L18), the pipeline will continue to run and eventually execute a deploy job.\n\nBecause SEP variables take the highest variable precedence, there is an easy fix to reduce the attack surface of the policy: Simply hardcode the correct value in your policy YAML or via the UI:\n\n```yaml\n- name: Secret Scanner\n  actions:\n  - scan: secret_detection\n    variables:\n      SECURE_ANALYZERS_PREFIX: registry.gitlab.com/security-products\n\n```\n\n### Pipeline execution policies\n\nSEPs enable the injection of a set of security-related jobs into any project pipeline. In contrast, PEPs apply entire pipeline configurations to projects, offering a lot more flexibility when it comes to customizing security constraints. \n\nThere are two methods for implementing these policies, known as \"actions\": `inject` and `override`. These actions function similarly to the patterns we have seen in the compliance frameworks section and provide flexible ways to enhance and enforce security standards within the development workflow.\n\n#### Injecting pipelines\n\nInjecting pipelines involves adding the jobs and other elements defined in the policy pipeline into the project pipeline. Currently, jobs should only be injected into reserved stages, namely `.pipeline-policy-pre` and `.pipeline-policy-post` to avoid unpredictable results.\n\nGitLab handles name clashes between jobs or variables in policy and project pipelines effectively by building each pipeline in isolation before combining them. This ensures that the integration process is seamless and does not disrupt existing workflows or configurations.\n\n![security scanning - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097984/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097983865.png)\n\nThe above screenshot shows an example of an injected policy pipeline. Project pipeline jobs are prefixed with `prj-` for easier identification.\n\n#### Overriding pipelines\n\nIn the override approach, the project pipeline is completely replaced by the policy pipeline. This method is similar to compliance pipelines that do not include the project's `.gitlab-ci.yml` file. Despite the override, the pipelines run using the project's CI/CD variables, maintaining consistency with project-specific configurations. The compliance pipeline we used earlier makes a perfectly fine policy pipeline, too:\n\n```yaml\nstages: [\"build\", \"test\", \"deploy\"]\n\ninclude:\n  - component: $CI_SERVER_FQDN/components/sast/sast@2.0.2\n  - component: $CI_SERVER_FQDN/components/dependency-scanning/cargo@0.2.0\n  - component: $CI_SERVER_FQDN/components/secret-detection/secret-detection@1.1.2\n  - component: $CI_SERVER_FQDN/components/container-scanning/container-scanning@4.1.0\n\nbuild-job:\n  stage: build\n  script: echo \"Building the container image\"\n\ntest-job:\n  stage: test\n  script: echo \"Running unit tests\"\n\ndeploy-job:\n  stage: deploy\n  script: echo \"Deploying app\"\n\n```\n\nThe image below shows a slightly more complete pipeline than the mock pipeline above:\n\n![More complete pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097984/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097983866.png)\n\n**Note:** This doesn't currently work with SEPs.\n\nHowever, the existence of a Dockerfile may not always be a valid indicator, as developers might be building without Dockerfiles using Cloud Native Buildpacks, Heroku Buildpacks, Kaniko, or other tools. Managed pipelines do not encounter this challenge, as they are more controlled and centralized.\n\n\u003C!-- TOC ignore:true -->\n### Projects with multiple container images\nFor projects that produce multiple container images, several container scanning jobs would be necessary for proper coverage. This raises similar questions as before: \"How do we know there are multiple?\" and \"Is the source of that information trustworthy?\". If we wanted to rely on the existence of `Dockerfile`s a [dynamic approach](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html#dynamic-child-pipelines) would be necessary that includes a container scanning job for each `Dockerfile` detected.\n\n## Get started with security scanning\nIn this article, you've learned about a variety of approaches to adding security scanning to CI/CD pipelines with a close look at ease of use, customizability, and the ability to strictly enforce scanning. You've seen that a pipeline author who is held responsible for project compliance needs to keep a few things in mind during the process to avoid surprises down the line. We recommend building a small testing space on your GitLab instance and then run a few tests to reproduce the main points of this article. Put yourself in the shoes of a malicious Sacha (Sachas aren't generally malicious people, but it's a good exercise) and think about how you could fool that annoying Amy and her security scans.\n\nGitLab provides strong support for all sorts of requirements and all approaches are – at least in our eyes – easy to implement due the platform's baked-in functionality. You should find ways to bulletproof your scan jobs and, if not, you should open a ticket with our support. \n\nHappy pipelining!\n\n> #### Get started with security scanning today!\n> [Sign up for a free trial of GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial) to implement security scanning in your software development lifecycle.\n\n## Read more\n\n- [Meet regulatory standards with GitLab security and compliance](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)\n- [How to integrate custom security scanners into GitLab](https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab/)\n- [Integrate external security scanners into your DevSecOps workflow](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/)\n",[10,25,26],"tutorial","CI/CD","yml",{},"/en-us/blog/how-to-choose-the-right-security-scanning-approach",{"title":16,"description":17,"ogTitle":16,"ogDescription":17,"noIndex":31,"ogImage":21,"ogUrl":32,"ogSiteName":33,"ogType":34,"canonicalUrls":32},false,"https://about.gitlab.com/blog/how-to-choose-the-right-security-scanning-approach","https://about.gitlab.com","article","en-us/blog/how-to-choose-the-right-security-scanning-approach",[10,25,37],"cicd","8ZSJvyQgRkwbsCfhVhGiDW01d0WuEdyDRmR-sdsi8xM",{"data":40},{"logo":41,"freeTrial":46,"sales":51,"login":56,"items":61,"search":368,"minimal":399,"duo":418,"pricingDeployment":428},{"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,89,183,188,289,349],{"text":63,"config":64,"cards":66},"Platform",{"dataNavLevelOne":65},"platform",[67,73,81],{"title":63,"description":68,"link":69},"The intelligent orchestration platform for DevSecOps",{"text":70,"config":71},"Explore our Platform",{"href":72,"dataGaName":65,"dataGaLocation":45},"/platform/",{"title":74,"description":75,"link":76},"GitLab Duo Agent Platform","Agentic AI for the entire software lifecycle",{"text":77,"config":78},"Meet GitLab Duo",{"href":79,"dataGaName":80,"dataGaLocation":45},"/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":82,"description":83,"link":84},"Why GitLab","See the top reasons enterprises choose GitLab",{"text":85,"config":86},"Learn more",{"href":87,"dataGaName":88,"dataGaLocation":45},"/why-gitlab/","why gitlab",{"text":90,"left":13,"config":91,"link":93,"lists":97,"footer":165},"Product",{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"View all Solutions",{"href":96,"dataGaName":92,"dataGaLocation":45},"/solutions/",[98,121,144],{"title":99,"description":100,"link":101,"items":106},"Automation","CI/CD and automation to accelerate deployment",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":45},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[107,110,113,117],{"text":26,"config":108},{"href":109,"dataGaLocation":45,"dataGaName":26},"/solutions/continuous-integration/",{"text":74,"config":111},{"href":79,"dataGaLocation":45,"dataGaName":112},"gitlab duo agent platform - product menu",{"text":114,"config":115},"Source Code Management",{"href":116,"dataGaLocation":45,"dataGaName":114},"/solutions/source-code-management/",{"text":118,"config":119},"Automated Software Delivery",{"href":104,"dataGaLocation":45,"dataGaName":120},"Automated software delivery",{"title":122,"description":123,"link":124,"items":129},"Security","Deliver code faster without compromising security",{"config":125},{"href":126,"dataGaName":127,"dataGaLocation":45,"icon":128},"/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[130,134,139],{"text":131,"config":132},"Application Security Testing",{"href":126,"dataGaName":133,"dataGaLocation":45},"Application security testing",{"text":135,"config":136},"Software Supply Chain Security",{"href":137,"dataGaLocation":45,"dataGaName":138},"/solutions/supply-chain/","Software supply chain security",{"text":140,"config":141},"Software Compliance",{"href":142,"dataGaName":143,"dataGaLocation":45},"/solutions/software-compliance/","software compliance",{"title":145,"link":146,"items":151},"Measurement",{"config":147},{"icon":148,"href":149,"dataGaName":150,"dataGaLocation":45},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[152,156,160],{"text":153,"config":154},"Visibility & Measurement",{"href":149,"dataGaLocation":45,"dataGaName":155},"Visibility and Measurement",{"text":157,"config":158},"Value Stream Management",{"href":159,"dataGaLocation":45,"dataGaName":157},"/solutions/value-stream-management/",{"text":161,"config":162},"Analytics & Insights",{"href":163,"dataGaLocation":45,"dataGaName":164},"/solutions/analytics-and-insights/","Analytics and insights",{"title":166,"items":167},"GitLab for",[168,173,178],{"text":169,"config":170},"Enterprise",{"href":171,"dataGaLocation":45,"dataGaName":172},"/enterprise/","enterprise",{"text":174,"config":175},"Small Business",{"href":176,"dataGaLocation":45,"dataGaName":177},"/small-business/","small business",{"text":179,"config":180},"Public Sector",{"href":181,"dataGaLocation":45,"dataGaName":182},"/solutions/public-sector/","public sector",{"text":184,"config":185},"Pricing",{"href":186,"dataGaName":187,"dataGaLocation":45,"dataNavLevelOne":187},"/pricing/","pricing",{"text":189,"config":190,"link":192,"lists":196,"feature":276},"Resources",{"dataNavLevelOne":191},"resources",{"text":193,"config":194},"View all resources",{"href":195,"dataGaName":191,"dataGaLocation":45},"/resources/",[197,230,248],{"title":198,"items":199},"Getting started",[200,205,210,215,220,225],{"text":201,"config":202},"Install",{"href":203,"dataGaName":204,"dataGaLocation":45},"/install/","install",{"text":206,"config":207},"Quick start guides",{"href":208,"dataGaName":209,"dataGaLocation":45},"/get-started/","quick setup checklists",{"text":211,"config":212},"Learn",{"href":213,"dataGaLocation":45,"dataGaName":214},"https://university.gitlab.com/","learn",{"text":216,"config":217},"Product documentation",{"href":218,"dataGaName":219,"dataGaLocation":45},"https://docs.gitlab.com/","product documentation",{"text":221,"config":222},"Best practice videos",{"href":223,"dataGaName":224,"dataGaLocation":45},"/getting-started-videos/","best practice videos",{"text":226,"config":227},"Integrations",{"href":228,"dataGaName":229,"dataGaLocation":45},"/integrations/","integrations",{"title":231,"items":232},"Discover",[233,238,243],{"text":234,"config":235},"Customer success stories",{"href":236,"dataGaName":237,"dataGaLocation":45},"/customers/","customer success stories",{"text":239,"config":240},"Blog",{"href":241,"dataGaName":242,"dataGaLocation":45},"/blog/","blog",{"text":244,"config":245},"Remote",{"href":246,"dataGaName":247,"dataGaLocation":45},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":249,"items":250},"Connect",[251,256,261,266,271],{"text":252,"config":253},"GitLab Services",{"href":254,"dataGaName":255,"dataGaLocation":45},"/services/","services",{"text":257,"config":258},"Community",{"href":259,"dataGaName":260,"dataGaLocation":45},"/community/","community",{"text":262,"config":263},"Forum",{"href":264,"dataGaName":265,"dataGaLocation":45},"https://forum.gitlab.com/","forum",{"text":267,"config":268},"Events",{"href":269,"dataGaName":270,"dataGaLocation":45},"/events/","events",{"text":272,"config":273},"Partners",{"href":274,"dataGaName":275,"dataGaLocation":45},"/partners/","partners",{"backgroundColor":277,"textColor":278,"text":279,"image":280,"link":284},"#2f2a6b","#fff","Insights for the future of software development",{"altText":281,"config":282},"the source promo card",{"src":283},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":285,"config":286},"Read the latest",{"href":287,"dataGaName":288,"dataGaLocation":45},"/the-source/","the source",{"text":290,"config":291,"lists":293},"Company",{"dataNavLevelOne":292},"company",[294],{"items":295},[296,301,307,309,314,319,324,329,334,339,344],{"text":297,"config":298},"About",{"href":299,"dataGaName":300,"dataGaLocation":45},"/company/","about",{"text":302,"config":303,"footerGa":306},"Jobs",{"href":304,"dataGaName":305,"dataGaLocation":45},"/jobs/","jobs",{"dataGaName":305},{"text":267,"config":308},{"href":269,"dataGaName":270,"dataGaLocation":45},{"text":310,"config":311},"Leadership",{"href":312,"dataGaName":313,"dataGaLocation":45},"/company/team/e-group/","leadership",{"text":315,"config":316},"Team",{"href":317,"dataGaName":318,"dataGaLocation":45},"/company/team/","team",{"text":320,"config":321},"Handbook",{"href":322,"dataGaName":323,"dataGaLocation":45},"https://handbook.gitlab.com/","handbook",{"text":325,"config":326},"Investor relations",{"href":327,"dataGaName":328,"dataGaLocation":45},"https://ir.gitlab.com/","investor relations",{"text":330,"config":331},"Trust Center",{"href":332,"dataGaName":333,"dataGaLocation":45},"/security/","trust center",{"text":335,"config":336},"AI Transparency Center",{"href":337,"dataGaName":338,"dataGaLocation":45},"/ai-transparency-center/","ai transparency center",{"text":340,"config":341},"Newsletter",{"href":342,"dataGaName":343,"dataGaLocation":45},"/company/contact/#contact-forms","newsletter",{"text":345,"config":346},"Press",{"href":347,"dataGaName":348,"dataGaLocation":45},"/press/","press",{"text":350,"config":351,"lists":352},"Contact us",{"dataNavLevelOne":292},[353],{"items":354},[355,358,363],{"text":52,"config":356},{"href":54,"dataGaName":357,"dataGaLocation":45},"talk to sales",{"text":359,"config":360},"Support portal",{"href":361,"dataGaName":362,"dataGaLocation":45},"https://support.gitlab.com","support portal",{"text":364,"config":365},"Customer portal",{"href":366,"dataGaName":367,"dataGaLocation":45},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":369,"login":370,"suggestions":377},"Close",{"text":371,"link":372},"To search repositories and projects, login to",{"text":373,"config":374},"gitlab.com",{"href":59,"dataGaName":375,"dataGaLocation":376},"search login","search",{"text":378,"default":379},"Suggestions",[380,382,386,388,392,396],{"text":74,"config":381},{"href":79,"dataGaName":74,"dataGaLocation":376},{"text":383,"config":384},"Code Suggestions (AI)",{"href":385,"dataGaName":383,"dataGaLocation":376},"/solutions/code-suggestions/",{"text":26,"config":387},{"href":109,"dataGaName":26,"dataGaLocation":376},{"text":389,"config":390},"GitLab on AWS",{"href":391,"dataGaName":389,"dataGaLocation":376},"/partners/technology-partners/aws/",{"text":393,"config":394},"GitLab on Google Cloud",{"href":395,"dataGaName":393,"dataGaLocation":376},"/partners/technology-partners/google-cloud-platform/",{"text":397,"config":398},"Why GitLab?",{"href":87,"dataGaName":397,"dataGaLocation":376},{"freeTrial":400,"mobileIcon":405,"desktopIcon":410,"secondaryButton":413},{"text":401,"config":402},"Start free trial",{"href":403,"dataGaName":50,"dataGaLocation":404},"https://gitlab.com/-/trials/new/","nav",{"altText":406,"config":407},"Gitlab Icon",{"src":408,"dataGaName":409,"dataGaLocation":404},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":406,"config":411},{"src":412,"dataGaName":409,"dataGaLocation":404},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":414,"config":415},"Get Started",{"href":416,"dataGaName":417,"dataGaLocation":404},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/get-started/","get started",{"freeTrial":419,"mobileIcon":424,"desktopIcon":426},{"text":420,"config":421},"Learn more about GitLab Duo",{"href":422,"dataGaName":423,"dataGaLocation":404},"/gitlab-duo/","gitlab duo",{"altText":406,"config":425},{"src":408,"dataGaName":409,"dataGaLocation":404},{"altText":406,"config":427},{"src":412,"dataGaName":409,"dataGaLocation":404},{"freeTrial":429,"mobileIcon":434,"desktopIcon":436},{"text":430,"config":431},"Back to pricing",{"href":186,"dataGaName":432,"dataGaLocation":404,"icon":433},"back to pricing","GoBack",{"altText":406,"config":435},{"src":408,"dataGaName":409,"dataGaLocation":404},{"altText":406,"config":437},{"src":412,"dataGaName":409,"dataGaLocation":404},{"title":439,"button":440,"config":445},"See how agentic AI transforms software delivery",{"text":441,"config":442},"Watch GitLab Transcend now",{"href":443,"dataGaName":444,"dataGaLocation":45},"/events/transcend/virtual/","transcend event",{"layout":446,"icon":447},"release","AiStar",{"data":449},{"text":450,"source":451,"edit":457,"contribute":462,"config":467,"items":472,"minimal":678},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":452,"config":453},"View page source",{"href":454,"dataGaName":455,"dataGaLocation":456},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":458,"config":459},"Edit this page",{"href":460,"dataGaName":461,"dataGaLocation":456},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":463,"config":464},"Please contribute",{"href":465,"dataGaName":466,"dataGaLocation":456},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":468,"facebook":469,"youtube":470,"linkedin":471},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[473,520,573,617,644],{"title":184,"links":474,"subMenu":489},[475,479,484],{"text":476,"config":477},"View plans",{"href":186,"dataGaName":478,"dataGaLocation":456},"view plans",{"text":480,"config":481},"Why Premium?",{"href":482,"dataGaName":483,"dataGaLocation":456},"/pricing/premium/","why premium",{"text":485,"config":486},"Why Ultimate?",{"href":487,"dataGaName":488,"dataGaLocation":456},"/pricing/ultimate/","why ultimate",[490],{"title":491,"links":492},"Contact Us",[493,496,498,500,505,510,515],{"text":494,"config":495},"Contact sales",{"href":54,"dataGaName":55,"dataGaLocation":456},{"text":359,"config":497},{"href":361,"dataGaName":362,"dataGaLocation":456},{"text":364,"config":499},{"href":366,"dataGaName":367,"dataGaLocation":456},{"text":501,"config":502},"Status",{"href":503,"dataGaName":504,"dataGaLocation":456},"https://status.gitlab.com/","status",{"text":506,"config":507},"Terms of use",{"href":508,"dataGaName":509,"dataGaLocation":456},"/terms/","terms of use",{"text":511,"config":512},"Privacy statement",{"href":513,"dataGaName":514,"dataGaLocation":456},"/privacy/","privacy statement",{"text":516,"config":517},"Cookie preferences",{"dataGaName":518,"dataGaLocation":456,"id":519,"isOneTrustButton":13},"cookie preferences","ot-sdk-btn",{"title":90,"links":521,"subMenu":530},[522,526],{"text":523,"config":524},"DevSecOps platform",{"href":72,"dataGaName":525,"dataGaLocation":456},"devsecops platform",{"text":527,"config":528},"AI-Assisted Development",{"href":422,"dataGaName":529,"dataGaLocation":456},"ai-assisted development",[531],{"title":532,"links":533},"Topics",[534,538,543,548,553,558,563,568],{"text":535,"config":536},"CICD",{"href":537,"dataGaName":37,"dataGaLocation":456},"/topics/ci-cd/",{"text":539,"config":540},"GitOps",{"href":541,"dataGaName":542,"dataGaLocation":456},"/topics/gitops/","gitops",{"text":544,"config":545},"DevOps",{"href":546,"dataGaName":547,"dataGaLocation":456},"/topics/devops/","devops",{"text":549,"config":550},"Version Control",{"href":551,"dataGaName":552,"dataGaLocation":456},"/topics/version-control/","version control",{"text":554,"config":555},"DevSecOps",{"href":556,"dataGaName":557,"dataGaLocation":456},"/topics/devsecops/","devsecops",{"text":559,"config":560},"Cloud Native",{"href":561,"dataGaName":562,"dataGaLocation":456},"/topics/cloud-native/","cloud native",{"text":564,"config":565},"AI for Coding",{"href":566,"dataGaName":567,"dataGaLocation":456},"/topics/devops/ai-for-coding/","ai for coding",{"text":569,"config":570},"Agentic AI",{"href":571,"dataGaName":572,"dataGaLocation":456},"/topics/agentic-ai/","agentic ai",{"title":574,"links":575},"Solutions",[576,578,580,585,589,592,596,599,601,604,607,612],{"text":131,"config":577},{"href":126,"dataGaName":131,"dataGaLocation":456},{"text":120,"config":579},{"href":104,"dataGaName":105,"dataGaLocation":456},{"text":581,"config":582},"Agile development",{"href":583,"dataGaName":584,"dataGaLocation":456},"/solutions/agile-delivery/","agile delivery",{"text":586,"config":587},"SCM",{"href":116,"dataGaName":588,"dataGaLocation":456},"source code management",{"text":535,"config":590},{"href":109,"dataGaName":591,"dataGaLocation":456},"continuous integration & delivery",{"text":593,"config":594},"Value stream management",{"href":159,"dataGaName":595,"dataGaLocation":456},"value stream management",{"text":539,"config":597},{"href":598,"dataGaName":542,"dataGaLocation":456},"/solutions/gitops/",{"text":169,"config":600},{"href":171,"dataGaName":172,"dataGaLocation":456},{"text":602,"config":603},"Small business",{"href":176,"dataGaName":177,"dataGaLocation":456},{"text":605,"config":606},"Public sector",{"href":181,"dataGaName":182,"dataGaLocation":456},{"text":608,"config":609},"Education",{"href":610,"dataGaName":611,"dataGaLocation":456},"/solutions/education/","education",{"text":613,"config":614},"Financial services",{"href":615,"dataGaName":616,"dataGaLocation":456},"/solutions/finance/","financial services",{"title":189,"links":618},[619,621,623,625,628,630,632,634,636,638,640,642],{"text":201,"config":620},{"href":203,"dataGaName":204,"dataGaLocation":456},{"text":206,"config":622},{"href":208,"dataGaName":209,"dataGaLocation":456},{"text":211,"config":624},{"href":213,"dataGaName":214,"dataGaLocation":456},{"text":216,"config":626},{"href":218,"dataGaName":627,"dataGaLocation":456},"docs",{"text":239,"config":629},{"href":241,"dataGaName":242,"dataGaLocation":456},{"text":234,"config":631},{"href":236,"dataGaName":237,"dataGaLocation":456},{"text":244,"config":633},{"href":246,"dataGaName":247,"dataGaLocation":456},{"text":252,"config":635},{"href":254,"dataGaName":255,"dataGaLocation":456},{"text":257,"config":637},{"href":259,"dataGaName":260,"dataGaLocation":456},{"text":262,"config":639},{"href":264,"dataGaName":265,"dataGaLocation":456},{"text":267,"config":641},{"href":269,"dataGaName":270,"dataGaLocation":456},{"text":272,"config":643},{"href":274,"dataGaName":275,"dataGaLocation":456},{"title":290,"links":645},[646,648,650,652,654,656,658,662,667,669,671,673],{"text":297,"config":647},{"href":299,"dataGaName":292,"dataGaLocation":456},{"text":302,"config":649},{"href":304,"dataGaName":305,"dataGaLocation":456},{"text":310,"config":651},{"href":312,"dataGaName":313,"dataGaLocation":456},{"text":315,"config":653},{"href":317,"dataGaName":318,"dataGaLocation":456},{"text":320,"config":655},{"href":322,"dataGaName":323,"dataGaLocation":456},{"text":325,"config":657},{"href":327,"dataGaName":328,"dataGaLocation":456},{"text":659,"config":660},"Sustainability",{"href":661,"dataGaName":659,"dataGaLocation":456},"/sustainability/",{"text":663,"config":664},"Diversity, inclusion and belonging (DIB)",{"href":665,"dataGaName":666,"dataGaLocation":456},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":330,"config":668},{"href":332,"dataGaName":333,"dataGaLocation":456},{"text":340,"config":670},{"href":342,"dataGaName":343,"dataGaLocation":456},{"text":345,"config":672},{"href":347,"dataGaName":348,"dataGaLocation":456},{"text":674,"config":675},"Modern Slavery Transparency Statement",{"href":676,"dataGaName":677,"dataGaLocation":456},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":679},[680,683,686],{"text":681,"config":682},"Terms",{"href":508,"dataGaName":509,"dataGaLocation":456},{"text":684,"config":685},"Cookies",{"dataGaName":518,"dataGaLocation":456,"id":519,"isOneTrustButton":13},{"text":687,"config":688},"Privacy",{"href":513,"dataGaName":514,"dataGaLocation":456},[690,703],{"id":691,"title":19,"body":9,"config":692,"content":694,"description":9,"extension":27,"meta":698,"navigation":13,"path":699,"seo":700,"stem":701,"__hash__":702},"blogAuthors/en-us/blog/authors/matt-genelin.yml",{"template":693},"BlogAuthor",{"name":19,"config":695},{"headshot":696,"ctfId":697},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664522/Blog/Author%20Headshots/matty_genelin.png","6x9dTYZik3lSViI8hu6dYQ",{},"/en-us/blog/authors/matt-genelin",{},"en-us/blog/authors/matt-genelin","BNd-jZWck4DOyJIDc9GI-734vQkyzXJgudpPaFgn5pM",{"id":704,"title":20,"body":9,"config":705,"content":706,"description":9,"extension":27,"meta":710,"navigation":13,"path":711,"seo":712,"stem":713,"__hash__":714},"blogAuthors/en-us/blog/authors/mathias-ewald.yml",{"template":693},{"name":20,"config":707},{"headshot":708,"ctfId":709},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664526/Blog/Author%20Headshots/mathias_ewald_headshot.png","7vLTPhU3yvh4xTToXcLpg9",{},"/en-us/blog/authors/mathias-ewald",{},"en-us/blog/authors/mathias-ewald","6h3mh_Isl2z7n-akRG5H9ijs9YS5wqTMLWKfyPjjDyQ",[716,728,743],{"content":717,"config":726},{"title":718,"description":719,"authors":720,"tags":722,"heroImage":723,"category":10,"date":724,"body":725},"A complete guide to GitLab Container Scanning","Explore GitLab's various container scanning methods and learn how to secure containers at every lifecycle stage.",[721],"Fernando Diaz",[10,25],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772721753/frfsm1qfscwrmsyzj1qn.png","2026-03-05","Container vulnerabilities don't wait for your next deployment. They can emerge at any\npoint, including when you build an image or while containers run in production.\nGitLab addresses this reality with multiple container scanning approaches, each designed\nfor different stages of your container lifecycle.\n\nIn this guide, we'll explore the different types of container scanning GitLab offers,\nhow to enable each one, and common configurations to get you started.\n\n## Why container scanning matters\n\nSecurity vulnerabilities in container images create risk throughout your application\nlifecycle. Base images, OS packages, and application dependencies can all harbor\nvulnerabilities that attackers actively exploit. Container scanning detects these risks\nearly, before they reach production, and provides remediation paths when available.\n\nContainer scanning is a critical component of Software Composition Analysis (SCA),\nhelping you understand and secure the external dependencies your containerized\napplications rely on.\n\n## The five types of GitLab Container Scanning\n\nGitLab offers five distinct container scanning approaches, each serving a specific\npurpose in your security strategy.\n\n\n### 1. Pipeline-based Container Scanning\n\n* What it does: Scans container images during your CI/CD pipeline execution,\ncatching vulnerabilities before deployment\n\n* Best for: Shift-left security, blocking vulnerable images from reaching production \n\n* Tier availability: Free, Premium, and Ultimate (with enhanced features in Ultimate)  \n\n* [Documentation](https://docs.gitlab.com/user/application_security/container_scanning/)\n\n\nGitLab uses the Trivy security scanner to analyze container images for\nknown vulnerabilities. When your pipeline runs, the scanner examines your images\nand generates a detailed report.\n\n\n#### How to enable pipeline-based Container Scanning \n\n**Option A: Preconfigured merge request**  \n\n* Navigate to **Secure > Security configuration** in your project.\n* Find the \"Container Scanning\" row.\n* Select **Configure with a merge request**.\n* This automatically creates a merge request with the necessary configuration.  \n\n**Option B: Manual configuration**  \n\n* Add the following to your `.gitlab-ci.yml`:\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n```  \n\n#### Common configurations\n\n**Scan a specific image:**\n\nTo scan a specific image, overwrite the `CS_IMAGE` variable in the `container_scanning` job.\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**Filter by severity threshold:**\n\nTo only find vulnerabilities with a certain severity criteria, overwrite the\n`CS_SEVERITY_THRESHOLD` variable in the `container_scanning` job. In the example\nbelow, only vulnerabilities with a severity of **High** or greater will be displayed.\n\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#### Viewing vulnerabilities in a merge request\n\nViewing Container Scanning vulnerabilities directly within merge requests makes security\nreviews seamless and efficient. Once Container Scanning is configured in your CI/CD\npipeline, GitLab automatically display detected vulnerabilities in the merge request's\n[Security widget](https://docs.gitlab.com/user/project/merge_requests/widgets/#application-security-scanning). \n\n\n![Container Scanning vulnerabilities displayed in MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/lt6elcq6jexdhqatdy8l.png \"Container Scanning vulnerabilities displayed in MR\")\n\n\n\n* Navigate to any merge request and scroll to the \"Security Scanning\" section to see a summary of\nnewly introduced and existing vulnerabilities found in your container images.\n\n* Click on a **Vulnerability** to access detailed information about the finding, including severity level,\naffected packages, and available remediation guidance.\n\n\n![GitLab Security View details in MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/hplihdlekc11uvpfih1p.png)\n\n\n\n![GitLab Security View details in MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/jnxbe7uld8wfeezboifs.png \"Container Scanning vulnerability details in MR\")\n\n\nThis visibility enables developers and security teams to catch and address container\nvulnerabilities before they reach production, making security an integral part of your\ncode review process rather than a separate gate.\n\n\n#### Viewing vulnerabilities in Vulnerability Report\n\nBeyond merge request reviews, GitLab provides a centralized\n[Vulnerability Report](https://docs.gitlab.com/user/application_security/vulnerability_report/) that gives security teams comprehensive visibility across all Container Scanning findings in your project.\n\n\n![Vulnerability Report sorted by Container Scanning](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547524/gagau279fzfgjpnvipm5.png \"Vulnerability Report sorted by Container Scanning\")\n\n\n* Access this report by navigating to **Security & Compliance > Vulnerability Report** in your\nproject sidebar.\n\n* Here you'll find an aggregated view of all container vulnerabilities detected across your branches, with powerful filtering options to sort by severity, status, scanner type, or specific container images.\n\n* You can click on a vulnerabilty to access its Vulnerablity page.\n\n\n![Vulnerability page - 1st view](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547520/e1woxupyoajhrpzrlylj.png)\n\n\n![Vulnerability page - 2nd view](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547521/idzcftcgjc8eryixnbjn.png)\n\n\n![Vulnerability page - 3rd view](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547522/mbbwbbprtf9anqqola10.png \"Vunerability Details for a Container Scanning vulnerability\")\n\n\n[Vulnerability Details](https://docs.gitlab.com/user/application_security/vulnerabilities/)\nshows exactly which container images and layers are impacted, making it easier to trace the\nvulnerability back to its source. You can assign vulnerabilities to team members, change\ntheir status (detected, confirmed, resolved, dismissed), add comments for collaboration,\nand link related issues for tracking remediation work.\n\nThis workflow transforms vulnerability management from a spreadsheet exercise into an integrated part of your development process, ensuring that container security findings are tracked, prioritized, and resolved systematically.\n\n#### View the Dependency List\n\nGitLab's [Dependency List](https://docs.gitlab.com/user/application_security/dependency_list/)\nprovides a comprehensive software bill of materials (SBOM) that catalogs every component within\nyour container images, giving you complete transparency into your software supply chain.\n\n* Navigate to **Security & Compliance > Dependency List** to access an inventory of all packages,\nlibraries, and dependencies detected by Container Scanning across your project.\n\n* This view is invaluable for understanding what's actually running inside your containers, from base OS\npackages to application-level dependencies.\n\n\n![GitLab Dependency List](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/vjg6dk3nhajqamplroji.png \"GitLab Dependency List (SBOM)\")\n\n\nYou can filter the list by package manager, license type, or vulnerability status to quickly\nidentify which components pose security risks or compliance concerns. Each dependency entry\nshows associated vulnerabilities, allowing you to understand security issues in the context\nof your actual software components rather than as isolated findings.\n\n\n### 2. Container Scanning for Registry\n\n* What it does: Automatically scans images pushed to your GitLab Container Registry\nwith the `latest` tag\n\n* Best for: Continuous monitoring of registry images without manual pipeline triggers  \n\n* Tier availability: Ultimate only \n\n* [Documentation](https://docs.gitlab.com/user/application_security/container_scanning/#container-scanning-for-registry) \n\n\nWhen you push a container image tagged `latest`, GitLab's security policy bot\nautomatically triggers a scan against the default branch. Unlike pipeline-based\nscanning, this approach works with Continuous Vulnerability Scanning to monitor\nfor newly published advisories.\n\n#### How to enable Container Scanning for Registry\n\n1. Navigate to **Secure > Security configuration**.\n2. Scroll to the **Container Scanning For Registry** section.\n3. Toggle the feature on.\n\n![Container Scanning for Registry](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547512/vntrlhtmsh1ecnwni5ji.png \"Toggle for Container Scanning for Registry\")\n\n#### Prerequisites\n\n- Maintainer role or higher in the project\n- Project must not be empty (requires at least one commit on the default branch)\n- Container Registry notifications must be configured\n- Package Metadata Database must be configured (enabled by default on GitLab.com)\n\nVulnerabilities appear under the **Container Registry vulnerabilities** tab in your\nVulnerability Report.\n\n\n### 3. Multi-Container Scanning\n\n* What it does: Scans multiple container images in parallel within a single pipeline \n* Best for: Microservices architectures and projects with multiple container images  \n* Tier availability: Free, Premium, and Ultimate (currently in Beta)  \n* [Documentation](https://docs.gitlab.com/user/application_security/container_scanning/multi_container_scanning/) \n\nMulti-Container Scanning uses dynamic child pipelines to run scans concurrently, significantly reducing overall pipeline execution time when you need to scan multiple images.\n\n#### How to enable Multi-Container scanning\n\n1. Create a `.gitlab-multi-image.yml` file in your repository root:\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. Include the template in your `.gitlab-ci.yml`:\n\n```yaml\ninclude:\n  - template: Jobs/Multi-Container-Scanning.latest.gitlab-ci.yml\n```\n\n#### Advanced configuration\n\n**Scan images from private registries:**\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**Include license information:**\n\n```yaml\nincludeLicenses: true\n\nscanTargets:\n  - name: postgres\n    tag: \"15-alpine\"\n```\n\n\n### 4. Continuous Vulnerability Scanning\n\n* What it does: Automatically creates vulnerabilities when new security advisories are published, no pipeline required \n\n* Best for: Proactive security monitoring between deployments\n\n* Tier availability: Ultimate only\n\n* [Documentation](https://docs.gitlab.com/user/application_security/continuous_vulnerability_scanning/)  \n\nTraditional scanning only catches vulnerabilities at scan time. But what happens\nwhen a new CVE is published tomorrow for a package you scanned yesterday? Continuous\nVulnerability Scanning solves this by monitoring the GitLab Advisory Database and\nautomatically creating vulnerability records when new advisories affect your components.\n\n\n#### How it works\n\n1. Your Container Scanning or Dependency Scanning job generates a CycloneDX SBOM.\n\n2. GitLab registers your project's components from this SBOM.\n\n3. When new advisories are published, GitLab checks if your components are affected.\n\n4. Vulnerabilities are automatically created in your vulnerability report.\n\n\n#### Key considerations\n\n- Scans run via background jobs (Sidekiq), not CI pipelines.\n\n- Only advisories published within the last 14 days are considered for new component detection.\n\n- Vulnerabilities use \"GitLab SBoM Vulnerability Scanner\" as the scanner name.\n\n- To mark vulnerabilities as resolved, you still need to run a pipeline-based scan.\n\n\n### 5. Operational Container Scanning\n\n* What it does: Scans running containers in your Kubernetes cluster on a\nscheduled cadence\n\n* Best for: Post-deployment security monitoring and runtime vulnerability detection  \n\n* Tier availability: Ultimate only\n\n* [Documentation](https://docs.gitlab.com/user/clusters/agent/vulnerabilities/)\n\n\nOperational Container Scanning bridges the gap between build-time security and\nruntime security. Using the GitLab Agent for Kubernetes, it scans containers\nactually running in your clusters—catching vulnerabilities that emerge after\ndeployment.\n\n#### How to enable Operational Container Scanning\n\nIf you are using the [GitLab Kubernetes Agent](https://docs.gitlab.com/user/clusters/agent/install/), you can add the following to your agent configuration file:\n\n```yaml\ncontainer_scanning:\n  cadence: '0 0 * * *'  # Daily at midnight\n  vulnerability_report:\n    namespaces:\n      include:\n        - production\n        - staging\n```\n\n\nYou can also create a [scan execution policy](https://docs.gitlab.com/user/clusters/agent/vulnerabilities/#enable-via-scan-execution-policies) that enforces scanning on a schedule by the GitLab Kubernetes Agent.\n\n\n![Scan execution policy - Operational Container Scanning](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547515/gsgvjcq4sas4dfc8ciqk.png \"Scan execution policy conditions for Operational Container Scanning\")\n\n#### Viewing results\n\n* Navigate to **Operate > Kubernetes clusters**.\n\n* Select the **Agent** tab, and choose your agent.\n\n* Then select the **Security** tab to view cluster vulnerabilities.\n\n* Results also appear under the **Operational Vulnerabilities** tab in the **Vulnerability Report**.\n\n\n## Enhancing posture with GitLab Security Policies\n\nGitLab Security Policies enable you to enforce consistent security standards across your container workflows through automated, policy-driven controls. These policies shift security left by embedding requirements directly into your development pipeline, ensuring vulnerabilities are caught and addressed before code reaches production.\n\n#### Scan execution and pipeline policies\n\n[Scan execution policies](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/) automate when and how Container Scanning runs across your projects. Define policies that trigger container scans on every merge request, schedule recurring scans of your main branch, and more. These policies ensure comprehensive coverage without relying on developers to manually configure scanning in each project's CI/CD pipeline.\n\nYou can specify which scanner versions to use and configure scanning parameters centrally, maintaining consistency across your organization while adapting to new container security threats.\n\n![Scan execution policy configuration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/z36dntxslqem9udrynvx.png \"Scan execution policy configuration\")\n\n\n[Pipeline execution policies](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/) provide flexible controls for injecting (or overriding) custom jobs into a pipeline based on your compliance needs.\n\nUse these policies to automatically inject Container Scanning jobs into your pipeline, fail builds when container vulnerabilities exceed your risk tolerance, trigger additional security checks for specific branches or tags, or enforce compliance requirements for container images destined for production environments. Pipeline execution policies act as automated guardrails, ensuring your security standards are consistently applied across all container deployments without manual intervention.\n\n![Pipeline execution policy](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/ddhhugzcr2swptgodof2.png \"Pipeline execution policy actions\")\n\n#### Merge request approval policies\n\n[Merge request approval policies](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/) enforce security gates by requiring designated approvers to review and sign off on merge requests containing container vulnerabilities.\n\nConfigure policies that block merge when critical or high-severity vulnerabilities are detected, or require security team approval for any merge request introducing new container findings. These policies prevent vulnerable container images from advancing through your pipeline while maintaining development velocity for low-risk changes.\n\n![Merge request approval policy performing block in MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/hgnbc1vl4ssqafqcyuzg.png \"Merge request approval policy performing block in MR\")\n\n\n## Choosing the right approach\n\n| Scanning Type | When to Use | Key Benefit |\n|--------------|-------------|-------------|\n| Pipeline-based | Every build | Shift-left security, blocks vulnerable builds |\n| Registry scanning | Continuous monitoring | Catches new CVEs in stored images |\n| Multi-container | Microservices | Parallel scanning, faster pipelines |\n| Continuous vulnerability | Between deployments | Proactive advisory monitoring |\n| Operational | Production monitoring | Runtime vulnerability detection |\n\n\n\nFor comprehensive security, consider combining multiple approaches. Use\npipeline-based scanning to catch issues during development, container\nscanning for registry for continuous monitoring, and operational scanning\nfor production visibility.\n\n## Get started today\n\nThe fastest path to container security is enabling pipeline-based scanning:\n\n1. Navigate to your project's **Secure > Security configuration**.\n2. Click **Configure with a merge request** for Container Scanning.\n3. Merge the resulting merge request.\n4. Your next pipeline will include vulnerability scanning.\n\nFrom there, layer in additional scanning types based on your security requirements\nand GitLab tier.\n\nContainer security isn't a one-time activity, it's an ongoing process.\nWith GitLab's comprehensive container scanning capabilities, you can detect\nvulnerabilities at every stage of your container lifecycle, from build to runtime.\n\n> For more information on how GitLab can help enhance your security posture, visit the [GitLab Security and Governance Solutions Page](https://about.gitlab.com/solutions/application-security-testing/).\n",{"slug":727,"featured":13,"template":14},"complete-guide-to-gitlab-container-scanning",{"content":729,"config":741},{"title":730,"description":731,"authors":732,"heroImage":735,"date":736,"body":737,"category":10,"tags":738},"Track vulnerability remediation with the updated GitLab Security Dashboard","Quickly prioritize remediation on high-risk projects and measure progress with vulnerability insights.",[733,734],"Alisa Ho","Mike Clausen","https://res.cloudinary.com/about-gitlab-com/image/upload/v1771438388/t6sts5qw4z8561gtlxiq.png","2026-02-19","Security teams and developers face the same frustration: thousands of vulnerabilities demanding attention, without the insights to help them prioritize remediation. Where is risk concentrated and how fast is it being remediated? Where will remediation efforts have the greatest impact? The updated GitLab Security Dashboard helps answer these questions with trend tracking, vulnerability age distribution, and risk scoring by project.\n\n## Measure remediation, not just detection\nApplication security teams don’t struggle to find vulnerabilities; they struggle to make sense of them. Most dashboards show raw counts without context, forcing teams to spend countless hours chasing remediation without understanding what vulnerabilities expose them to the greatest risks.\n\n[GitLab Security Dashboard](https://docs.gitlab.com/user/application_security/security_dashboard/#new-security-dashboards) consolidates all vulnerability data into one view that spans projects, groups, and business units.\n\nIn 18.6, we introduced the first release of the updated Security Dashboard, allowing teams to view vulnerabilities over time and filter based on project or report type. As part of the [18.9 release](https://about.gitlab.com/releases/2026/02/19/gitlab-18-9-released/), customers will be able to take advantage of new filters and charts that make it easier to slice data by severity, status, scanner, or project and visualize trends such as open vulnerabilities, remediation velocity, vulnerability age distribution, and risk score over time.\n\nRisk scores help teams prioritize remediating their most critical vulnerabilities. The risk score is calculated using factors such as vulnerability age, Exploit Prediction Scoring System (EPSS), and Known Exploited Vulnerability (KEV) scores for related repositories and their security postures. With this data, application security teams can pinpoint which areas need more attention than others. \n\nGitLab Security Dashboard helps application security and development teams:\n* **Track program effectiveness**: Monitor remediation velocity, scanner adoption, and risk posture to show measurable improvement.\n* **Focus on targeted remediation**: Fix vulnerabilities that represent the greater risk to production systems.\n* **Identify areas for remediation training**: Find which teams struggle with remediating vulnerabilities in accordance with company policy to invest in additional training. \n* **Reduce manual reporting**: Eliminate the need for external dashboards and spreadsheets by tracking everything directly within GitLab.\n\nThis update reflects GitLab’s continued commitment to making security measurable, contextual, and integrated into everyday development workflows. GitLab Security Dashboard turns raw findings into actionable insights, giving security and development teams the clarity to prioritize, reduce risk faster, and prove their progress.\n\n## See Security Dashboard in action\nAn application security leader preparing for an executive briefing can now show whether investments are reducing risk with clear trendlines: open vulnerabilities decreasing, vulnerability age decreasing, once-prevalent CWE types trending downward, and a healthy risk score. Instead of presenting raw counts, they can demonstrate how the backlog is shrinking and how risk posture is improving quarter over quarter.\n\nAt the same time, developers can see the same dashboard highlighting critical vulnerabilities in their active projects, allowing them to focus remediation efforts without exporting data or juggling multiple tools.\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1166108924?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=\"Security-Dashboard-Demo-Final\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> For more details on how to get started with GitLab Security Dashboard today, check out our [documentation](https://docs.gitlab.com/user/application_security/security_dashboard/).",[10,739,740],"product","features",{"featured":31,"template":14,"slug":742},"track-vulnerability-remediation-with-the-updated-gitlab-security-dashboard",{"content":744,"config":754},{"title":745,"description":746,"heroImage":747,"body":748,"date":749,"category":10,"authors":750,"tags":752},"How to set up GitLab SAML SSO with Google Workspace","Learn how to automate user provisioning and sync permissions with Google groups with this step-by-step guide.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1759320418/xjmqcozxzt4frx0hori3.png","Single sign-on (SSO) simplifies user authentication and improves security by allowing employees to access multiple applications with one set of credentials. For organizations using both GitLab and Google Workspace, integrating SAML-based SSO streamlines access management and ensures your teams can collaborate seamlessly.\n\nIn this guide, we'll walk through configuring SAML authentication between Google Workspace and GitLab.com, including automatic group synchronization that maps Google Workspace groups to GitLab roles. By the end, your users will be able to sign in to GitLab using their Google credentials, and their permissions will automatically reflect their Google group memberships.\n\n**Note:** This guide focuses on GitLab.com (SaaS). If you're using GitLab Self-Managed, the setup process differs slightly. Refer to the [official GitLab SAML documentation for self-managed instances](https://docs.gitlab.com/integration/saml/) for detailed instructions.\n\n## What you'll need\n\nBefore getting started, make sure you have:\n- **Google Workspace** with Super Admin access\n- **GitLab.com** with a Premium or Ultimate tier subscription\n- **Owner role** on a GitLab top-level group\n- Users already existing in Google Workspace (they'll be created in GitLab automatically on first login)\n\n## Understanding the architecture\n\nWhen you configure SAML SSO with group synchronization, here's what happens:\n\n1. **Authentication flow**: Users navigate to GitLab's SSO URL and are redirected to Google Workspace to authenticate.\n2. **SAML assertion**: After successful authentication, Google sends a SAML response containing user details and group memberships.\n3. **Automatic provisioning**: GitLab creates the user account (if needed) and assigns them to groups based on their Google group memberships.\n4. **Permission sync**: Each time users sign in, GitLab updates their group memberships and roles to match their current Google groups.\n\nThis setup provides several benefits:\n\n- **Centralized access control**: You can manage user access through Google Workspace groups.\n- **Automatic provisioning**: New users gain GitLab access on their first login.\n- **Dynamic permissions**: User roles update automatically based on group membership changes.\n- **Enhanced security**: You can leverage Google's authentication security features.\n- **Reduced administrative overhead**: There is no need to manually manage GitLab group memberships.\n\n## Part 1: Get your GitLab SAML configuration values\n\nFirst, you'll need to gather some information from GitLab that you'll use when creating the SAML application in Google Workspace. Here are the steps to take:\n\n### Step 1: Navigate to your GitLab group SAML settings\n\n1. Sign in to **GitLab.com**.\n2. Navigate to your **top-level group** (Note: SAML SSO can only be configured at the top-level group, not in subgroups).\n3. In the left sidebar, select **Settings > SAML SSO**.\n\n### Step 2: Copy the required URLs\n\nOn the SAML SSO settings page, you'll see three important URLs. Copy and save these somewhere accessible — you'll need them shortly:\n\n- **Assertion consumer service URL**: This is where Google will send SAML responses.\n  - Format: `https://gitlab.com/groups/your-group/-/saml/callback`\n\n- **Identifier**: Also called the Entity ID, this uniquely identifies your GitLab group.\n  - Format: `https://gitlab.com/groups/your-group`\n\n- **GitLab SSO URL**: This is the URL your users will use to sign in.\n  - Format: `https://gitlab.com/groups/your-group/-/saml/sso`\n\n\n\u003Cfigure>\n  \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769090029/lrw6jbn7ussjze6lxg5o.png\" alt=\"GitLab SAML single sign-on settings\">\n  \u003Cfigcaption>\u003Cem>GitLab SAML single sign-on settings\u003C/em>\u003C/figcaption>\n\u003C/figure>\n## Part 2: Create your SAML application in Google Workspace\n\nNow you'll create a custom SAML application in Google Workspace that connects to your GitLab group.\n\n### Step 3: Access the Google Admin Console\n\n1. Open a new browser tab and sign in to the [Google Admin Console](https://admin.google.com/) with a Super Administrator account.\n2. Click the **Menu** icon (☰) in the top-left.\n3. Navigate to **Apps > Web and mobile apps**.\n4. Click **Add App > Add custom SAML app**.\n\u003Cp>\u003C/p>\n\u003Cfigure>\n  \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769090026/c2inhqzppdbszysupjcd.png\" alt=\"Google custom SAML app\">\n  \u003Cfigcaption>\u003Cem>Google custom SAML app\u003C/em>\u003C/figcaption>\n\u003C/figure>\n\n### Step 4: Configure the application name\n\n1. In the **App name** field, enter GitLab (or your preferred name).\n2. Optionally upload a **GitLab logo** as the app icon for easy recognition.\n3. Click **Continue**.\n\n### Step 5: Download Google identity provider details\n\nOn the **Google Identity Provider details** page, you'll need to capture two pieces of information:\n\n1. **SSO URL**: Copy this URL. It tells GitLab where to send authentication requests.\n   - Example format: `https://accounts.google.com/o/saml2/idp?idpid=C1234abcd`\n\n\n2. **Certificate**: Click the **Download** button to save the certificate file.\n   - The file will be named something like: `GoogleIDPCertificate-gitlab.pem`\n   - Save this file somewhere you can easily find it. You'll need it in the next section\n\n3. Click **Continue**.\n\n### Step 6: Configure service provider details\n\nThis is where you'll use the GitLab URLs you copied in Step 2. Enter the following:\n\n| **Field** | **Value** | **Description** |\n|-----------|-----------|-----------------|\n| **ACS URL** | Your GitLab Assertion consumer service URL | Where Google sends SAML responses |\n| **Entity ID** | Your GitLab Identifier | Unique identifier for your GitLab group |\n| **Start URL** | Leave blank | Not required for this setup |\n| **Name ID format** | Select **EMAIL** | The format for the user identifier |\n| **Name ID** | Select **Basic Information > Primary Email** | The user's primary email will be used as their identifier |\n| **Signed response** | Leave unchecked | GitLab doesn't require signed responses by default |\n\n\u003Cfigure style=\"margin: 24px 0;\">\n  \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769090028/kaui5vj14gkftbfgsbnz.png\" alt=\"GitLab SAML app details\">\n  \u003Cfigcaption>\u003Cem>GitLab SAML app details\u003C/em>\u003C/figcaption>\n\u003C/figure>\n\n\nClick **Continue** when complete.\n\n### Step 7: Configure attribute mapping\n\nAttribute mapping tells Google which user information to send to GitLab. You'll configure both basic user attributes and group membership.\n\n#### Basic attributes\n\nAdd these three attribute mappings by clicking **Add mapping** for each:\n\n| **Google Directory attribute** | **App attribute** |\n|--------------------------------|-------------------|\n| Primary email | email |\n| First name | first_name |\n| Last name | last_name |\n\n#### Group membership configuration\n\nThis is the critical configuration that enables automatic group synchronization:\n\n1. Scroll down to the **\"Group membership (optional)\"** section.\n2. Under **\"Google groups\"**, click **\"Search for a group\"**.\n3. Search for and select each Google Workspace group you want to synchronize with GitLab.\n   - You can select up to 75 groups\n   - Examples: Engineering, DevOps, Platform-Team, Security-Team\n\n4. Under **\"App attribute\"**, enter exactly: `groups`.\n5. Click **Finish**.\n\n\u003Cp>\u003C/p>\n\u003Cfigure>\n  \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769090027/ksuebt9uoe3w5cdzsjkl.png\" alt=\"GitLab SAML app attribute mapping\">\n  \u003Cfigcaption>\u003Cem>GitLab SAML app attribute mapping\u003C/em>\u003C/figcaption>\n\u003C/figure>\n\n> **Critical**: The app attribute name **MUST** be exactly `groups` (lowercase). This is what GitLab expects to receive in the SAML response. Any other value or capitalization will prevent group synchronization from working.\n\n### Step 8: Enable the application for users\n\nYour SAML app is created but not yet enabled. To make it available to users:\n\n1. In the Google Admin Console, find your **GitLab** app in the Web and mobile apps list.\n2. Click on the app to open its details.\n3. In the left sidebar, click **User access**.\n4. Select one of the following:\n   - **ON for everyone** - Enables the app for all users in your organization\n   - **ON for some organizational units** - Select specific organizational units\n\n5. Click **Save**.\n\n**Note**: Changes can take up to 24 hours to propagate, but typically take effect within a few minutes.\n\n## Part 3: Convert the certificate to SHA-1 fingerprint format\n\nGitLab requires a SHA-1 certificate fingerprint, but Google's certificate download doesn't include this format directly. You'll need to convert it.\n\n### Step 9: Convert your certificate\n\nYou have two options for converting the certificate to the required format.\n\n#### Option 1: Online conversion tool\n\nThis is a viable method if you're comfortable using a third-party tool:\n\n1. **Locate the certificate file** you downloaded in Step 5:\n   - Check your Downloads folder\n   - The file name will be something like: `GoogleIDPCertificate-gitlab.pem`\n\n2. **Open the file** in a text editor:\n   - Mac: **Right-click > Open With > TextEdit**\n   - Windows: **Right-click > Open With > Notepad**\n   - Linux: Use your preferred text editor\n\n3. **Copy ALL contents** of the file, including the header and footer:\n\n\n  ```text\n  -----BEGIN CERTIFICATE-----\n  MIIDdDCCAlygAwIBAgIGAXqD...\n  (multiple lines of encoded text)\n  ...kE7RnF6yQ==\n  -----END CERTIFICATE-----\n  ```\n\n\n4. **Navigate to**: A SHA-1 fingerprint conversion tool. [This one](https://www.samltool.com/fingerprint.php) is a good example.\n5. **Paste the certificate content** into the text box.\n6. **Select \"SHA-1\"** from the algorithm dropdown (not SHA-256!).\n7. Click **\"Calculate Fingerprint\"**.\n8. **Copy the resulting fingerprint** - it will be in the format: `XX:XX:XX:XX:XX:...`.\n\n#### Option 2: Command-line conversion\n\nIf you prefer using the command line:\n\n**For Mac, Linux, or Windows with WSL:**\n\n\n  ```bash\n  cd ~/Downloads\n  openssl x509 -noout -fingerprint -sha1 -inform pem -in \"GoogleIDPCertificate-gitlab.pem\"\n  ```\n\n\nThe output will show:\n\n\n  ```text\n  SHA1 Fingerprint=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX\n  ```\n\n\nCopy everything after `SHA1 Fingerprint=`.\n\n## Part 4: Complete your GitLab SAML configuration\n\nNow that you have the Google SSO URL and certificate fingerprint, you can complete the GitLab side of the configuration.\n\n### Step 10: Enter Google identity provider details\n\nReturn to your GitLab browser tab (**Settings > SAML SSO**) and do the following:\n\n1. **Identity provider SSO URL**:\n   - Paste the SSO URL you copied from Google in Step 5\n\n2. **Certificate fingerprint**:\n   - Paste the SHA-1 fingerprint you generated in Step 9\n   - Verify the format is correct: 59 characters with colons (XX:XX:XX:...)\n\n3. **Enable SAML authentication for this group**:\n   - Check this box to activate SAML SSO\n\n\u003Cp>\u003C/p>\n\u003Cfigure>\n  \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769090027/ncoeqrdu7aahyuflrq7b.png\" alt=\"GitLab SAML Configuration with Google SAML values\">\n  \u003Cfigcaption>\u003Cem>GitLab SAML Configuration with Google SAML values\u003C/em>\u003C/figcaption>\n\u003C/figure>\n\n### Step 11: Configure security settings (recommended)\n\nFor enhanced security, consider enabling these additional options:\n\n- **\"Enforce SAML authentication for web activity for this group\"**\n  - Requires users to authenticate via SAML to access the GitLab web interface\n\n- **\"Enforce SAML authentication for Git and Dependency Proxy activity for this group\"**\n  - Requires SAML authentication for Git operations and dependency proxy access\n\nClick **Save changes** to apply your configuration.\n\n### Step 12: Test your SAML configuration\n\nBefore proceeding with group synchronization, verify that basic SAML authentication works:\n\n1. Open an incognito or private browsing window.\n2. Navigate to your GitLab SSO URL.\n   - Format: `https://gitlab.com/groups/your-group/-/saml/sso`\n\n3. You should be redirected to the Google sign-in page.\n4. Sign in with a Google Workspace account that has access to the GitLab app.\n5. After successful authentication, you should be redirected back to GitLab.\n\n**If the test succeeds**, you can proceed to configure group synchronization.\n\n**If the test fails**, check the following:\n\n- Verify the certificate fingerprint is SHA-1 format (not SHA-256).\n- Confirm the SSO URL is correct.\n- Ensure the user has access to the GitLab SAML app in Google Admin Console.\n- Check that the ACS URL and Entity ID match exactly.\n\n## Part 5: Set up SAML group synchronization\n\nNow it's time to map your Google Workspace groups to GitLab roles so that permissions are automatically managed based on group membership.\n\n### Step 13: Configure default membership role\n\nAs a security best practice, set a minimal default role for users who log in but don't belong to any mapped groups:\n\n1. In your GitLab group, navigate to **Settings > General**.\n2. Expand the **Permissions and group features** section.\n3. Under **Default membership role**, select **Minimal Access or Guest**.\n4. Click **Save changes**.\n\n\u003Cp>\u003C/p>\n\u003Cfigure>\n  \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769097587/syi0jeaspzt9tki0w9nd.png\" alt=\"GitLab SAML Default membership setting\">\n  \u003Cfigcaption>\u003Cem>GitLab SAML Default membership setting\u003C/em>\u003C/figcaption>\n\u003C/figure>\n\n### Step 14: Create SAML group links\n\nSAML Group Links are the mappings between Google Workspace groups and GitLab roles. Here's how to create them:\n\n1. In your GitLab group, navigate to **Settings > SAML Group Links**.\n2. Click **\"Add new SAML Group Link\"**.\n\nFor each Google Workspace group you want to sync:\n\n**SAML Group Name**:\n\n- Enter the **exact name** of your Google Workspace group\n- This is **case-sensitive** and must match perfectly\n- Example: Engineering (not engineering)\n- To find the exact name: Google Admin Console > Directory > Groups\n\n**Access Level**: Select the appropriate GitLab role:\n\n- **Minimal Access** - Can see that the group exists\n- **Guest** - Can view issues and leave comments\n- **Reporter** - Can pull code, view issues, and create new issues\n- **Developer** - Can push code, create merge requests, and manage issues\n- **Maintainer** - Can manage project settings and members\n- **Owner** - Full administrative control over the group\n\n3. Click **Save**.\n4. **Repeat this process** for each Google Workspace group you want to map.\n\n**Note:** SAML group sync rules are enforced every time a user signs in. If a user's Google group membership matches a sync rule, their GitLab role will be automatically set to the configured access level, even if you've manually changed it to something different. For example, if you set up a sync rule that grants \"Maintainer\" access and then manually promote a user to \"Owner,\" they'll be automatically downgraded back to \"Maintainer\" on their next SAML sign-in.\n\n**Best practices:** To maintain custom access levels for specific users, do one of the following:\n\n - Use SAML group sync only on your top-level group and manually manage permissions in subgroups\n\n - Create separate Google groups for users who need elevated permissions\n \n - Avoid setting up sync rules that would conflict with manual role assignments\n\n\n\n\u003Cfigure>\n  \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769090028/etjoaiuyhnqh4gnjqcha.png\" alt=\"GitLab SAML Group Links setup\">\n  \u003Cfigcaption>\u003Cem>GitLab SAML Group Links setup\u003C/em>\u003C/figcaption>\n\u003C/figure>\n### Example group mapping configuration\n\nHere's a practical example of how you might structure your group mappings:\n\n| **Google Workspace Group** | **GitLab Role** | **Purpose** |\n|----------------------------|-----------------|-------------|\n| GitLab-Admins | Owner | Full administrative access |\n| Engineering-Team | Maintainer | Can manage projects and settings |\n| Developer-Team | Developer | Can write and push code |\n| QA-Team | Developer | Can test and manage issues |\n| Contractors | Reporter | Read-only access to code |\n| All-Employees | Minimal Access | Basic visibility |\n\n### Step 15: Verify your group links\n\nAfter creating all your group links:\n\n1. Review the complete list of SAML Group Links in **Settings > SAML Group Links**.\n2. Verify each **SAML Group Name** exactly matches the corresponding Google Workspace group.\n3. Verify each **Access Level** is appropriate for the intended purpose.\n4. Check for any typos or extra spaces.\n\n## Part 6: Test the complete configuration\n\nNow it's time to test the entire setup including group synchronization.\n\n### Step 16: Test with a real user\n\nChoose a test user who meets these criteria:\n\n- Has a Google Workspace account\n- Is a member of at least one Google Workspace group you configured\n- Has the GitLab SAML app enabled in Google Admin Console\n- Ideally is not you (to ensure a realistic test)\n\nTo perform the test:\n\n1. **Open an incognito or private browsing window**\n2. **Navigate to your GitLab SSO URL**:\n   - `https://gitlab.com/groups/your-group/-/saml/sso`\n\n3. **Sign in** with the test user's Google Workspace credentials\n4. The user should be:\n   - Authenticated successfully\n   - Redirected to GitLab\n   - Automatically added to the GitLab group\n   - Assigned the appropriate role based on their Google group membership\n\n### Step 17: Verify group membership and role assignment\n\nUsing your GitLab administrator account:\n\n1. Navigate to your group in GitLab.\n2. Select **Manage > Members** from the left sidebar.\n3. Find the test user in the members list.\n4. Verify the following:\n   - User appears in the members list\n   - User has the correct **Max role** based on their Google group(s)\n   - **Source** column shows a SAML indicator\n\n\u003Cp>\u003C/p>\n\u003Cfigure>\n  \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1769090026/hiov7kiukidsiyscfesg.png\" alt=\"Verified SAML user added\">\n  \u003Cfigcaption>\u003Cem>Verified SAML user added\u003C/em>\u003C/figcaption>\n\u003C/figure>\n\n## Part 7: Configure subgroup access (optional)\n\nFor larger organizations, you may want to provide more granular access control using GitLab subgroups. SAML Group Links can be configured at any level of your group hierarchy, allowing you to map different Google Workspace groups to specific teams or projects.\n\n### Understanding GitLab's subgroup structure\n\nGitLab supports nested group hierarchies that can mirror your organizational structure:\n\n  ```text\n  acme-corp/                          ← Top-level group (SAML configured here)\n  ├── engineering/                    ← Subgroup\n  │   ├── backend/                   ← Nested subgroup\n  │   └── frontend/                  ← Nested subgroup\n  ├── marketing/                      ← Subgroup\n  └── operations/                     ← Subgroup\n  ```\n\n\n### Creating subgroups\n\nIf you need to create additional subgroups:\n\n1. Navigate to your **parent group** (e.g., acme-corp).\n2. Click the **New subgroup** button.\n3. Configure the subgroup:\n   - **Subgroup name**: Display name (e.g., Engineering)\n   - **Subgroup URL**: URL slug (e.g., engineering)\n   - **Visibility level**: Choose Private, Internal, or Public\n\n4. Click **Create subgroup**.\n5. Repeat for other subgroups as needed.\n\n### Configuring SAML group links for subgroups\nHere are the steps to configure SAML group links for subgroups.\n\n#### Add new Google groups to the SAML app (if needed)\n\nIf you're introducing new Google Workspace groups for subgroup access:\n\n1. Go to **Google Admin Console > Apps > Web and mobile apps > GitLab**.\n2. Click **SAML attribute mapping**.\n3. Scroll to **\"Group membership (optional)\"**.\n4. Add your new groups (e.g., Backend-Team, Frontend-Team).\n5. Verify the **\"App attribute\"** is still `groups`.\n6. Click **Save**.\n\n#### Map Google groups to subgroups\n\n1. **Navigate to the specific subgroup** in GitLab\n   - Example: acme-corp/engineering/backend\n\n2. Go to **Settings > SAML Group Links**.\n3. Click **\"Add new SAML Group Link\"**.\n4. Configure the mapping:\n   - **SAML Group Name**: Backend-Team (exact Google Workspace group name)\n   - **Access Level**: Developer (or your desired role)\n\n5. Click **Save**.\nRepeat this process for all subgroups and their corresponding Google groups.\n\n### Multi-level access example\n\nHere's how permissions might work across different levels:\n\n#### Top-level group: acme-corp\n\nSAML Group Links:\n\n- \"Company-Admins\" → Owner\n- \"All-Employees\" → Minimal Access\n\n#### Subgroup: acme-corp/engineering\n\nSAML Group Links:\n\n- \"Engineering-Leads\" → Owner\n- \"Engineering-Team\" → Maintainer\n\n#### Nested subgroup: acme-corp/engineering/backend\n\nSAML Group Links:\n\n- \"Backend-Leads\" → Maintainer\n- \"Backend-Team\" → Developer\n\n### How permissions inherit and combine\n\nUnderstanding permission behavior is important:\n\n- **Role calculation**: At each level, users receive the **highest role** from all their Google groups.\n- **Inheritance**: Higher permissions at parent levels flow down to child subgroups.\n- **Independence**: Each level calculates permissions based on its own group links plus inherited permissions.\n- **No limitation**: Lower permissions at parent levels do NOT restrict higher permissions at child levels.\n\n**Example scenarios**:\n\n**User A** (member of Backend-Team only):\n\n- acme-corp: Minimal Access (from \"All-Employees\" default)\n- acme-corp/engineering: Minimal Access (inherited from parent)\n- acme-corp/engineering/backend: Developer (from \"Backend-Team\" mapping)\n\n**User B** (member of Engineering-Leads and Backend-Team):\n\n- acme-corp: Minimal Access (from \"All-Employees\" default)\n- acme-corp/engineering: Owner (from \"Engineering-Leads\" mapping)\n- acme-corp/engineering/backend: Owner (inherited from parent, which is higher than Developer)\n\n## How the synchronization works\n\nUnderstanding the mechanics of SAML group synchronization helps you manage the system effectively.\n\n### Synchronization timing\n\n- **When sync occurs**: Group memberships update **every time** a user signs in via SAML.\n- **Frequency**: Changes are not continuous — they only happen at login.\n- **Direction**: Synchronization is **one-way** from Google Workspace to GitLab.\n- **First login**: User account is created automatically and groups are assigned.\n- **Subsequent logins**: Existing group memberships are updated to match current Google groups.\n\n### Role priority and combination\n\nWhen a user belongs to multiple Google Workspace groups:\n\n- GitLab evaluates **all** the user's groups at each level of the hierarchy.\n- The user receives the **highest role** from any of their groups.\n- This calculation happens independently at each level (top-level group, subgroups, etc.).\n\n**Example**:\n\n- User in \"Developers\" (Developer role) + \"Tech-Leads\" (Maintainer role) → Gets **Maintainer**\n\n### Automatic role changes\n\nThe system automatically handles membership changes:\n\n- **User added to a Google group**: Role upgraded on next login.\n- **User removed from a Google group**: Role recalculated based on remaining groups on next login.\n- **User removed from all mapped groups**: Reverts to default membership role on next login.\n- **User added to additional groups**: Gets highest role from all groups on next login.\n\n### Propagation timing\n\nBe aware of these timing considerations:\n\n- **Google Workspace changes**: Can take up to 24 hours to propagate, though usually take only a few minutes.\n- **GitLab sync**: Happens immediately when the user logs in after Google changes are live.\n- **Testing**: Have users log out and log back in to test permission changes.\n\n## Understanding user lifecycle and edge cases\n\n### What happens when you remove a user from GitLab?\n\n**Removing permissions only:** If you remove a user from GitLab projects but leave their account active and they're still in the authorized Google groups:\n\n- They keep their same account (same user ID and username)\n- When they log in via SAML, their group memberships are automatically restored\n- They regain permissions based on their current Google group memberships\n\n**Blocking the account:**\n\n- Account exists but is locked\n- User cannot log in even if in Google groups\n- Can be unblocked later, preserving all history\n\n**Deleting the account:**\n\n- Account is permanently removed\n- If user logs in again (while still in Google groups), GitLab creates a **completely new account**\n- New account has different user ID with no connection to the old one\n\n### Proper offboarding process\n\nTo permanently revoke access, follow this order:\n\n1. **Remove from Google Workspace groups** - Prevents authentication\n2. **Block in GitLab** - Prevents account recreation and preserves audit trails\n3. **Delete account (optional)** - Only if you're certain they won't return\n\n> **Critical**: Removing a user only from GitLab without removing them from Google groups means they can simply log back in and regain access.\n\n### Google group membership propagation\n\nAccording to [Google's documentation](https://support.google.com/a/answer/11143403), group membership changes can take up to 24 hours to propagate, though typically occur within minutes.\n\n### Account recreation scenarios\n\n| **Scenario** | **User still in Google groups?** | **What happens on login** |\n|--------------|----------------------------------|---------------------------|\n| Permissions removed | Yes | Same account, group memberships restored |\n| Account blocked | Yes | Login fails |\n| Account deleted | Yes | New account created with new user ID |\n| Removed from Google groups | No | Login fails at Google |\n\n## Troubleshooting common issues\n\nEven with careful configuration, you might encounter issues. Here are solutions to the most common problems.\n\n### Users not being added to groups\n\n**Symptom**: User successfully logs in via SAML but doesn't appear in any GitLab groups, or appears with only the default role.\n\n**Possible causes and solutions**:\n\n1. **Group names don't match exactly**\n   - Check spelling and capitalization in both Google Workspace and GitLab\n   - Look for extra spaces before or after group names\n   - Verify the exact name in Google Admin Console > Directory > Groups\n\n2. **User not actually in the Google group**\n   - Verify membership: Google Admin Console > Directory > Groups > [Group] > Members\n   - Remember that nested group membership might not be included\n\n3. **Groups not configured in SAML app**\n   - Verify the groups are selected in Google SAML attribute mapping\n   - Confirm \"App attribute\" is set to `groups` (lowercase)\n   - Use \"Test SAML Login\" to inspect the SAML response\n\n4. **Timing or cache issue**\n   - Wait 24 hours for Google changes to fully propagate\n   - Have the user log out of GitLab and Google completely\n   - Clear browser cache and try again\n   - User must log in via the SAML SSO URL, not regular GitLab login\n\n### User has incorrect role\n\n**Symptom**: User has access but with the wrong permission level.\n\n**Possible causes and solutions**:\n\n1. **User belongs to multiple groups**\n   - Remember: Users get the **highest** role from all their groups\n   - Check all Google groups the user belongs to\n   - Review all SAML Group Link configurations at all levels\n\n2. **SAML Group Link misconfigured**\n   - Verify the Access Level setting in Settings > SAML Group Links\n   - Check for duplicate group mappings that might conflict\n\n3. **User hasn't logged in since changes**\n   - Roles only update when users log in via SAML\n   - Have the user log out completely and log back in via the SSO URL\n\n4. **Inherited permissions from parent groups**\n   - Check SAML Group Links in parent groups\n   - Remember that higher roles at parent levels flow down to children\n\n### SAML authentication fails completely\n\n**Symptom**: Users cannot log in at all, or receive error messages during authentication.\n\n**Possible causes and solutions**:\n\n1. **Incorrect certificate fingerprint**\n   - Verify you used SHA-1 format, not SHA-256\n   - Check the fingerprint has the correct format with colons\n   - Regenerate using the online tool or OpenSSL command\n\n2. **Wrong SSO URL**\n   - Double-check the SSO URL copied from Google\n   - Ensure there are no extra spaces or characters\n\n3. **ACS URL or Entity ID mismatch**\n   - Verify the ACS URL in Google Admin Console matches GitLab exactly\n   - Confirm the Entity ID matches between both systems\n\n4. **User doesn't have app access**\n   - Check User Access settings in Google Admin Console\n   - Verify the user's organizational unit has the app enabled\n   - Confirm the app is \"ON\" for the appropriate users\n\n5. **Certificate expired**\n   - Check certificate validity dates\n   - Download a fresh certificate if needed\n\n### Groups attribute missing from SAML response\n\n**Symptom**: Users can log in but group synchronization doesn't work at all.\n\n**Possible causes and solutions**:\n\n1. **Groups not selected in Google configuration**\n   - Return to **Google Admin > Apps > GitLab > Attribute** mapping\n   - Verify groups are selected under \"Group membership\"\n   - Confirm \"App attribute\" is exactly `groups` (lowercase)\n\n2. **User not in any configured groups**\n   - Only groups the user belongs to are sent in the SAML response\n   - Add the user to at least one selected group to test\n\n3. **Configuration hasn't propagated**\n   - Wait up to 24 hours for changes to take effect\n   - Try logging out of Google Admin Console and back in\n\n4. **Typo in app attribute name**\n   - The attribute name must be exactly `groups` (lowercase)\n   - Even a capital letter or extra space will break functionality\n\n## Best practices for managing SAML group sync\n\nFollow these recommendations to maintain a secure and efficient setup.\n\n### Security best practices\n\n1. **Maintain emergency access**\n   - Keep at least one Owner account that uses password authentication (not SAML)\n   - This provides emergency access if SAML configuration breaks\n   - Store these credentials securely\n\n2. **Use least privilege principle**\n   - Set default membership to Minimal Access\n   - Only grant higher permissions through explicit group mappings\n   - Regularly review and audit group memberships\n\n3. **Enable enforcement options**\n   - Turn on \"Enforce SAML authentication\" options\n   - This prevents users from bypassing SSO\n   - Exceptions should be rare and well-documented\n\n4. **Regular security audits**\n   - Quarterly review of Google Workspace group memberships\n   - Annual review of SAML Group Link mappings\n   - Monitor GitLab audit logs for unusual access patterns\n\n## Summary and next steps\n\nCongratulations! You've successfully configured SAML SSO and automatic group synchronization between Google Workspace and GitLab. Your setup now provides:\n\n- **Seamless authentication** - Users sign in with their familiar Google Workspace credentials.\n- **Automatic provisioning** - User accounts are created on first login without manual intervention.\n- **Dynamic permissions** - Group memberships and roles update automatically based on Google Workspace groups.\n- **Centralized access control** - Manage all access through your existing Google Workspace groups.\n- **Enhanced security** - Leverage Google's authentication infrastructure and enforce consistent policies.\n- **Reduced administrative overhead** - Eliminate manual user and permission management in GitLab.\n\n### What happens now\n\nWhen users access GitLab:\n\n1. They navigate to your GitLab SSO URL.\n2. Authenticate using their Google Workspace credentials.\n3. Get automatically added to appropriate GitLab groups.\n4. Receive permissions based on their Google group memberships.\n5. Their permissions update every time they sign in.\n\n### Additional resources\n\n- [GitLab SAML SSO Documentation](https://docs.gitlab.com/ee/user/group/saml_sso/)\n- [GitLab SAML Group Sync Documentation](https://docs.gitlab.com/ee/user/group/saml_sso/group_sync.html)\n- [Google Workspace SAML App Setup](https://support.google.com/a/answer/6087519)\n- [SAML Certificate Fingerprint Tool](https://www.samltool.com/fingerprint.php)\n\n## Related article\n* [How-to: GitLab Single Sign-on with SAML, SCIM, and Azure's Entra ID](https://about.gitlab.com/blog/how-to-gitlab-single-sign-on-with-saml-scim-and-azures-entra-id/)","2026-01-27",[751],"Omid Khan",[10,25,739,753],"google",{"featured":13,"template":14,"slug":755},"how-to-set-up-gitlab-saml-sso-with-google-workspace",{"promotions":757},[758,772,783],{"id":759,"categories":760,"header":762,"text":763,"button":764,"image":769},"ai-modernization",[761],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":765,"config":766},"Get your AI maturity score",{"href":767,"dataGaName":768,"dataGaLocation":242},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":770},{"src":771},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":773,"categories":774,"header":775,"text":763,"button":776,"image":780},"devops-modernization",[739,557],"Are you just managing tools or shipping innovation?",{"text":777,"config":778},"Get your DevOps maturity score",{"href":779,"dataGaName":768,"dataGaLocation":242},"/assessments/devops-modernization-assessment/",{"config":781},{"src":782},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":784,"categories":785,"header":786,"text":763,"button":787,"image":791},"security-modernization",[10],"Are you trading speed for security?",{"text":788,"config":789},"Get your security maturity score",{"href":790,"dataGaName":768,"dataGaLocation":242},"/assessments/security-modernization-assessment/",{"config":792},{"src":793},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":795,"blurb":796,"button":797,"secondaryButton":802},"Start building faster today","See what your team can do with the intelligent orchestration platform for DevSecOps.\n",{"text":798,"config":799},"Get your free trial",{"href":800,"dataGaName":50,"dataGaLocation":801},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":494,"config":803},{"href":54,"dataGaName":55,"dataGaLocation":801},1773350812770]