[{"data":1,"prerenderedAt":729},["ShallowReactive",2],{"/en-us/blog/how-to-choose-the-right-security-scanning-approach/":3,"navigation-en-us":37,"banner-en-us":464,"footer-en-us":481,"Matt Genelin-Mathias Ewald":691,"next-steps-en-us":714},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":16,"config":26,"_id":30,"_type":31,"title":32,"_source":33,"_file":34,"_stem":35,"_extension":36},"/en-us/blog/how-to-choose-the-right-security-scanning-approach","blog",false,"",{"title":9,"description":10,"ogTitle":9,"ogDescription":10,"noIndex":6,"ogImage":11,"ogUrl":12,"ogSiteName":13,"ogType":14,"canonicalUrls":12,"schema":15},"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.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097969/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_282096522_securitycompliance.jpeg_1750097968823.jpg","https://about.gitlab.com/blog/how-to-choose-the-right-security-scanning-approach","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to choose the right security scanning approach\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matt Genelin\"},{\"@type\":\"Person\",\"name\":\"Mathias Ewald\"}],\n        \"datePublished\": \"2024-08-26\",\n      }",{"title":9,"description":10,"authors":17,"heroImage":11,"date":20,"body":21,"category":22,"tags":23},[18,19],"Matt Genelin","Mathias Ewald","2024-08-26","Integrating security scans into your CI/CD pipeline is crucial for\nmaintaining robust and secure applications. But who's responsible for those\nscans? Who is responsible for adding them into every CI/CD pipeline for all\nprojects? And who decides which identified vulnerability may pass or needs\nfixing? For organizations in regulated industries, these are critical\nquestions.\n\n\nIn this article, you'll learn how GitLab\n[CI/CD](https://about.gitlab.com/topics/ci-cd/) enables each person in the\nsoftware development lifecycle to incorporate security scanning. You'll also\ndiscover the advantages and disadvantages of the various options available\nto add scanning to GitLab project pipelines. Code examples will help you\nkickstart security scanning on the GitLab DevSecOps platform.\n\n\nArticle contents:\n\n- [The basics of setting up security\nscanning](#the-basics-of-setting-up-security-scanning)\n\n- [Pipeline includes](#pipeline-includes)\n\n- [Compliance frameworks](#compliance-frameworks)\n\n- [Policies](#policies)\n\n- [Get started with security scanning](#get-started-with-security-scanning)\n\n\n## The basics of setting up security scanning\n\n\nGitLab uses [fictional\npersonas](https://handbook.gitlab.com/handbook/product/personas/#user-personas)\nto describe the individual team member who would typically use a given\nsecurity feature or approach. By exploring the perspective of a **Software\nDeveloper (Sasha)**, **Application Security Engineer (Amy)**, or **Platform\nEngineer (Priyanka)**, you can better understand the needs of each role on\nyour team.\n\n\nGitLab follows a \"pipeline-per-project\" principle, stored in the file named\n`.gitlab-ci.yml`. This file contains the project's CI/CD pipeline definition\nand is revision controlled like any other file in the project. You'll learn\nabout these project pipelines, as well as compliance pipelines and policy\npipelines. While compliance pipelines and policy pipelines also refer to the\nYAML files in GitLab projects, they typically have a different file name and\nserve a different purpose.\n\n\nReaders already familiar with security scanning in GitLab will find clarity\nin the security pipeline choices available in the context of your\nteam/organization. Therefore, we will discuss each of the approaches with\nrespect to the following criteria:\n\n\n- **Ease of use:** How easy is it to add security scanning to project\npipelines? Is it a reasonable task for Sasha, or something that Amy and\nPriyanka should handle?\n\n\n- **Customization:** How deeply can scanner configurations be customized\nusing that approach? While default configurations that make sense and cover\na wide range of customer needs are worth gold, the time often comes when\nscanner configurations need adjustments.\n\n\n- **Enforcement:** Is this approach suitable to companies operating in\nregulated industries or that otherwise have global policies in place? Can we\nensure each relevant project runs Scanner X with Configuration Y?\n\n\n## Pipeline includes\n\n\n[GitLab project pipeline\nincludes](https://docs.gitlab.com/ee/ci/yaml/includes.html) are a mechanism\nthat allows the integration of external pipelines into the `.gitlab-ci.yaml`\nproject pipeline. This is similar to including a library in many programming\nlanguages. This powerful feature enables the seamless incorporation of your\nown templates, as well as GitLab-provided templates, to be used as building\nblocks for your pipelines. Includes can be used in project pipelines or\nother pipeline files. An example of a commonly included external pipeline is\nincluding a security scanning pipeline into a GitLab project pipeline.\n\n\nHere are the common types of includes, which use the security scanner\nexample.\n\n\n### Templates\n\n\nGitLab offers ready-to-use\n[templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Jobs)\nthat can be included in a project pipeline to make it easier for teams to\nadd in various pre-built elements. The following is example code:\n\n\n```yaml\n\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\nDetection](https://docs.gitlab.com/ee/user/application_security/secret_detection/),\n[Static Application Security\nTesting](https://docs.gitlab.com/ee/user/application_security/sast/),\n[Dependency\nScanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/),\nand [Container\nScanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\n– all in only five lines of code. \n\n\nTo modify the behavior of jobs included via templates, you can either use\nvariables or use [GitLab's property merging\ncapabilities](https://docs.gitlab.com/ee/ci/yaml/includes.html#merge-method-for-include).\n\n\nYou will find an example of modifying the GitLab Container Scanning pipeline\nusing variables below. The [template for Container\nScanning](https://gitlab.com/gitlab-org/gitlab/-/blob/59f08760feaab1eb0489f694d4f28408af9c2e8d/lib/gitlab/ci/templates/Jobs/Container-Scanning.gitlab-ci.yml)\nneeds to know the location of the image and uses a variable named `CS_IMAGE`\nfor that as is documented in the template code linked above.\n\n\n```yaml\n\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\ndefining the `CS_IMAGE` variable before the included pipeline template. The\nContainer Scanning template inherits the `CS_IMAGE` variable value. \n\n\nIf we wanted to make changes to the [`allow_failure` property defined\nhere](https://gitlab.com/gitlab-org/gitlab/-/blob/59f08760feaab1eb0489f694d4f28408af9c2e8d/lib/gitlab/ci/templates/Jobs/Container-Scanning.gitlab-ci.yml#L38),\nwe would need to resort to property merging since the job templates employ\nno variable for the value. (The `allow_failure` property is a property\ngenerally available on every GitLab pipeline job. Please check the\n[documentation](https://docs.gitlab.com/ee/ci/yaml/#allow_failure) for\ndetails.)\n\n\nIn this example, `allow_failure` is set to `false`, meaning the entire\npipeline stops on a container scanning failure. This stops any unscanned\ncontainers from moving forward in the pipeline.\n\n\n```yaml\n\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\n\ncontainer_scanning:\n  allow_failure: false\n```\n\n\nGitLab will load the job template and – as defined in the template code –\nregister a job called `container_scanning`. As the pipeline definition\ndeclares another job with that name, GitLab will merge that specification\nwith the already registered job.\n\n\nWhile this feature offers many possibilities, it also makes it impossible to\nprotect certain properties from being overwritten. We are only at the point\nof modifying the project pipeline, so there's no control over that anyway.\nBut later on, you will see that this can pose a challenge when security\nneeds to be enforced on a project.\n\n\n### Components\n\n\nTemplates are a great start for sharing repeatable GitLab pipelines. To\nfurther abstract reusable code across an entire organization or a GitLab\ninstance, [GitLab introduced\ncomponents](https://docs.gitlab.com/ee/ci/components/). Components are the\nnext logical step in GitLab's evolution of pipelines. Components are\ndesigned to simplify the creation and use of functional building blocks to\nuse in pipelines, or even to package and ship entire pipelines if needed.\nThey offer a well-defined interface, which accepts \"inputs\" for\nconfiguration. Otherwise, the component is completely isolated, which makes\nthem a great candidate to share work within an organization and to be\nsearchable and reusable building blocks.\n\n\nDevelopers can use the [CI/CD Catalog](https://gitlab.com/explore/catalog)\nto browse and search the collection of publicly available GitLab components,\nwhich are components officially built and maintained by GitLab. GitLab uses\nthe CI/CD Catalog [to publish our shipped\ncomponents](https://gitlab.com/components) such as security scanners\nalongside community-provided components.\n\n\nComponents are consumed similarly to templates via the `include` keyword. In\nan example above, we showed how the container scanning job requires\nknowledge of the image location. This \"input\" uses the component for\n[container\nscanning](https://gitlab.com/components/container-scanning/-/blob/19fd5b83bc631cb9890b4fadb08d31b3150853ce/templates/container-scanning.yml)\nis called `cs_image`. The configuration equivalent to the previous example\nlooks like this:\n\n\n```yaml\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    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\nDependency Scanning component at Version 0.2.0, the Secret Detection\ncomponent at Version 1.1.2, and the Container Scanning component at Version\n4.1.0. `~latest` [and more tags are\navailable](https://docs.gitlab.com/ee/ci/components/#component-versions) for\nbleeding-edge component usage and other development needs.\n\n\nWhether you use templates or components, your pipeline might look like the\nimage below. The top four jobs in the test stage are the result of the four\ninclude statements in the code above.\n\n\n![An example\npipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097984/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097983863.png)\n\n\n### Advantages and disadvantages of using pipeline includes\n\n\n#### Ease of use\n\n\nOne of the benefits of using pipeline includes in GitLab is their ease of\nuse. We have seen how, with essentially six lines of code, we included four\ncommonly used security scanners. All the complex logic and setup are handled\nwithin the templates or components, saving Sacha time and effort by\nproviding a ready-to-use solution.\n\n\n#### Customization\n\n\nWhile templates offer the highest flexibility (variables and merging), it's\nimportant to remember that with \"great power comes great responsibility.\"\nThe flexibility of templates supports extensive customization, but requires\ncareful management and oversight to avoid unexpected results.\n\n\nIn contrast, components provide a more structured mechanism for authoring,\nsharing, and maintaining building blocks for a broader audience. Components,\nwhile not as customizable, enhance stability and reliability, and are a\nvaluable, reusable, and repeatable feature. \n\n\n#### Enforcement\n\n\nAs the name _include_ suggests, it is the GitLab project pipeline that needs\nto include templates or components. While scanner templates are\nstraightforward to use, Amy and Priyanka cannot be sure Sacha has included\nthem properly, or even at all. Enforcement of scanner usage is needed.\n\n\nFor regulated industries, managing security in project pipelines is not an\napproach that provides the necessary audit trail or enforcement.\n\n\n## Compliance frameworks\n\n\nGitLab identified the gap between the ability to enforce security scans on\nproject pipelines and the need to [adhere to regulatory compliance\nframeworks](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)\nsuch as PCI DSS, NIST, and many more. The introduction of compliance\nframeworks as functionality caters to precisely this challenge.\n\n\nAt first glance, a compliance framework in GitLab is merely a label attached\nto a project, which would typically be named after the regulatory framework\nit is supposed to implement. The magic is added with the link between that\nlabel and a compliance pipeline YAML file, which is responsible for\nimplementing the necessary steps to ensure compliance. \n\n\nThe mechanism is straightforward: Every time the project pipeline is\ntriggered, GitLab executes the compliance pipeline instead. The compliance\npipeline runs with both the [CI/CD\nvariables](https://docs.gitlab.com/ee/ci/variables/) and [predefined CI/CD\nvariables](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)\nof the project pipeline.\n\n\nThis allows for two main design patterns: a \"wrapping pipeline,\" where the\ncompliance pipeline includes the project pipeline, and an \"overriding\npipeline,\" where it does not. \n\n\n**Note:** Compliance pipelines have been deprecated in GitLab Version 17.3\nand are scheduled for removal in Version 19.0. At this point, we cannot\nrecommend implementing this approach for new development platforms. However,\nyou might already be using them, making it worth reading this section.\n\n\n### Wrapping pipelines\n\n\nIn the wrapping approach, the compliance pipeline defines its own jobs\naccording to specific compliance needs. It includes the project pipeline in\nthe same way we have seen templates included in the previous section. This\nsetup is possible because the predefined CI/CD variables originate from the\nproject pipeline, allowing the system to identify the pipeline definition's\nlocation for inclusion.\n\n\nHere is an example of what a simple compliance pipeline might look like. \n\n\n```yaml\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  - 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\nvariables.\n\n\n### Overriding pipelines\n\n\nUnlike wrapping pipelines, which include the project pipeline, overriding\npipelines ignore it entirely and run only their own jobs. This type of\npipeline defines each step, encompassing all necessary jobs to build, test,\nand deploy the application.\n\n\nBelow we see a mock compliance pipeline that illustrates this approach.\n\n\n```yaml\n\nstages: [\"build\", \"test\", \"deploy\"]\n\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\n#### Ease of use\n\n\nWhile compliance frameworks aren't terribly complicated, they aren't as\nstraightforward and simple as pipeline includes. They're meant to be written\nand assigned to projects by Amy and Priyanka, who now need to interact with\npipeline YAML code. A framework needs to be declared in the top-level\nnamespace and compliance pipelines need to be created and maintained, and\ncompliance frameworks need to be attached to the right projects. \n\n\n#### Customization\n\n\nAmy and Priyanka are the authors of compliance pipelines. Like Sacha in the\nprevious section on includes, they have full control over what they include\nand how they include it, giving them maximum customizability of compliance\njobs such as security scanners.\n\n\n#### Enforcement\n\nThis aspect of enforcing pipelines questions whether developers can tamper\nwith security jobs? In an environment with a strong separation of duties,\nthis nuance requires some extra attention. To answer this, we need to look\nat each pattern separately:\n\n\n##### Wrapping pipelines\n\nAs seen before, project pipelines are included in compliance pipelines. In\naddition to group- or project-level CI/CD variables, every element of that\nproject pipeline must be considered a potential threat to the compliance\npipeline. Obviously, variables and jobs stick out as primary candidates.\nAnd, in fact, they can and will influence security job behavior if used\nmaliciously.\n\n\nHere is a simple example to illustrate the issue.\n\n\nCompliance pipeline:\n\n```yaml\n\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\n```yaml\n\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\ncould be done via project or croup-level CI/CD variables, too), which is\nevaluated in the included secret detection template. Further, the last three\nlines use the merging mechanism discussed previously, to not execute the job\nat all. Kind of redundant, we know.\n\n\nBoth overrides could be prevented using components, but you get the idea.\nComponents, too, are receptive to such attacks via their inputs' default\nvalues, which often use variables, too! Let's take a look at how this could\nbe taken advantage of.\n\n\nCompliance pipeline:\n\n```yaml\n\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\n```yaml\n\nvariables:\n  CI_TEMPLATE_REGISTRY_HOST: \"docker.io\"\n```\n\n\nTo understand what is happening here, look at the [SAST scanner component's\nLine\n6](https://gitlab.com/components/sast/-/blob/main/templates/sast.yml?ref_type=heads#L6):\n\n\n```yaml\n\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\ndefault value. By setting this variable to a false value in the same way we\nset `SECRET_DETECTION_DISABLED` to `true` before, Sacha may cause the job to\nload a wrong image and break SAST testing.\n\n\nTo prevent this override ability by the developer role, avoid templates in\nfavor of components. This approach covers many developer-induced loopholes.\nTo be certain of compliance, hardcode values for component inputs.\n\n\n##### Overriding pipelines\n\n\nThis type is an entirely different beast. Developers get no chance of\ninjecting actual pipeline code into the compliance pipeline. However,\ncompliance pipelines do run with the project's CI/CD variables. Hence, any\nvariable specified on the group- or project-level might modify the\ncompliance pipeline's behavior. With `SECRET_DETECTION_DISABLED` set to\n`true` in the project CI/CD variables, the following compliance pipeline can\nbe modified again:\n\n\n```yaml\n\nstages: [\"build\", \"test\", \"deploy\"]\n\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n\nbuild-job: ...\n\ntest-job: ...\n\ndeploy-job: ...\n\n```\n\n\nComponents can solve this particular problem, but, as before, component\ninputs may use CI/CD variables developers can set. Compliance pipeline\nauthors need to identify and take care of these situations. \n\n\n## Policies\n\n\nCompliance pipelines' shortcomings have led to the next step for managing\ncompliance:\n[policies](https://docs.gitlab.com/ee/user/application_security/policies/).\n\n\nGitLab introduced\n[policies](https://docs.gitlab.com/ee/user/application_security/policies/)\nas the way forward. Authors store a set of policies in a separate project as\nYAML files and apply them to projects on the group or project level. This\ngives Amy and Priyanka the flexibility to target individual projects with\nspecific requirements but also to ensure compliance across the entire\norganization if needed. Access to the policy project can be controlled\nwithin the policy project and audited within GitLab.\n\n\nPolicies come in different types for different purposes. The types we are\ninterested in right now are scan execution policies (SEP) and pipeline\nexecution policies (PEP).\n\n\n### Scan execution policies\n\n\nAs the name suggests, SEPs require a particular scan – or set of scans – to\nbe executed as part of the project pipeline and inject the respective scan\njobs into the pipelines of associated projects. They include the respective\n[template](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Jobs)\nin the pipeline according to variables and rules set by Amy and Priyanka.\n\n\nGitLab supports policy authors with a comprehensive user interface in\naddition to a YAML-based Git workflow. The following screenshot and code\nsnippet illustrate a very basic example of a SEP:\n\n\n![Scan execution policy\nexample](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097984/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097983864.png)\n\n\n```yaml\n\nname: Secret Scanner\n\ndescription: ''\n\nenabled: true\n\nactions:\n\n- scan: secret_detection\n\nrules:\n\n- type: pipeline\n  branches:\n  - \"*\"\n```\n\n\nFor more details on SEP settings in the UI and YAML, please refer to the\n[policy\ndocumentation](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html).\n\n\n#### Advantages and disadvantages of scan execution policies\n\n\n##### Ease of use\n\nSEPs provide a lightweight, easy-to-use mechanism that enforces security on\nexisting and new CI/CD pipelines across the organization or on a granular\nlevel. The UI support makes them a viable tool for all relevant personas.\n\n\n##### Customization\n\nSEPs are restricted to predefined scanner jobs, and there is no option to\nextend this list with custom jobs at this point. This limitation can be\nrestrictive for teams with unique scanning requirements that fall outside\nthe standard options.\n\n\n##### Enforcement\n\n\nOnce an SEP is applied to a project (directly or indirectly), Sacha has no\nway to get rid of that scan job. Though, there may be ways to –\nintentionally or not – manipulate the scan job's behavior.\n\n\nJobs injected via SEPs generally are receptive to CI/CD variables and adhere\nto the general rules of [variable\nprecedence](https://docs.gitlab.com/ee/ci/variables/index.html#cicd-variable-precedence).\nFor this injection, Policies incorporate logic that denies changing some\npredefined variables as described\n[here](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html#cicd-variables)\nand generally deny the configuration of variables that follow certain\npatterns such as `_DISABLED` or  `_EXCLUDED_PATHS`.\n\n\nDespite these security measures, inconsiderate use of policies may still\nopen opportunities for tampering: In my test, I was able to set a\nproject-level CI/CD variable `SECURE_ANALYZERS_PREFIX` to a bad value (a\nnon-existing location) and as you can see\n[here](https://gitlab.com/gitlab-org/gitlab/-/blob/a2d4b8df0095c1363a105a1fa212daf227eca063/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml),\nthe secret detection template uses that to build the location of the scanner\nimage.\n\n\nWhile the scan job does get included in the pipeline run, it crashes very\nearly and, therefore, provides no scan results. Due to the [`allow_failure:\ntrue`\nconfiguration](https://gitlab.com/gitlab-org/gitlab/-/blob/a2d4b8df0095c1363a105a1fa212daf227eca063/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml#L18),\nthe pipeline will continue to run and eventually execute a deploy job.\n\n\nBecause SEP variables take the highest variable precedence, there is an easy\nfix to reduce the attack surface of the policy: Simply hardcode the correct\nvalue in your policy YAML or via the UI:\n\n\n```yaml\n\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\n\nSEPs enable the injection of a set of security-related jobs into any project\npipeline. In contrast, PEPs apply entire pipeline configurations to\nprojects, offering a lot more flexibility when it comes to customizing\nsecurity constraints. \n\n\nThere are two methods for implementing these policies, known as \"actions\":\n`inject` and `override`. These actions function similarly to the patterns we\nhave seen in the compliance frameworks section and provide flexible ways to\nenhance and enforce security standards within the development workflow.\n\n\n#### Injecting pipelines\n\n\nInjecting pipelines involves adding the jobs and other elements defined in\nthe policy pipeline into the project pipeline. Currently, jobs should only\nbe injected into reserved stages, namely `.pipeline-policy-pre` and\n`.pipeline-policy-post` to avoid unpredictable results.\n\n\nGitLab handles name clashes between jobs or variables in policy and project\npipelines effectively by building each pipeline in isolation before\ncombining them. This ensures that the integration process is seamless and\ndoes not disrupt existing workflows or configurations.\n\n\n![security scanning - image\n4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097984/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097983865.png)\n\n\nThe above screenshot shows an example of an injected policy pipeline.\nProject pipeline jobs are prefixed with `prj-` for easier identification.\n\n\n#### Overriding pipelines\n\n\nIn the override approach, the project pipeline is completely replaced by the\npolicy pipeline. This method is similar to compliance pipelines that do not\ninclude the project's `.gitlab-ci.yml` file. Despite the override, the\npipelines run using the project's CI/CD variables, maintaining consistency\nwith project-specific configurations. The compliance pipeline we used\nearlier makes a perfectly fine policy pipeline, too:\n\n\n```yaml\n\nstages: [\"build\", \"test\", \"deploy\"]\n\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\npipeline above:\n\n\n![More complete\npipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097984/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097983866.png)\n\n\n**Note:** This doesn't currently work with SEPs.\n\n\nHowever, the existence of a Dockerfile may not always be a valid indicator,\nas developers might be building without Dockerfiles using Cloud Native\nBuildpacks, Heroku Buildpacks, Kaniko, or other tools. Managed pipelines do\nnot encounter this challenge, as they are more controlled and centralized.\n\n\n\u003C!-- TOC ignore:true -->\n\n### Projects with multiple container images\n\nFor projects that produce multiple container images, several container\nscanning jobs would be necessary for proper coverage. This raises similar\nquestions as before: \"How do we know there are multiple?\" and \"Is the source\nof that information trustworthy?\". If we wanted to rely on the existence of\n`Dockerfile`s a [dynamic\napproach](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html#dynamic-child-pipelines)\nwould be necessary that includes a container scanning job for each\n`Dockerfile` detected.\n\n\n## Get started with security scanning\n\nIn this article, you've learned about a variety of approaches to adding\nsecurity scanning to CI/CD pipelines with a close look at ease of use,\ncustomizability, and the ability to strictly enforce scanning. You've seen\nthat a pipeline author who is held responsible for project compliance needs\nto keep a few things in mind during the process to avoid surprises down the\nline. We recommend building a small testing space on your GitLab instance\nand then run a few tests to reproduce the main points of this article. Put\nyourself in the shoes of a malicious Sacha (Sachas aren't generally\nmalicious people, but it's a good exercise) and think about how you could\nfool that annoying Amy and her security scans.\n\n\nGitLab provides strong support for all sorts of requirements and all\napproaches are – at least in our eyes – easy to implement due the platform's\nbaked-in functionality. You should find ways to bulletproof your scan jobs\nand, if not, you should open a ticket with our support. \n\n\nHappy pipelining!\n\n\n> #### Get started with security scanning today!\n\n> [Sign up for a free trial of GitLab\nUltimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial)\nto implement security scanning in your software development lifecycle.\n\n\n## Read more\n\n\n- [Meet regulatory standards with GitLab security and\ncompliance](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/)\n\n- [How to integrate custom security scanners into\nGitLab](https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab/)\n\n- [Integrate external security scanners into your DevSecOps\nworkflow](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/)\n","security",[22,24,25],"tutorial","CI/CD",{"slug":27,"featured":28,"template":29},"how-to-choose-the-right-security-scanning-approach",true,"BlogPost","content:en-us:blog:how-to-choose-the-right-security-scanning-approach.yml","yaml","How To Choose The Right Security Scanning Approach","content","en-us/blog/how-to-choose-the-right-security-scanning-approach.yml","en-us/blog/how-to-choose-the-right-security-scanning-approach","yml",{"_path":38,"_dir":39,"_draft":6,"_partial":6,"_locale":7,"data":40,"_id":460,"_type":31,"title":461,"_source":33,"_file":462,"_stem":463,"_extension":36},"/shared/en-us/main-navigation","en-us",{"logo":41,"freeTrial":46,"sales":51,"login":56,"items":61,"search":391,"minimal":422,"duo":441,"pricingDeployment":450},{"config":42},{"href":43,"dataGaName":44,"dataGaLocation":45},"/","gitlab logo","header",{"text":47,"config":48},"Get free trial",{"href":49,"dataGaName":50,"dataGaLocation":45},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":52,"config":53},"Talk to sales",{"href":54,"dataGaName":55,"dataGaLocation":45},"/sales/","sales",{"text":57,"config":58},"Sign in",{"href":59,"dataGaName":60,"dataGaLocation":45},"https://gitlab.com/users/sign_in/","sign in",[62,106,202,207,312,372],{"text":63,"config":64,"cards":66,"footer":89},"Platform",{"dataNavLevelOne":65},"platform",[67,73,81],{"title":63,"description":68,"link":69},"The most comprehensive AI-powered DevSecOps Platform",{"text":70,"config":71},"Explore our Platform",{"href":72,"dataGaName":65,"dataGaLocation":45},"/platform/",{"title":74,"description":75,"link":76},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":77,"config":78},"Meet GitLab Duo",{"href":79,"dataGaName":80,"dataGaLocation":45},"/gitlab-duo/","gitlab duo ai",{"title":82,"description":83,"link":84},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":85,"config":86},"Learn more",{"href":87,"dataGaName":88,"dataGaLocation":45},"/why-gitlab/","why gitlab",{"title":90,"items":91},"Get started with",[92,97,102],{"text":93,"config":94},"Platform Engineering",{"href":95,"dataGaName":96,"dataGaLocation":45},"/solutions/platform-engineering/","platform engineering",{"text":98,"config":99},"Developer Experience",{"href":100,"dataGaName":101,"dataGaLocation":45},"/developer-experience/","Developer experience",{"text":103,"config":104},"MLOps",{"href":105,"dataGaName":103,"dataGaLocation":45},"/topics/devops/the-role-of-ai-in-devops/",{"text":107,"left":28,"config":108,"link":110,"lists":114,"footer":184},"Product",{"dataNavLevelOne":109},"solutions",{"text":111,"config":112},"View all Solutions",{"href":113,"dataGaName":109,"dataGaLocation":45},"/solutions/",[115,139,163],{"title":116,"description":117,"link":118,"items":123},"Automation","CI/CD and automation to accelerate deployment",{"config":119},{"icon":120,"href":121,"dataGaName":122,"dataGaLocation":45},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[124,127,131,135],{"text":25,"config":125},{"href":126,"dataGaLocation":45,"dataGaName":25},"/solutions/continuous-integration/",{"text":128,"config":129},"AI-Assisted Development",{"href":79,"dataGaLocation":45,"dataGaName":130},"AI assisted development",{"text":132,"config":133},"Source Code Management",{"href":134,"dataGaLocation":45,"dataGaName":132},"/solutions/source-code-management/",{"text":136,"config":137},"Automated Software Delivery",{"href":121,"dataGaLocation":45,"dataGaName":138},"Automated software delivery",{"title":140,"description":141,"link":142,"items":147},"Security","Deliver code faster without compromising security",{"config":143},{"href":144,"dataGaName":145,"dataGaLocation":45,"icon":146},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[148,153,158],{"text":149,"config":150},"Application Security Testing",{"href":151,"dataGaName":152,"dataGaLocation":45},"/solutions/application-security-testing/","Application security testing",{"text":154,"config":155},"Software Supply Chain Security",{"href":156,"dataGaLocation":45,"dataGaName":157},"/solutions/supply-chain/","Software supply chain security",{"text":159,"config":160},"Software Compliance",{"href":161,"dataGaName":162,"dataGaLocation":45},"/solutions/software-compliance/","software compliance",{"title":164,"link":165,"items":170},"Measurement",{"config":166},{"icon":167,"href":168,"dataGaName":169,"dataGaLocation":45},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[171,175,179],{"text":172,"config":173},"Visibility & Measurement",{"href":168,"dataGaLocation":45,"dataGaName":174},"Visibility and Measurement",{"text":176,"config":177},"Value Stream Management",{"href":178,"dataGaLocation":45,"dataGaName":176},"/solutions/value-stream-management/",{"text":180,"config":181},"Analytics & Insights",{"href":182,"dataGaLocation":45,"dataGaName":183},"/solutions/analytics-and-insights/","Analytics and insights",{"title":185,"items":186},"GitLab for",[187,192,197],{"text":188,"config":189},"Enterprise",{"href":190,"dataGaLocation":45,"dataGaName":191},"/enterprise/","enterprise",{"text":193,"config":194},"Small Business",{"href":195,"dataGaLocation":45,"dataGaName":196},"/small-business/","small business",{"text":198,"config":199},"Public Sector",{"href":200,"dataGaLocation":45,"dataGaName":201},"/solutions/public-sector/","public sector",{"text":203,"config":204},"Pricing",{"href":205,"dataGaName":206,"dataGaLocation":45,"dataNavLevelOne":206},"/pricing/","pricing",{"text":208,"config":209,"link":211,"lists":215,"feature":299},"Resources",{"dataNavLevelOne":210},"resources",{"text":212,"config":213},"View all resources",{"href":214,"dataGaName":210,"dataGaLocation":45},"/resources/",[216,249,271],{"title":217,"items":218},"Getting started",[219,224,229,234,239,244],{"text":220,"config":221},"Install",{"href":222,"dataGaName":223,"dataGaLocation":45},"/install/","install",{"text":225,"config":226},"Quick start guides",{"href":227,"dataGaName":228,"dataGaLocation":45},"/get-started/","quick setup checklists",{"text":230,"config":231},"Learn",{"href":232,"dataGaLocation":45,"dataGaName":233},"https://university.gitlab.com/","learn",{"text":235,"config":236},"Product documentation",{"href":237,"dataGaName":238,"dataGaLocation":45},"https://docs.gitlab.com/","product documentation",{"text":240,"config":241},"Best practice videos",{"href":242,"dataGaName":243,"dataGaLocation":45},"/getting-started-videos/","best practice videos",{"text":245,"config":246},"Integrations",{"href":247,"dataGaName":248,"dataGaLocation":45},"/integrations/","integrations",{"title":250,"items":251},"Discover",[252,257,261,266],{"text":253,"config":254},"Customer success stories",{"href":255,"dataGaName":256,"dataGaLocation":45},"/customers/","customer success stories",{"text":258,"config":259},"Blog",{"href":260,"dataGaName":5,"dataGaLocation":45},"/blog/",{"text":262,"config":263},"Remote",{"href":264,"dataGaName":265,"dataGaLocation":45},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":267,"config":268},"TeamOps",{"href":269,"dataGaName":270,"dataGaLocation":45},"/teamops/","teamops",{"title":272,"items":273},"Connect",[274,279,284,289,294],{"text":275,"config":276},"GitLab Services",{"href":277,"dataGaName":278,"dataGaLocation":45},"/services/","services",{"text":280,"config":281},"Community",{"href":282,"dataGaName":283,"dataGaLocation":45},"/community/","community",{"text":285,"config":286},"Forum",{"href":287,"dataGaName":288,"dataGaLocation":45},"https://forum.gitlab.com/","forum",{"text":290,"config":291},"Events",{"href":292,"dataGaName":293,"dataGaLocation":45},"/events/","events",{"text":295,"config":296},"Partners",{"href":297,"dataGaName":298,"dataGaLocation":45},"/partners/","partners",{"backgroundColor":300,"textColor":301,"text":302,"image":303,"link":307},"#2f2a6b","#fff","Insights for the future of software development",{"altText":304,"config":305},"the source promo card",{"src":306},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":308,"config":309},"Read the latest",{"href":310,"dataGaName":311,"dataGaLocation":45},"/the-source/","the source",{"text":313,"config":314,"lists":316},"Company",{"dataNavLevelOne":315},"company",[317],{"items":318},[319,324,330,332,337,342,347,352,357,362,367],{"text":320,"config":321},"About",{"href":322,"dataGaName":323,"dataGaLocation":45},"/company/","about",{"text":325,"config":326,"footerGa":329},"Jobs",{"href":327,"dataGaName":328,"dataGaLocation":45},"/jobs/","jobs",{"dataGaName":328},{"text":290,"config":331},{"href":292,"dataGaName":293,"dataGaLocation":45},{"text":333,"config":334},"Leadership",{"href":335,"dataGaName":336,"dataGaLocation":45},"/company/team/e-group/","leadership",{"text":338,"config":339},"Team",{"href":340,"dataGaName":341,"dataGaLocation":45},"/company/team/","team",{"text":343,"config":344},"Handbook",{"href":345,"dataGaName":346,"dataGaLocation":45},"https://handbook.gitlab.com/","handbook",{"text":348,"config":349},"Investor relations",{"href":350,"dataGaName":351,"dataGaLocation":45},"https://ir.gitlab.com/","investor relations",{"text":353,"config":354},"Trust Center",{"href":355,"dataGaName":356,"dataGaLocation":45},"/security/","trust center",{"text":358,"config":359},"AI Transparency Center",{"href":360,"dataGaName":361,"dataGaLocation":45},"/ai-transparency-center/","ai transparency center",{"text":363,"config":364},"Newsletter",{"href":365,"dataGaName":366,"dataGaLocation":45},"/company/contact/","newsletter",{"text":368,"config":369},"Press",{"href":370,"dataGaName":371,"dataGaLocation":45},"/press/","press",{"text":373,"config":374,"lists":375},"Contact us",{"dataNavLevelOne":315},[376],{"items":377},[378,381,386],{"text":52,"config":379},{"href":54,"dataGaName":380,"dataGaLocation":45},"talk to sales",{"text":382,"config":383},"Get help",{"href":384,"dataGaName":385,"dataGaLocation":45},"/support/","get help",{"text":387,"config":388},"Customer portal",{"href":389,"dataGaName":390,"dataGaLocation":45},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":392,"login":393,"suggestions":400},"Close",{"text":394,"link":395},"To search repositories and projects, login to",{"text":396,"config":397},"gitlab.com",{"href":59,"dataGaName":398,"dataGaLocation":399},"search login","search",{"text":401,"default":402},"Suggestions",[403,405,409,411,415,419],{"text":74,"config":404},{"href":79,"dataGaName":74,"dataGaLocation":399},{"text":406,"config":407},"Code Suggestions (AI)",{"href":408,"dataGaName":406,"dataGaLocation":399},"/solutions/code-suggestions/",{"text":25,"config":410},{"href":126,"dataGaName":25,"dataGaLocation":399},{"text":412,"config":413},"GitLab on AWS",{"href":414,"dataGaName":412,"dataGaLocation":399},"/partners/technology-partners/aws/",{"text":416,"config":417},"GitLab on Google Cloud",{"href":418,"dataGaName":416,"dataGaLocation":399},"/partners/technology-partners/google-cloud-platform/",{"text":420,"config":421},"Why GitLab?",{"href":87,"dataGaName":420,"dataGaLocation":399},{"freeTrial":423,"mobileIcon":428,"desktopIcon":433,"secondaryButton":436},{"text":424,"config":425},"Start free trial",{"href":426,"dataGaName":50,"dataGaLocation":427},"https://gitlab.com/-/trials/new/","nav",{"altText":429,"config":430},"Gitlab Icon",{"src":431,"dataGaName":432,"dataGaLocation":427},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":429,"config":434},{"src":435,"dataGaName":432,"dataGaLocation":427},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":437,"config":438},"Get Started",{"href":439,"dataGaName":440,"dataGaLocation":427},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":442,"mobileIcon":446,"desktopIcon":448},{"text":443,"config":444},"Learn more about GitLab Duo",{"href":79,"dataGaName":445,"dataGaLocation":427},"gitlab duo",{"altText":429,"config":447},{"src":431,"dataGaName":432,"dataGaLocation":427},{"altText":429,"config":449},{"src":435,"dataGaName":432,"dataGaLocation":427},{"freeTrial":451,"mobileIcon":456,"desktopIcon":458},{"text":452,"config":453},"Back to pricing",{"href":205,"dataGaName":454,"dataGaLocation":427,"icon":455},"back to pricing","GoBack",{"altText":429,"config":457},{"src":431,"dataGaName":432,"dataGaLocation":427},{"altText":429,"config":459},{"src":435,"dataGaName":432,"dataGaLocation":427},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":465,"_dir":39,"_draft":6,"_partial":6,"_locale":7,"title":466,"button":467,"image":472,"config":476,"_id":478,"_type":31,"_source":33,"_file":479,"_stem":480,"_extension":36},"/shared/en-us/banner","is now in public beta!",{"text":468,"config":469},"Try the Beta",{"href":470,"dataGaName":471,"dataGaLocation":45},"/gitlab-duo/agent-platform/","duo banner",{"altText":473,"config":474},"GitLab Duo Agent Platform",{"src":475},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1753720689/somrf9zaunk0xlt7ne4x.svg",{"layout":477},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":482,"_dir":39,"_draft":6,"_partial":6,"_locale":7,"data":483,"_id":687,"_type":31,"title":688,"_source":33,"_file":689,"_stem":690,"_extension":36},"/shared/en-us/main-footer",{"text":484,"source":485,"edit":491,"contribute":496,"config":501,"items":506,"minimal":679},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":486,"config":487},"View page source",{"href":488,"dataGaName":489,"dataGaLocation":490},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":492,"config":493},"Edit this page",{"href":494,"dataGaName":495,"dataGaLocation":490},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":497,"config":498},"Please contribute",{"href":499,"dataGaName":500,"dataGaLocation":490},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":502,"facebook":503,"youtube":504,"linkedin":505},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[507,530,586,615,649],{"title":63,"links":508,"subMenu":513},[509],{"text":510,"config":511},"DevSecOps platform",{"href":72,"dataGaName":512,"dataGaLocation":490},"devsecops platform",[514],{"title":203,"links":515},[516,520,525],{"text":517,"config":518},"View plans",{"href":205,"dataGaName":519,"dataGaLocation":490},"view plans",{"text":521,"config":522},"Why Premium?",{"href":523,"dataGaName":524,"dataGaLocation":490},"/pricing/premium/","why premium",{"text":526,"config":527},"Why Ultimate?",{"href":528,"dataGaName":529,"dataGaLocation":490},"/pricing/ultimate/","why ultimate",{"title":531,"links":532},"Solutions",[533,538,540,542,547,552,556,559,563,568,570,573,576,581],{"text":534,"config":535},"Digital transformation",{"href":536,"dataGaName":537,"dataGaLocation":490},"/topics/digital-transformation/","digital transformation",{"text":149,"config":539},{"href":151,"dataGaName":149,"dataGaLocation":490},{"text":138,"config":541},{"href":121,"dataGaName":122,"dataGaLocation":490},{"text":543,"config":544},"Agile development",{"href":545,"dataGaName":546,"dataGaLocation":490},"/solutions/agile-delivery/","agile delivery",{"text":548,"config":549},"Cloud transformation",{"href":550,"dataGaName":551,"dataGaLocation":490},"/topics/cloud-native/","cloud transformation",{"text":553,"config":554},"SCM",{"href":134,"dataGaName":555,"dataGaLocation":490},"source code management",{"text":25,"config":557},{"href":126,"dataGaName":558,"dataGaLocation":490},"continuous integration & delivery",{"text":560,"config":561},"Value stream management",{"href":178,"dataGaName":562,"dataGaLocation":490},"value stream management",{"text":564,"config":565},"GitOps",{"href":566,"dataGaName":567,"dataGaLocation":490},"/solutions/gitops/","gitops",{"text":188,"config":569},{"href":190,"dataGaName":191,"dataGaLocation":490},{"text":571,"config":572},"Small business",{"href":195,"dataGaName":196,"dataGaLocation":490},{"text":574,"config":575},"Public sector",{"href":200,"dataGaName":201,"dataGaLocation":490},{"text":577,"config":578},"Education",{"href":579,"dataGaName":580,"dataGaLocation":490},"/solutions/education/","education",{"text":582,"config":583},"Financial services",{"href":584,"dataGaName":585,"dataGaLocation":490},"/solutions/finance/","financial services",{"title":208,"links":587},[588,590,592,594,597,599,601,603,605,607,609,611,613],{"text":220,"config":589},{"href":222,"dataGaName":223,"dataGaLocation":490},{"text":225,"config":591},{"href":227,"dataGaName":228,"dataGaLocation":490},{"text":230,"config":593},{"href":232,"dataGaName":233,"dataGaLocation":490},{"text":235,"config":595},{"href":237,"dataGaName":596,"dataGaLocation":490},"docs",{"text":258,"config":598},{"href":260,"dataGaName":5,"dataGaLocation":490},{"text":253,"config":600},{"href":255,"dataGaName":256,"dataGaLocation":490},{"text":262,"config":602},{"href":264,"dataGaName":265,"dataGaLocation":490},{"text":275,"config":604},{"href":277,"dataGaName":278,"dataGaLocation":490},{"text":267,"config":606},{"href":269,"dataGaName":270,"dataGaLocation":490},{"text":280,"config":608},{"href":282,"dataGaName":283,"dataGaLocation":490},{"text":285,"config":610},{"href":287,"dataGaName":288,"dataGaLocation":490},{"text":290,"config":612},{"href":292,"dataGaName":293,"dataGaLocation":490},{"text":295,"config":614},{"href":297,"dataGaName":298,"dataGaLocation":490},{"title":313,"links":616},[617,619,621,623,625,627,629,633,638,640,642,644],{"text":320,"config":618},{"href":322,"dataGaName":315,"dataGaLocation":490},{"text":325,"config":620},{"href":327,"dataGaName":328,"dataGaLocation":490},{"text":333,"config":622},{"href":335,"dataGaName":336,"dataGaLocation":490},{"text":338,"config":624},{"href":340,"dataGaName":341,"dataGaLocation":490},{"text":343,"config":626},{"href":345,"dataGaName":346,"dataGaLocation":490},{"text":348,"config":628},{"href":350,"dataGaName":351,"dataGaLocation":490},{"text":630,"config":631},"Sustainability",{"href":632,"dataGaName":630,"dataGaLocation":490},"/sustainability/",{"text":634,"config":635},"Diversity, inclusion and belonging (DIB)",{"href":636,"dataGaName":637,"dataGaLocation":490},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":353,"config":639},{"href":355,"dataGaName":356,"dataGaLocation":490},{"text":363,"config":641},{"href":365,"dataGaName":366,"dataGaLocation":490},{"text":368,"config":643},{"href":370,"dataGaName":371,"dataGaLocation":490},{"text":645,"config":646},"Modern Slavery Transparency Statement",{"href":647,"dataGaName":648,"dataGaLocation":490},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":650,"links":651},"Contact Us",[652,655,657,659,664,669,674],{"text":653,"config":654},"Contact an expert",{"href":54,"dataGaName":55,"dataGaLocation":490},{"text":382,"config":656},{"href":384,"dataGaName":385,"dataGaLocation":490},{"text":387,"config":658},{"href":389,"dataGaName":390,"dataGaLocation":490},{"text":660,"config":661},"Status",{"href":662,"dataGaName":663,"dataGaLocation":490},"https://status.gitlab.com/","status",{"text":665,"config":666},"Terms of use",{"href":667,"dataGaName":668,"dataGaLocation":490},"/terms/","terms of use",{"text":670,"config":671},"Privacy statement",{"href":672,"dataGaName":673,"dataGaLocation":490},"/privacy/","privacy statement",{"text":675,"config":676},"Cookie preferences",{"dataGaName":677,"dataGaLocation":490,"id":678,"isOneTrustButton":28},"cookie preferences","ot-sdk-btn",{"items":680},[681,683,685],{"text":665,"config":682},{"href":667,"dataGaName":668,"dataGaLocation":490},{"text":670,"config":684},{"href":672,"dataGaName":673,"dataGaLocation":490},{"text":675,"config":686},{"dataGaName":677,"dataGaLocation":490,"id":678,"isOneTrustButton":28},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",[692,704],{"_path":693,"_dir":694,"_draft":6,"_partial":6,"_locale":7,"content":695,"config":699,"_id":701,"_type":31,"title":18,"_source":33,"_file":702,"_stem":703,"_extension":36},"/en-us/blog/authors/matt-genelin","authors",{"name":18,"config":696},{"headshot":697,"ctfId":698},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664522/Blog/Author%20Headshots/matty_genelin.png","6x9dTYZik3lSViI8hu6dYQ",{"template":700},"BlogAuthor","content:en-us:blog:authors:matt-genelin.yml","en-us/blog/authors/matt-genelin.yml","en-us/blog/authors/matt-genelin",{"_path":705,"_dir":694,"_draft":6,"_partial":6,"_locale":7,"content":706,"config":710,"_id":711,"_type":31,"title":19,"_source":33,"_file":712,"_stem":713,"_extension":36},"/en-us/blog/authors/mathias-ewald",{"name":19,"config":707},{"headshot":708,"ctfId":709},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664526/Blog/Author%20Headshots/mathias_ewald_headshot.png","7vLTPhU3yvh4xTToXcLpg9",{"template":700},"content:en-us:blog:authors:mathias-ewald.yml","en-us/blog/authors/mathias-ewald.yml","en-us/blog/authors/mathias-ewald",{"_path":715,"_dir":39,"_draft":6,"_partial":6,"_locale":7,"header":716,"eyebrow":717,"blurb":718,"button":719,"secondaryButton":723,"_id":725,"_type":31,"title":726,"_source":33,"_file":727,"_stem":728,"_extension":36},"/shared/en-us/next-steps","Start shipping better software faster","50%+ of the Fortune 100 trust GitLab","See what your team can do with the intelligent\n\n\nDevSecOps platform.\n",{"text":47,"config":720},{"href":721,"dataGaName":50,"dataGaLocation":722},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":52,"config":724},{"href":54,"dataGaName":55,"dataGaLocation":722},"content:shared:en-us:next-steps.yml","Next Steps","shared/en-us/next-steps.yml","shared/en-us/next-steps",1758326264974]