[{"data":1,"prerenderedAt":790},["ShallowReactive",2],{"/en-us/blog/why-are-developers-vulnerable-to-driveby-attacks":3,"navigation-en-us":34,"banner-en-us":434,"footer-en-us":444,"blog-post-authors-en-us-Chris Moberly":686,"blog-related-posts-en-us-why-are-developers-vulnerable-to-driveby-attacks":700,"assessment-promotions-en-us":742,"next-steps-en-us":780},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":23,"isFeatured":12,"meta":24,"navigation":25,"path":26,"publishedDate":20,"seo":27,"stem":31,"tagSlugs":32,"__hash__":33},"blogPosts/en-us/blog/why-are-developers-vulnerable-to-driveby-attacks.yml","Why Are Developers Vulnerable To Driveby Attacks",[7],"chris-moberly",null,"security",{"slug":11,"featured":12,"template":13},"why-are-developers-vulnerable-to-driveby-attacks",false,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"body":21,"category":9,"tags":22},"Why are developers so vulnerable to drive-by attacks?","The complexity of developer working environments make them more likely to be vulnerable to a drive-by attack. We talk about why and walk you through a real-life example from a recent disclosure here at GitLab, and provide tips to reduce the risk and impact of drive-by attacks.",[18],"Chris Moberly","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682986/Blog/Hero%20Images/pexels-pixabay-434450.jpg","2021-09-07","\nAs someone who spends a lot of time working with computers, I know how easy it is to grow over-confident with regards to security. My systems are patched, my firewall rules are tight, and I’m vigilant when it comes to just about anything that looks out of the ordinary.\n\nNo one’s hacking their way into *my* workstation, that’s for sure.\n\nBut my experience working as a hacker myself has shown me that the opposite is often true. Those of us who are *more* technical are often *much more* vulnerable to an attack due to the complexity of our working environments.\n\nIn this blog, we’re going to dive into the anatomy of something called a “drive-by attack,” where malicious code hidden within a website uses your own browser to attack your computer.\n\nAs an example, I’ll show you how our own [Red Team](https://handbook.gitlab.com/handbook/security/security-operations/red-team/) was able to chain multiple vulnerabilities in the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/README.md) (GDK) to achieve remote code execution (RCE) on developer laptops. And lastly, we’ll discuss steps you can take to reduce the risk of this happening to you.\n\n## How drive-by attacks work\n\nDrive-by attacks come in many forms. Each type of attack starts the same way - you visit a website that contains some malicious code (typically JavaScript). That code will then target a specific type of vulnerability, either in your browser itself or in some other network service that your browser can access. In this blog, we will focus on the latter.\n\nWhat I find particularly fascinating about these attacks is that they completely bypass traditional protections like network firewalls and antivirus software. I think many are under the impression that a network service running on their localhost address cannot be targeted remotely. This is simply not true; in fact, this same technique can be used to target any service on your local network, even those without any outbound internet access at all!\n\nLet’s say you are running a test webserver on your laptop on port 8000. You can simulate this running a simple [netcat](https://en.wikipedia.org/wiki/Netcat) command:\n\n```text\nnc -lkp 8000\n```\n\nNow let’s say you are browsing the internet while that test server is running locally. You visit a site that has been compromised with malicious JavaScript. We’ve set up a site at [https://gitlab-com.gitlab.io/gl-security/security-operations/gl-redteam/simple-request](https://gitlab-com.gitlab.io/gl-security/security-operations/gl-redteam/simple-request) that mimics a basic attack. The site contains the following JavaScript:\n\n```xml\n\u003Cscript>\n\tfetch(\"http://localhost:8000\", {\n    \tmethod: 'post',\n    \tbody: 'you\\'re under attack!',\n\t})\n\u003C/script>\n```\n\nWhen you open the site in your browser, you should see that a POST request has been executed against your simulated server, like the screenshot below.\n\n![file name](https://about.gitlab.com/images/blogimages/drive-by/firefox.png)\nHelp, I’m under attack!\n\nWhen JavaScript attempts to interact with another website, the first thing your browser checks is whether or not the protocol, port, and domain all match between that other site and where the script was originally loaded from. This is called the [same-origin policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy): it's your browser’s first line of defense when it comes to these types of attacks.\n\nIn our example above, none of these items matched. That makes this a cross-origin request. Luckily, modern browsers have some mechanisms to restrict exactly what these types of requests can do.\n\nOne of these is called a “[CORS preflight request](https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request).” When some JavaScript asks your browser to perform complex actions on a cross-origin request, your browser will first send an HTTP OPTIONS request to the target. The target will respond with various HTTP headers that tell the browser what is allowed. The most common of these is the “[Access-Control-Allow-Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin)” header.\n\nIf this header is set to `*` or to the website containing the malicious code, then your browser will let the code perform complex HTTP requests and access the responses. This would include shipping results off to a remote server, or performing complex multi-step actions like logging in to a service or gaining access to the session token; basically the code will be interacting with it as if it were a human user.\n\nAnother header you may encounter is [Access-Control-Allow-Credentials](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#requests_with_credentials). When set to `true`, the origin specified in `Access-Control-Allow-Origin` can perform credentialed requests utilizing the browser’s active sessions. When origin validation is not done properly and the requesting origin is blindly reflected in `Access-Control-Allow-Origin`, drive-by attacks against authenticated services become much more likely to succeed as they do not need to first guess the password and mimic a logon.\n\nFrom my experience, the first example (`Access-Control-Allow-Origin: *`) is enabled quite often in development software and open-source projects. Even production-ready applications may intentionally set this header to `*` when started with certain flags that tell them they are running in development mode.\n\nWhat makes matters worse is that software run in development mode tends to have other relaxed security measures: verbose error logging, default passwords or even debuggers that allow web requests to execute commands on the host operating system. This makes it very easy for malicious JavaScript to turn basic cross-origin requests into full-on drive-by exploits that completely compromise your machine.\n\n**To be very clear, if you are running a web server on your workstation with this header set, you are granting permission to any website you visit to fully interact with your application. If that application has the ability to run commands on your laptop, you could be granting any website you visit permission to run commands on your laptop.**\n\n“*Well, that’s fine*,” you might think. “*I’ll just remove that header and be good to go*”.\n\nUnfortunately, it’s not that simple. The preflight check has a pretty big loophole via something called a “[simple request](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests).” Remote JavaScript is allowed to completely bypass the check if it follows some simple rules, like:\n\n- Must be only GET, HEAD, or POST\n- Must be one of three content types (`application/x-www-form-urlencoded`, `multipart/form-data` or `text/plain`)\n- Must use only a specific set of HTTP headers\n- Cannot read the response from the target service\n\nThis is why we had no issues running the “you’re under attack!” example above. It followed the rules and was a simple request.\n\nSo, to reiterate:\n\n* Any website on the internet can use your browser to attack any service you have access to as long as the attack follows certain rules.\n* Services that implement strong protections against Cross-Site Request Forgery (CSRF) can be more resilient to these attacks.\n* Services that specifically reduce these protections (like with the `Access-Control-Allow-Origin` header) are vulnerable to any attack, whether they follow the rules or not.\n\nHow confident are you that every service you run and test locally has implemented strong CSRF protections and has not removed them while in development mode? And even if they have, how confident are you that they cannot still be exploited via the simple requests described above?\n\n## Example: Drive-by RCE in the GitLab GDK\n\nThe GitLab GDK is a tool that helps GitLab contributors install a fully-functioning GitLab instance for development purposes.\n\nIn September of 2020, our Red Team was researching how our developers could be targeted by sophisticated attackers. We were able to chain multiple vulnerabilities in the GDK to conduct the exact type of attack described in this blog, demonstrating how developer workstations could be remotely compromised.\n\n**These vulnerabilities were quickly patched, the community was asked to upgrade, and this specific risk no longer exists. Read on below about the specific issues and their fixes.**\n\nThe attack targeted two components bundled with the GDK:\n\n* [Better Errors](https://github.com/BetterErrors/better_errors): a Rails error debugging tool\n* [webpack-dev-server](https://github.com/webpack/webpack-dev-server): a development web server that provides static file access\n\nWhen visited, the first thing the malicious website would do was to load the better_errors console in an invisible iframe. The result of this was a simple `GET` request from the browser to `http://localhost:3000/__better_errors`.\nWhen this URL was loaded, the better_errors application would generate a unique error code (this is important later on) and then send an HTTP redirect code back to the browser inside the iframe. The URL that it redirected to would include the unique error code, like this:\n\n```text\nhttp://localhost:3000/__better_errors/[ERROR CODE]/eval\n```\n\nBecause better_errors did not have the dangerous `Access-Control-Allow-Origin: *` header set, the malicious site could not actually view that response. However, the GDK keeps a lot of log files, including a record of every URL that has been accessed. This meant that the unique error code generated by better_errors was now stored in a log file on the workstation’s filesystem.\n\nThe next step targeted the webpack-dev-server. This ran on localhost on port 3808 and was configured with the overly-permissive CORS header `Access-Control-Allow-Origin: *`.  As discussed earlier in the blog, this header tells your browser that any website can interact freely with this service.\n\nwebpack-dev-server was configured to serve the contents of the log directory, so our malicious JavaScript could literally download and parse the current log file to extract the unique error code generated above.\n\nUsing this error code, the script would then create a specially-crafted HTTP POST request to instruct better_errors to evaluate arbitrary Ruby code. And, of course, with Ruby we can encapsulate operating system commands in backticks to execute any command we wanted to on the host. That request looked like this:\n\n```text\nPOST http://localhost:3000/__better_errors/[ERROR CODE]/eval\nContent-Type: text/plain\nAccept: text/html\n\n{\"index\":\"0\",\"source\":\"`touch /tmp/itworked`\"}\n```\n\nIt is worth noting that better_errors actually **did not** have an overly-permissive CORS header. So, technically, we should not have been able to send the above command. Because the content being sent was actually JSON, it would not have qualified as a “simple request” and would have had to pass a CORS preflight check, which would have failed.\n\nHowever, the `Content-type` header was not being validated properly. We were able to bypass the preflight check by incorrectly setting the content type to `text/plain` while still providing a JSON payload in the request body.\n\nWhen the malicious website instructed the browser to send that final request, the command would be executed and the host would be compromised.\n\n![file name](https://about.gitlab.com/images/blogimages/drive-by/driveby.png)\nThe original PoC in action.\n\nTo summarize the issues that made this possible:\n\n* Better Errors:\n     * Improper validation of content type header\n     * Lack of robust cross-site request forgery protection (CSRF tokens)  * webpack-dev-server:\n     * Was configured to serve the entire GitLab directory (via `contentBase: true`)\n     * Overly-permissive CORS header (`Access-Control-Allow-Origin: *`)\n\nWhile GitLab ended up completely removing Better Errors from the GDK, we did reach out to its author who was incredibly responsive and very quickly [implemented robust protection](https://github.com/BetterErrors/better_errors/pull/474) for the issues we disclosed.\n\nThe GDK still uses webpack-dev-server, but it has been configured to [stop serving the installation directory](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/41841) and to [stop sending the overly-permissive CORS header](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/46459).\n\nYou can view the source code for the original PoC exploit at [https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gdk-driveby-poc-public](https://gitlab.com/gitlab-com/gl-security/security-operations/gl-redteam/gdk-driveby-poc-public).\n\n## How to protect yourself from drive-by attacks\n\n### Secure your code from cross-origin attacks\n\nIf you are a developer looking to strengthen your own application, here are two great resources to get you started:\n\n* [OWASP Cross-Site Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)\n* [Portswigger: What is CORS?](https://portswigger.net/web-security/cors)\n\nDo not make the mistake of thinking that your application does not require protection just because it is never exposed to the internet. Any application that listens for requests on a network port can be attacked, even if it only ever runs on localhost for testing purposes.\n\n### Inspect your own network\n\nAs users of software in general, we need to be aware of the increased attack surface that comes with every piece of software we install.\n\n**How many network services do you have running locally on your workstation right now?** Try one of the following commands, you might be surprised by the results:\n\n```shell\n# Linux systems\nsudo ss -tlpa\n\n# MacOS systems\nsudo lsof -i -P | grep -i \"listen\"\n```\n\nHow about on your home network? Those are also potential targets for a drive-by attack. If your browser can access them, it can be used to attack them. You can get a quick view using [nmap](https://nmap.org/) like this:\n\n```text\n# Assuming your LAN is 192.168.1.0/24. Change as needed.\nnmap -sV 192.168.1.0/24\n```\n\nIf you uncover anything that looks like a web service, try to inspect the default HTTP response headers with a command like this:\n\n```shell\ncurl -vv -H \"Origin: http://attacker.com\" http://[IP ADDRESS]\n```\n\nIf the response headers include something like `Access-Control-Allow-Origin: *` or `Access-Control-Allow-Origin: http://attacker.com`, then you know right away that there is a high chance it is vulnerable to a drive-by attack.\n\nHowever, as demonstrated in our example above, even services with properly configured CORS headers can be targeted by drive-by attacks under the right conditions.\n\n### Reducing potential impact and risk\n\nWhen testing and developing software, we end up executing a lot of code via libraries and dependencies. It’s unlikely that we have the time and resources to personally audit every single line of that code. To make matters worse, we often run local environments with intentionally relaxed security controls because it is just too cumbersome to emulate full production environments on our workstations.\n\nEliminating these risks totally might be unrealistic, but we can at least make an effort to reduce the potential impact should one of these environments be compromised.\n\nIf you were to fall victim to a drive-by attack while running an insecure server on your workstation, you would be in for a very bad day. An attacker with a shell on your system can take over every authenticated web session you have, access all of your local data, and potentially compromise any other remote system you have access to.\n\nThe most obvious way to reduce risk would be to not run potentially risky software directly on your workstation. Some easy ways to do this would be:\n\n* Use temporary virtual machines (in the cloud or with local virtualization software) that are reverted to “known good” snapshots often. Ensure these machines contain no sensitive data.\n* Use container technology (LXD, Docker, etc) for launching temporary test environments. Follow best practices to make container escapes more difficult.\n\nNeither of the above are iron-clad protections. Attackers can still target VMs and containers using your workstation’s browser. Sophisticated attackers may even find their way out of that restricted environment and back onto your workstation. But these methods do add another layer between potentially insecure code and your sensitive data.\n\n### Secure your browser\n\nAdditional layers of security can also be implemented around the browser, by segmenting it or restricting what it can do. Remember, your browser is what a drive-by attack abuses to gain access to local services. Here are some ideas to consider:\n\n* Use the [Tor Browser](https://www.torproject.org/). Besides coming with enhanced security features enabled by default, it literally [cannot access localhost](https://gitlab.torproject.org/legacy/trac/-/issues/10419) or your LAN.\n* In your normal browser, plugins like [uBlock Origin](https://github.com/gorhill/uBlock) can limit the ability of JavaScript to execute (see [blocking modes](https://github.com/gorhill/uBlock/wiki/Blocking-mode)) and block sites from accessing local IP addresses (enable the \"block access to LAN\" [filter-list](https://github.com/gorhill/uBlock/wiki/Dashboard:-Filter-lists)).\n* Some attacks may use a DNS name that resolves to a local IP address, which would bypass the filter list described above. See if your provider supports something called \"DNS rebind protection\" (available in dnsmasq, pihole, and services like NextDNS).\n* You can run a web browser inside a virtual machine with limited access to your workstation and/or your LAN. This can be done manually or via products like [QubesOS](https://www.qubes-os.org/) and/or [Whonix](https://www.whonix.org/). Use this segmented browser when accessing sites that you do not trust completely. Revert the browser VMs back to a known good state often.\n\nSome of the ideas above, such as using the Tor Browser or a virtual machine, may not be particularly convenient for 100% of your tasks. You can use them selectively when accessing sites that you have specific concerns with (like while conducting incident response or security research).\n\n![file name](https://about.gitlab.com/images/blogimages/drive-by/tor-browser.png)\nTor Browser to the rescue!\n\n## Understand and protect your attack surface\n\nIf you are running software on your computer that listens on a local network port, you are running a server. That server can be accessed and attacked by any website you visit. Because software developers frequently test less-secure services on their local machines, they are at an increased risk of compromise by these types of attacks.\n\nUnderstanding this attack surface is important, as it lets you make decisions about what additional layers of security you can use to protect yourself. If you have any tips of your own to share, please do so in the comments below.\n\nThanks for reading!\n\nCover image by [Pixabay](https://www.pexels.com/@pixabay) on [Pexels](https://www.pexels.com/photo/action-asphalt-back-light-cars-434450/)\n",[9],"yml",{},true,"/en-us/blog/why-are-developers-vulnerable-to-driveby-attacks",{"title":15,"description":16,"ogTitle":15,"ogDescription":16,"noIndex":12,"ogImage":19,"ogUrl":28,"ogSiteName":29,"ogType":30,"canonicalUrls":28},"https://about.gitlab.com/blog/why-are-developers-vulnerable-to-driveby-attacks","https://about.gitlab.com","article","en-us/blog/why-are-developers-vulnerable-to-driveby-attacks",[9],"UD1NRx0QyFbRL08OHafJEhVrNpBDK8Is6NzsaL5L93k",{"data":35},{"logo":36,"freeTrial":41,"sales":46,"login":51,"items":56,"search":364,"minimal":395,"duo":414,"pricingDeployment":424},{"config":37},{"href":38,"dataGaName":39,"dataGaLocation":40},"/","gitlab logo","header",{"text":42,"config":43},"Get free trial",{"href":44,"dataGaName":45,"dataGaLocation":40},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":47,"config":48},"Talk to sales",{"href":49,"dataGaName":50,"dataGaLocation":40},"/sales/","sales",{"text":52,"config":53},"Sign in",{"href":54,"dataGaName":55,"dataGaLocation":40},"https://gitlab.com/users/sign_in/","sign in",[57,84,179,184,285,345],{"text":58,"config":59,"cards":61},"Platform",{"dataNavLevelOne":60},"platform",[62,68,76],{"title":58,"description":63,"link":64},"The intelligent orchestration platform for DevSecOps",{"text":65,"config":66},"Explore our Platform",{"href":67,"dataGaName":60,"dataGaLocation":40},"/platform/",{"title":69,"description":70,"link":71},"GitLab Duo Agent Platform","Agentic AI for the entire software lifecycle",{"text":72,"config":73},"Meet GitLab Duo",{"href":74,"dataGaName":75,"dataGaLocation":40},"/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":77,"description":78,"link":79},"Why GitLab","See the top reasons enterprises choose GitLab",{"text":80,"config":81},"Learn more",{"href":82,"dataGaName":83,"dataGaLocation":40},"/why-gitlab/","why gitlab",{"text":85,"left":25,"config":86,"link":88,"lists":92,"footer":161},"Product",{"dataNavLevelOne":87},"solutions",{"text":89,"config":90},"View all Solutions",{"href":91,"dataGaName":87,"dataGaLocation":40},"/solutions/",[93,117,140],{"title":94,"description":95,"link":96,"items":101},"Automation","CI/CD and automation to accelerate deployment",{"config":97},{"icon":98,"href":99,"dataGaName":100,"dataGaLocation":40},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[102,106,109,113],{"text":103,"config":104},"CI/CD",{"href":105,"dataGaLocation":40,"dataGaName":103},"/solutions/continuous-integration/",{"text":69,"config":107},{"href":74,"dataGaLocation":40,"dataGaName":108},"gitlab duo agent platform - product menu",{"text":110,"config":111},"Source Code Management",{"href":112,"dataGaLocation":40,"dataGaName":110},"/solutions/source-code-management/",{"text":114,"config":115},"Automated Software Delivery",{"href":99,"dataGaLocation":40,"dataGaName":116},"Automated software delivery",{"title":118,"description":119,"link":120,"items":125},"Security","Deliver code faster without compromising security",{"config":121},{"href":122,"dataGaName":123,"dataGaLocation":40,"icon":124},"/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[126,130,135],{"text":127,"config":128},"Application Security Testing",{"href":122,"dataGaName":129,"dataGaLocation":40},"Application security testing",{"text":131,"config":132},"Software Supply Chain Security",{"href":133,"dataGaLocation":40,"dataGaName":134},"/solutions/supply-chain/","Software supply chain security",{"text":136,"config":137},"Software Compliance",{"href":138,"dataGaName":139,"dataGaLocation":40},"/solutions/software-compliance/","software compliance",{"title":141,"link":142,"items":147},"Measurement",{"config":143},{"icon":144,"href":145,"dataGaName":146,"dataGaLocation":40},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[148,152,156],{"text":149,"config":150},"Visibility & Measurement",{"href":145,"dataGaLocation":40,"dataGaName":151},"Visibility and Measurement",{"text":153,"config":154},"Value Stream Management",{"href":155,"dataGaLocation":40,"dataGaName":153},"/solutions/value-stream-management/",{"text":157,"config":158},"Analytics & Insights",{"href":159,"dataGaLocation":40,"dataGaName":160},"/solutions/analytics-and-insights/","Analytics and insights",{"title":162,"items":163},"GitLab for",[164,169,174],{"text":165,"config":166},"Enterprise",{"href":167,"dataGaLocation":40,"dataGaName":168},"/enterprise/","enterprise",{"text":170,"config":171},"Small Business",{"href":172,"dataGaLocation":40,"dataGaName":173},"/small-business/","small business",{"text":175,"config":176},"Public Sector",{"href":177,"dataGaLocation":40,"dataGaName":178},"/solutions/public-sector/","public sector",{"text":180,"config":181},"Pricing",{"href":182,"dataGaName":183,"dataGaLocation":40,"dataNavLevelOne":183},"/pricing/","pricing",{"text":185,"config":186,"link":188,"lists":192,"feature":272},"Resources",{"dataNavLevelOne":187},"resources",{"text":189,"config":190},"View all resources",{"href":191,"dataGaName":187,"dataGaLocation":40},"/resources/",[193,226,244],{"title":194,"items":195},"Getting started",[196,201,206,211,216,221],{"text":197,"config":198},"Install",{"href":199,"dataGaName":200,"dataGaLocation":40},"/install/","install",{"text":202,"config":203},"Quick start guides",{"href":204,"dataGaName":205,"dataGaLocation":40},"/get-started/","quick setup checklists",{"text":207,"config":208},"Learn",{"href":209,"dataGaLocation":40,"dataGaName":210},"https://university.gitlab.com/","learn",{"text":212,"config":213},"Product documentation",{"href":214,"dataGaName":215,"dataGaLocation":40},"https://docs.gitlab.com/","product documentation",{"text":217,"config":218},"Best practice videos",{"href":219,"dataGaName":220,"dataGaLocation":40},"/getting-started-videos/","best practice videos",{"text":222,"config":223},"Integrations",{"href":224,"dataGaName":225,"dataGaLocation":40},"/integrations/","integrations",{"title":227,"items":228},"Discover",[229,234,239],{"text":230,"config":231},"Customer success stories",{"href":232,"dataGaName":233,"dataGaLocation":40},"/customers/","customer success stories",{"text":235,"config":236},"Blog",{"href":237,"dataGaName":238,"dataGaLocation":40},"/blog/","blog",{"text":240,"config":241},"Remote",{"href":242,"dataGaName":243,"dataGaLocation":40},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":245,"items":246},"Connect",[247,252,257,262,267],{"text":248,"config":249},"GitLab Services",{"href":250,"dataGaName":251,"dataGaLocation":40},"/services/","services",{"text":253,"config":254},"Community",{"href":255,"dataGaName":256,"dataGaLocation":40},"/community/","community",{"text":258,"config":259},"Forum",{"href":260,"dataGaName":261,"dataGaLocation":40},"https://forum.gitlab.com/","forum",{"text":263,"config":264},"Events",{"href":265,"dataGaName":266,"dataGaLocation":40},"/events/","events",{"text":268,"config":269},"Partners",{"href":270,"dataGaName":271,"dataGaLocation":40},"/partners/","partners",{"backgroundColor":273,"textColor":274,"text":275,"image":276,"link":280},"#2f2a6b","#fff","Insights for the future of software development",{"altText":277,"config":278},"the source promo card",{"src":279},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":281,"config":282},"Read the latest",{"href":283,"dataGaName":284,"dataGaLocation":40},"/the-source/","the source",{"text":286,"config":287,"lists":289},"Company",{"dataNavLevelOne":288},"company",[290],{"items":291},[292,297,303,305,310,315,320,325,330,335,340],{"text":293,"config":294},"About",{"href":295,"dataGaName":296,"dataGaLocation":40},"/company/","about",{"text":298,"config":299,"footerGa":302},"Jobs",{"href":300,"dataGaName":301,"dataGaLocation":40},"/jobs/","jobs",{"dataGaName":301},{"text":263,"config":304},{"href":265,"dataGaName":266,"dataGaLocation":40},{"text":306,"config":307},"Leadership",{"href":308,"dataGaName":309,"dataGaLocation":40},"/company/team/e-group/","leadership",{"text":311,"config":312},"Team",{"href":313,"dataGaName":314,"dataGaLocation":40},"/company/team/","team",{"text":316,"config":317},"Handbook",{"href":318,"dataGaName":319,"dataGaLocation":40},"https://handbook.gitlab.com/","handbook",{"text":321,"config":322},"Investor relations",{"href":323,"dataGaName":324,"dataGaLocation":40},"https://ir.gitlab.com/","investor relations",{"text":326,"config":327},"Trust Center",{"href":328,"dataGaName":329,"dataGaLocation":40},"/security/","trust center",{"text":331,"config":332},"AI Transparency Center",{"href":333,"dataGaName":334,"dataGaLocation":40},"/ai-transparency-center/","ai transparency center",{"text":336,"config":337},"Newsletter",{"href":338,"dataGaName":339,"dataGaLocation":40},"/company/contact/#contact-forms","newsletter",{"text":341,"config":342},"Press",{"href":343,"dataGaName":344,"dataGaLocation":40},"/press/","press",{"text":346,"config":347,"lists":348},"Contact us",{"dataNavLevelOne":288},[349],{"items":350},[351,354,359],{"text":47,"config":352},{"href":49,"dataGaName":353,"dataGaLocation":40},"talk to sales",{"text":355,"config":356},"Support portal",{"href":357,"dataGaName":358,"dataGaLocation":40},"https://support.gitlab.com","support portal",{"text":360,"config":361},"Customer portal",{"href":362,"dataGaName":363,"dataGaLocation":40},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":365,"login":366,"suggestions":373},"Close",{"text":367,"link":368},"To search repositories and projects, login to",{"text":369,"config":370},"gitlab.com",{"href":54,"dataGaName":371,"dataGaLocation":372},"search login","search",{"text":374,"default":375},"Suggestions",[376,378,382,384,388,392],{"text":69,"config":377},{"href":74,"dataGaName":69,"dataGaLocation":372},{"text":379,"config":380},"Code Suggestions (AI)",{"href":381,"dataGaName":379,"dataGaLocation":372},"/solutions/code-suggestions/",{"text":103,"config":383},{"href":105,"dataGaName":103,"dataGaLocation":372},{"text":385,"config":386},"GitLab on AWS",{"href":387,"dataGaName":385,"dataGaLocation":372},"/partners/technology-partners/aws/",{"text":389,"config":390},"GitLab on Google Cloud",{"href":391,"dataGaName":389,"dataGaLocation":372},"/partners/technology-partners/google-cloud-platform/",{"text":393,"config":394},"Why GitLab?",{"href":82,"dataGaName":393,"dataGaLocation":372},{"freeTrial":396,"mobileIcon":401,"desktopIcon":406,"secondaryButton":409},{"text":397,"config":398},"Start free trial",{"href":399,"dataGaName":45,"dataGaLocation":400},"https://gitlab.com/-/trials/new/","nav",{"altText":402,"config":403},"Gitlab Icon",{"src":404,"dataGaName":405,"dataGaLocation":400},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":402,"config":407},{"src":408,"dataGaName":405,"dataGaLocation":400},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":410,"config":411},"Get Started",{"href":412,"dataGaName":413,"dataGaLocation":400},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/get-started/","get started",{"freeTrial":415,"mobileIcon":420,"desktopIcon":422},{"text":416,"config":417},"Learn more about GitLab Duo",{"href":418,"dataGaName":419,"dataGaLocation":400},"/gitlab-duo/","gitlab duo",{"altText":402,"config":421},{"src":404,"dataGaName":405,"dataGaLocation":400},{"altText":402,"config":423},{"src":408,"dataGaName":405,"dataGaLocation":400},{"freeTrial":425,"mobileIcon":430,"desktopIcon":432},{"text":426,"config":427},"Back to pricing",{"href":182,"dataGaName":428,"dataGaLocation":400,"icon":429},"back to pricing","GoBack",{"altText":402,"config":431},{"src":404,"dataGaName":405,"dataGaLocation":400},{"altText":402,"config":433},{"src":408,"dataGaName":405,"dataGaLocation":400},{"title":435,"button":436,"config":441},"See how agentic AI transforms software delivery",{"text":437,"config":438},"Watch GitLab Transcend now",{"href":439,"dataGaName":440,"dataGaLocation":40},"/events/transcend/virtual/","transcend event",{"layout":442,"icon":443},"release","AiStar",{"data":445},{"text":446,"source":447,"edit":453,"contribute":458,"config":463,"items":468,"minimal":675},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":448,"config":449},"View page source",{"href":450,"dataGaName":451,"dataGaLocation":452},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":454,"config":455},"Edit this page",{"href":456,"dataGaName":457,"dataGaLocation":452},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":459,"config":460},"Please contribute",{"href":461,"dataGaName":462,"dataGaLocation":452},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":464,"facebook":465,"youtube":466,"linkedin":467},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[469,516,570,614,641],{"title":180,"links":470,"subMenu":485},[471,475,480],{"text":472,"config":473},"View plans",{"href":182,"dataGaName":474,"dataGaLocation":452},"view plans",{"text":476,"config":477},"Why Premium?",{"href":478,"dataGaName":479,"dataGaLocation":452},"/pricing/premium/","why premium",{"text":481,"config":482},"Why Ultimate?",{"href":483,"dataGaName":484,"dataGaLocation":452},"/pricing/ultimate/","why ultimate",[486],{"title":487,"links":488},"Contact Us",[489,492,494,496,501,506,511],{"text":490,"config":491},"Contact sales",{"href":49,"dataGaName":50,"dataGaLocation":452},{"text":355,"config":493},{"href":357,"dataGaName":358,"dataGaLocation":452},{"text":360,"config":495},{"href":362,"dataGaName":363,"dataGaLocation":452},{"text":497,"config":498},"Status",{"href":499,"dataGaName":500,"dataGaLocation":452},"https://status.gitlab.com/","status",{"text":502,"config":503},"Terms of use",{"href":504,"dataGaName":505,"dataGaLocation":452},"/terms/","terms of use",{"text":507,"config":508},"Privacy statement",{"href":509,"dataGaName":510,"dataGaLocation":452},"/privacy/","privacy statement",{"text":512,"config":513},"Cookie preferences",{"dataGaName":514,"dataGaLocation":452,"id":515,"isOneTrustButton":25},"cookie preferences","ot-sdk-btn",{"title":85,"links":517,"subMenu":526},[518,522],{"text":519,"config":520},"DevSecOps platform",{"href":67,"dataGaName":521,"dataGaLocation":452},"devsecops platform",{"text":523,"config":524},"AI-Assisted Development",{"href":418,"dataGaName":525,"dataGaLocation":452},"ai-assisted development",[527],{"title":528,"links":529},"Topics",[530,535,540,545,550,555,560,565],{"text":531,"config":532},"CICD",{"href":533,"dataGaName":534,"dataGaLocation":452},"/topics/ci-cd/","cicd",{"text":536,"config":537},"GitOps",{"href":538,"dataGaName":539,"dataGaLocation":452},"/topics/gitops/","gitops",{"text":541,"config":542},"DevOps",{"href":543,"dataGaName":544,"dataGaLocation":452},"/topics/devops/","devops",{"text":546,"config":547},"Version Control",{"href":548,"dataGaName":549,"dataGaLocation":452},"/topics/version-control/","version control",{"text":551,"config":552},"DevSecOps",{"href":553,"dataGaName":554,"dataGaLocation":452},"/topics/devsecops/","devsecops",{"text":556,"config":557},"Cloud Native",{"href":558,"dataGaName":559,"dataGaLocation":452},"/topics/cloud-native/","cloud native",{"text":561,"config":562},"AI for Coding",{"href":563,"dataGaName":564,"dataGaLocation":452},"/topics/devops/ai-for-coding/","ai for coding",{"text":566,"config":567},"Agentic AI",{"href":568,"dataGaName":569,"dataGaLocation":452},"/topics/agentic-ai/","agentic ai",{"title":571,"links":572},"Solutions",[573,575,577,582,586,589,593,596,598,601,604,609],{"text":127,"config":574},{"href":122,"dataGaName":127,"dataGaLocation":452},{"text":116,"config":576},{"href":99,"dataGaName":100,"dataGaLocation":452},{"text":578,"config":579},"Agile development",{"href":580,"dataGaName":581,"dataGaLocation":452},"/solutions/agile-delivery/","agile delivery",{"text":583,"config":584},"SCM",{"href":112,"dataGaName":585,"dataGaLocation":452},"source code management",{"text":531,"config":587},{"href":105,"dataGaName":588,"dataGaLocation":452},"continuous integration & delivery",{"text":590,"config":591},"Value stream management",{"href":155,"dataGaName":592,"dataGaLocation":452},"value stream management",{"text":536,"config":594},{"href":595,"dataGaName":539,"dataGaLocation":452},"/solutions/gitops/",{"text":165,"config":597},{"href":167,"dataGaName":168,"dataGaLocation":452},{"text":599,"config":600},"Small business",{"href":172,"dataGaName":173,"dataGaLocation":452},{"text":602,"config":603},"Public sector",{"href":177,"dataGaName":178,"dataGaLocation":452},{"text":605,"config":606},"Education",{"href":607,"dataGaName":608,"dataGaLocation":452},"/solutions/education/","education",{"text":610,"config":611},"Financial services",{"href":612,"dataGaName":613,"dataGaLocation":452},"/solutions/finance/","financial services",{"title":185,"links":615},[616,618,620,622,625,627,629,631,633,635,637,639],{"text":197,"config":617},{"href":199,"dataGaName":200,"dataGaLocation":452},{"text":202,"config":619},{"href":204,"dataGaName":205,"dataGaLocation":452},{"text":207,"config":621},{"href":209,"dataGaName":210,"dataGaLocation":452},{"text":212,"config":623},{"href":214,"dataGaName":624,"dataGaLocation":452},"docs",{"text":235,"config":626},{"href":237,"dataGaName":238,"dataGaLocation":452},{"text":230,"config":628},{"href":232,"dataGaName":233,"dataGaLocation":452},{"text":240,"config":630},{"href":242,"dataGaName":243,"dataGaLocation":452},{"text":248,"config":632},{"href":250,"dataGaName":251,"dataGaLocation":452},{"text":253,"config":634},{"href":255,"dataGaName":256,"dataGaLocation":452},{"text":258,"config":636},{"href":260,"dataGaName":261,"dataGaLocation":452},{"text":263,"config":638},{"href":265,"dataGaName":266,"dataGaLocation":452},{"text":268,"config":640},{"href":270,"dataGaName":271,"dataGaLocation":452},{"title":286,"links":642},[643,645,647,649,651,653,655,659,664,666,668,670],{"text":293,"config":644},{"href":295,"dataGaName":288,"dataGaLocation":452},{"text":298,"config":646},{"href":300,"dataGaName":301,"dataGaLocation":452},{"text":306,"config":648},{"href":308,"dataGaName":309,"dataGaLocation":452},{"text":311,"config":650},{"href":313,"dataGaName":314,"dataGaLocation":452},{"text":316,"config":652},{"href":318,"dataGaName":319,"dataGaLocation":452},{"text":321,"config":654},{"href":323,"dataGaName":324,"dataGaLocation":452},{"text":656,"config":657},"Sustainability",{"href":658,"dataGaName":656,"dataGaLocation":452},"/sustainability/",{"text":660,"config":661},"Diversity, inclusion and belonging (DIB)",{"href":662,"dataGaName":663,"dataGaLocation":452},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":326,"config":665},{"href":328,"dataGaName":329,"dataGaLocation":452},{"text":336,"config":667},{"href":338,"dataGaName":339,"dataGaLocation":452},{"text":341,"config":669},{"href":343,"dataGaName":344,"dataGaLocation":452},{"text":671,"config":672},"Modern Slavery Transparency Statement",{"href":673,"dataGaName":674,"dataGaLocation":452},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":676},[677,680,683],{"text":678,"config":679},"Terms",{"href":504,"dataGaName":505,"dataGaLocation":452},{"text":681,"config":682},"Cookies",{"dataGaName":514,"dataGaLocation":452,"id":515,"isOneTrustButton":25},{"text":684,"config":685},"Privacy",{"href":509,"dataGaName":510,"dataGaLocation":452},[687],{"id":688,"title":18,"body":8,"config":689,"content":691,"description":8,"extension":23,"meta":695,"navigation":25,"path":696,"seo":697,"stem":698,"__hash__":699},"blogAuthors/en-us/blog/authors/chris-moberly.yml",{"template":690},"BlogAuthor",{"name":18,"config":692},{"headshot":693,"ctfId":694},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664235/Blog/Author%20Headshots/cmoberly-headshot.jpg","cmoberly",{},"/en-us/blog/authors/chris-moberly",{},"en-us/blog/authors/chris-moberly","v83w571hHQ-Pp6FRXLR8j4NJ3-1mcNhD7eif5Q962QY",[701,714,729],{"content":702,"config":712},{"title":703,"description":704,"authors":705,"tags":707,"heroImage":709,"category":9,"date":710,"body":711},"A complete guide to GitLab Container Scanning","Explore GitLab's various container scanning methods and learn how to secure containers at every lifecycle stage.",[706],"Fernando Diaz",[9,708],"tutorial","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":713,"featured":25,"template":13},"complete-guide-to-gitlab-container-scanning",{"content":715,"config":727},{"title":716,"description":717,"authors":718,"heroImage":721,"date":722,"body":723,"category":9,"tags":724},"Track vulnerability remediation with the updated GitLab Security Dashboard","Quickly prioritize remediation on high-risk projects and measure progress with vulnerability insights.",[719,720],"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/).",[9,725,726],"product","features",{"featured":12,"template":13,"slug":728},"track-vulnerability-remediation-with-the-updated-gitlab-security-dashboard",{"content":730,"config":740},{"title":731,"description":732,"heroImage":733,"body":734,"date":735,"category":9,"authors":736,"tags":738},"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",[737],"Omid Khan",[9,708,725,739],"google",{"featured":25,"template":13,"slug":741},"how-to-set-up-gitlab-saml-sso-with-google-workspace",{"promotions":743},[744,758,769],{"id":745,"categories":746,"header":748,"text":749,"button":750,"image":755},"ai-modernization",[747],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":751,"config":752},"Get your AI maturity score",{"href":753,"dataGaName":754,"dataGaLocation":238},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":756},{"src":757},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":759,"categories":760,"header":761,"text":749,"button":762,"image":766},"devops-modernization",[725,554],"Are you just managing tools or shipping innovation?",{"text":763,"config":764},"Get your DevOps maturity score",{"href":765,"dataGaName":754,"dataGaLocation":238},"/assessments/devops-modernization-assessment/",{"config":767},{"src":768},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":770,"categories":771,"header":772,"text":749,"button":773,"image":777},"security-modernization",[9],"Are you trading speed for security?",{"text":774,"config":775},"Get your security maturity score",{"href":776,"dataGaName":754,"dataGaLocation":238},"/assessments/security-modernization-assessment/",{"config":778},{"src":779},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":781,"blurb":782,"button":783,"secondaryButton":788},"Start building faster today","See what your team can do with the intelligent orchestration platform for DevSecOps.\n",{"text":784,"config":785},"Get your free trial",{"href":786,"dataGaName":45,"dataGaLocation":787},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":490,"config":789},{"href":49,"dataGaName":50,"dataGaLocation":787},1773350830072]