[{"data":1,"prerenderedAt":797},["ShallowReactive",2],{"/en-us/blog/2025-owasp-top-10-whats-changed-and-why-it-matters":3,"navigation-en-us":33,"banner-en-us":443,"footer-en-us":453,"blog-post-authors-en-us-Fernando Diaz":695,"blog-related-posts-en-us-2025-owasp-top-10-whats-changed-and-why-it-matters":709,"assessment-promotions-en-us":749,"next-steps-en-us":787},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":24,"isFeatured":12,"meta":25,"navigation":26,"path":27,"publishedDate":20,"seo":28,"stem":29,"tagSlugs":30,"__hash__":32},"blogPosts/en-us/blog/2025-owasp-top-10-whats-changed-and-why-it-matters.yml","2025 Owasp Top 10 Whats Changed And Why It Matters",[7],"fernando-diaz",null,"security",{"slug":11,"featured":12,"template":13},"2025-owasp-top-10-whats-changed-and-why-it-matters",false,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"category":9,"tags":21,"body":23},"OWASP Top 10 2025: What's changed and why it matters","Explore new supply chain and error handling risks, ranking shifts, and remediation strategies for all 10 categories.",[18],"Fernando Diaz","https://res.cloudinary.com/about-gitlab-com/image/upload/v1759320418/xjmqcozxzt4frx0hori3.png","2026-01-07",[9,22],"open source","The OWASP Foundation has released the [eighth edition of its influential \"Top 10 Security Risks\" list for 2025](https://owasp.org/Top10/2025/0x00_2025-Introduction/),\nintroducing significant changes that reflect the evolving landscape of application security. Based on analysis\nof more than 175,000 Common Vulnerabilities and Exposures (CVEs) records and feedback from security practitioners across the globe, this update addresses\nmodern attack vectors. Here's everything you need to know about what's changed, why these changes matter,\nand how to protect your systems.\n\n\n> :bulb: Join GitLab Transcend on February 10 to learn how agentic AI transforms software delivery. Hear from customers and discover how to jumpstart your own modernization journey. [Register now.](https://about.gitlab.com/events/transcend/virtual/)\n\n\n## What's new in 2025?\n\nThe shift from 2021 (the last time the list came out) to 2025 represents more than minor adjustments, it's a fundamental shift in application security.\nTwo entirely new categories entered the list and one category was consolidated into another, which highlights emerging risks\nthat traditional testing often misses.\n\nThese additions and shifts can be seen in the chart below:\n\n![OWASP Top 10 - Changes from 2021 to 2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639428/tbekzibeqylorwqrkdau.png)\n\n\n### Two new categories\n\n- **A03: Software Supply Chain Failures**: Expands the 2021 category \"Vulnerable and Outdated Components\" to encompass the entire software supply chain, including dependencies, build systems, and distribution infrastructure. Despite having the fewest occurrences in testing data, this category has the highest average exploit and impact scores from CVEs.\n\n- **A10: Mishandling of Exceptional Conditions**: Focuses on improper error handling, logical errors, and failing open scenarios. This addresses how systems respond to abnormal conditions.\n\n### Major ranking changes\n\n- Security Misconfiguration surged from #5 (2021) to #2 (2025), now affecting 3% of tested applications.\n- Server-Side Request Forgery (SSRF) has been consolidated into A01: Broken Access Control.\n- Cryptographic Failures dropped from #2 to #4.\n- Injection fell from #3 to #5.\n- Insecure Design moved from #4 to #6.\n\n## Why these changes were made\n\nThe OWASP methodology combines data-driven analysis with community insights. The 2025 edition analyzed 589\nCommon Weakness Enumerations (CWEs), which is a substantial increase from the approximately 400 CWEs in 2021.\nThis expansion reflects the growing complexity of modern software systems and the need to capture emerging threats.\n\nThe community survey component addresses a fundamental limitation: testing data essentially looks into the past.\nBy the time security researchers develop testing methodologies and integrate them into automated tools, years may\nhave passed. The two community-voted categories ensure that emerging risks identified by frontline practitioners\nare included, even if they're not yet prevalent in automated testing data.\n\nThe rise of Security Misconfiguration highlights an industry trend toward configuration-based security,\nwhile Software Supply Chain Failures acknowledges the rise of sophisticated attacks targeting compromised packages.\n\n## Using GitLab Ultimate for vulnerability detection and management\n\nGitLab Ultimate provides comprehensive [security scanning](https://docs.gitlab.com/user/application_security/detect/) to detect risks across the\n2025 OWASP Top 10 categories. For instance, the end-to-end platform analyzes your project's source code, dependencies, and infrastructure\ndefinitions. It also uses [Advanced Static Application Security Testing (SAST)](https://docs.gitlab.com/user/application_security/sast/gitlab_advanced_sast/) to detect injection flaws,\ncryptographic failures, and insecure design patterns in source code. [Infrastructure as Code (IaC) scanning](https://docs.gitlab.com/user/application_security/iac_scanning/) finds\nsecurity misconfigurations in your deployment definitions. [Secret Detection](https://docs.gitlab.com/user/application_security/secret_detection/) prevents the leakage of credentials, and\n[Dependency Scanning](https://docs.gitlab.com/user/application_security/dependency_scanning/) uncovers libraries with known vulnerabilities in your software supply chain, which directly\naddresses the new A03 category for Software Supply Chain Failures.\n\nIn addition:\n\n* [Dynamic Application Security Testing (DAST)](https://docs.gitlab.com/user/application_security/dast/) probes your deployed application for broken access control,\nauthentication failures, and injection vulnerabilities by simulating attack vectors.\n* [API Security Testing](https://docs.gitlab.com/user/application_security/api_security/)\nprobes your API endpoints for input validation weaknesses and authentication bypasses.\n* [Web API Fuzz Testing](https://docs.gitlab.com/user/application_security/api_fuzzing/)\nuncovers how your application handles exceptional conditions by generating unexpected inputs, which directly\naddresses the new A10 category for mishandling of exceptional conditions.\n\nSecurity scanning integrates seamlessly into your [CI/CD pipeline](https://about.gitlab.com/topics/ci-cd/), running when code is pushed from a feature\nbranch so developers can remediate vulnerabilities before they reach production. Security findings are consolidated in\nthe [Vulnerability Report](https://docs.gitlab.com/user/application_security/vulnerability_report/), where security\nteams can triage, analyze, and track remediation. GitLab also allows you to leverage AI agents such as [Security Analyst Agent](https://about.gitlab.com/blog/vulnerability-triage-made-simple-with-gitlab-security-analyst-agent/), available in GitLab Duo Agent Platform, to quickly determine what are the most critical vulnerabilities and how to take action on\nthem.\n\nYou can enforce additional controls through [merge request approval policies](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/) and [pipeline execution policies](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/) to ensure security scanning runs consistently across your organization. Customer Success and Professional Services teams at GitLab ensure you derive value from an investment in GitLab in a timely manner.\n\nDeliver secure software faster with security testing in the same platform developers already use.\nTo learn more, visit our [application security testing solutions site](https://about.gitlab.com/solutions/application-security-testing/).\n\n## The OWASP Top 10 2025: Complete breakdown\n\n### A01: Broken Access Control\n\n##### What it is\n\nFailures in enforcing policies that prevent users from acting outside their intended permissions,\nleading to unauthorized access.\n\n##### Impact on your system\n\n- Unauthorized information disclosure\n- Complete data destruction or data modification\n- Privilege escalation (users gaining admin rights)\n- Viewing or editing other users' accounts\n- API access from unauthorized or untrusted sources\n\n##### Notable CWEs\n\n- [CWE-22: Path Traversal](https://cwe.mitre.org/data/definitions/22.html)\n- [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/200.html)\n- [CWE-352: Cross-Site Request Forgery (CSRF)](https://cwe.mitre.org/data/definitions/352.html)\n\n### A02: Security Misconfiguration\n\n##### What it is\n\nSystems, applications, or cloud services configured incorrectly from a security perspective.\n\n##### Impact on your system\n\n- Exposure of sensitive information through error messages\n- Unauthorized access through default accounts\n- Unnecessary services or features enabled\n- Outdated security patches\n- Server does not send security headers or directives\n\n##### Notable CWEs\n\n- [CWE-16: Configuration](https://cwe.mitre.org/data/definitions/16.html)\n- [CWE-521: Weak Password Requirements](https://cwe.mitre.org/data/definitions/521.html)\n- [CWE-798: Use of Hard-coded Credentials](https://cwe.mitre.org/data/definitions/798.html)\n\n### A03: Software Supply Chain Failures\n\n##### What it is\n\nBreakdowns or compromises in building, distributing, or updating software through vulnerabilities or malicious changes in dependencies, tools, or build processes.\n\n##### Impact on your system:\n\n- Compromised packages introducing backdoors\n- Malicious code injected during build processes\n- Vulnerable dependencies cascading through your application\n- Use of components from untrusted sources in production\n- Changes within your supply chain are not tracked\n\n##### Notable CWEs\n\n- [CWE-1395: Dependency on Vulnerable Third-Party Component](https://cwe.mitre.org/data/definitions/1395.html)\n- [CWE-1104: Use of Unmaintained Third Party Components](https://cwe.mitre.org/data/definitions/1104.html)\n\n### A04: Cryptographic Failures\n\n##### What it is\n\nFailures related to lack of cryptography, insufficiently strong cryptography, leaking of cryptographic keys, and related errors.\n\n##### Impact on your system:\n\n- Sensitive data exposure (passwords, credit cards, health records)\n- Man-in-the-middle attacks\n- Data breach through weak encryption\n- Key compromise leading to system-wide exposure\n- Regulatory compliance failures (GDPR, PCI DSS)\n\n##### Notable CWEs\n\n- [CWE-327: Use of a Broken or Risky Cryptographic Algorithm](https://cwe.mitre.org/data/definitions/327.html)\n- [CWE-330: Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330.html)\n\n### A05: Injection\n\n##### What it is\n\nSystem flaws allowing attackers to insert malicious code or commands (SQL, NoSQL, OS commands, LDAP, etc.) into programs.\n\n##### Impact on your system\n\n- Data loss or corruption through SQL injection\n- Complete database compromise\n- Server takeover through command injection\n- Cross-site scripting (XSS) attacks\n- Information disclosure\n- Denial of service\n\n##### Notable CWEs\n\n- [CWE-89: SQL Injection](https://cwe.mitre.org/data/definitions/89.html)\n- [CWE-78: OS Command Injection](https://cwe.mitre.org/data/definitions/78.html)\n\n### A06: Insecure Design\n\n##### What it is\n\nWeaknesses in design representing different failures, expressed as missing or ineffective control design—architectural flaws rather than implementation bugs.\n\n##### Impact on your system\n\n- Weak password reset flows\n- Missing authorization steps\n- Flawed business logic allowing bypasses\n- Inadequate threat modeling leading to blind spots\n- Design patterns that fail under attack scenarios\n\n##### Notable CWEs\n\n- [CWE-209: Generation of Error Messages Containing Sensitive Information](https://cwe.mitre.org/data/definitions/209.html)\n- [CWE-522: Insufficiently Protected Credentials](https://cwe.mitre.org/data/definitions/522.html)\n- [CWE-656: Reliance on Security Through Obscurity](https://cwe.mitre.org/data/definitions/656.html)\n\n### A07: Authentication Failures\n\n##### What it is\n\nVulnerabilities allowing attackers to trick systems into recognizing invalid or incorrect users as legitimate.\n\n##### Impact on your system\n\n- Account takeover and credential stuffing\n- Session hijacking\n- Brute force attacks succeeding\n- Weak password recovery mechanisms exploited\n- Multi-factor authentication bypass\n\n##### Notable CWEs\n\n- [CWE-287: Improper Authentication](https://cwe.mitre.org/data/definitions/287.html)\n- [CWE-306: Missing Authentication for Critical Function](https://cwe.mitre.org/data/definitions/306.html)\n- [CWE-521: Weak Password Requirements](https://cwe.mitre.org/data/definitions/521.html)\n\n### A08: Software or Data Integrity Failures\n\n##### What it is\n\nCode and infrastructure failing to protect against invalid or untrusted code/data being treated as trusted and valid.\n\n##### Impact on your system\n\n- Unsigned updates allowing malicious code injection\n- Insecure deserialization leading to remote code execution\n- CI/CD pipeline compromise\n- Auto-update mechanisms exploited\n- Tampered software artifacts\n\n##### Notable CWEs\n\n- [CWE-345: Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html)\n- [CWE-346: Origin Validation Error](https://cwe.mitre.org/data/definitions/346.html)\n- [CWE-347: Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html)\n\n### A09: Security Logging & Alerting Failures\n\n##### What it is\n\nInsufficient logging and monitoring with inadequate alerting, which makes rapid response difficult.\n\n##### Impact on your system\n\n- Attacks go undetected for extended periods\n- Breach investigation becomes impossible\n- Compliance violations from lack of audit trails\n- Delayed incident response\n- Inability to determine scope of compromise\n\n##### Notable CWEs\n\n- [CWE-117: Improper Output Neutralization for Logs](https://cwe.mitre.org/data/definitions/117.html)\n- [CWE-532: Insertion of Sensitive Information into Log File](https://cwe.mitre.org/data/definitions/532.html)\n- [CWE-778: Insufficient Logging](https://cwe.mitre.org/data/definitions/778.html)\n\n### A10: Mishandling of Exceptional Conditions\n\n##### What it is\n\nPrograms failing to prevent, detect, and respond to unusual and unpredictable situations, which leads to crashes, unexpected behavior, or vulnerabilities.\n\n##### Impact on your system\n\n- Information disclosure through verbose error messages\n- Denial of service from unhandled exceptions\n- State corruption from improper error handling\n- Race conditions exploited\n- Systems failing open instead of closed\n- Application crashes exposing sensitive data\n\n##### Notable CWEs\n\n- [CWE-248: Uncaught Exception](https://cwe.mitre.org/data/definitions/248.html)\n- [CWE-390: Detection of Error Condition Without Action](https://cwe.mitre.org/data/definitions/390.html)\n- [CWE-391: Unchecked Error Condition](https://cwe.mitre.org/data/definitions/391.html)\n\n## Prevention and remediation best practices\n\nGitLab provides tools to enable you to not only quickly find and remediate vulnerabilities within the OWASP Top 10,\nbut also to prevent them from making it into your production system. By following these best practices you can enhance\nand maintain your security posture:\n\n#### Automated security scanning for all repositories\n\n- Perform [SAST Scanning](https://docs.gitlab.com/user/application_security/sast/) to detect insecure design patterns like plaintext password storage, inadequate error handling, and missing encryption during code review, catching design flaws early in the development lifecycle.\n- Perform [Secret Detection](https://docs.gitlab.com/user/application_security/secret_detection/) to identify credentials in configuration files, environment variables, and code, preventing plaintext password storage and ensuring secrets are properly managed through GitLab's CI/CD variables with masking and encryption.\n- Perform [DAST Scanning](https://docs.gitlab.com/user/application_security/dast/) to detect broken access control vulnerabilities\n- Perform [Dependency Scanning](https://docs.gitlab.com/user/application_security/dependency_scanning/) to scan project dependencies against vulnerability databases, identifying known CVEs in direct and transitive dependencies across multiple package managers (npm, pip, Maven, etc.).\n- Perform [Container Scanning](https://docs.gitlab.com/user/application_security/container_scanning/) to analyze Docker images for vulnerable base layers and packages, ensuring container supply chain security before deployment.\n- Perform [IaC Scanning](https://docs.gitlab.com/user/application_security/iac_scanning/) to check your infrastructure definition files for known vulnerabilities.\n- Leverage [API Security Tools](https://docs.gitlab.com/user/application_security/api_security/) to secure and protect web APIs from unauthorized access, misuse, and attacks.\n- Perform [Web API Fuzz Testing](https://docs.gitlab.com/user/application_security/api_fuzzing/) to discover bugs and potential vulnerabilities that other QA processes might miss.\n\n![Security Results in MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639431/zs6xh8hz6mud3vuig3dy.png)\n\u003Cp>\u003C/p>\n\u003Ccenter>\u003Ci>View vulnerabilities detected in MR with diff from feature branch to main branch.\u003C/i>\u003C/center>\n\n#### Understand your security posture\n\n- Generate a [software bill of materials (SBOM)](https://docs.gitlab.com/user/application_security/dependency_list/) for complete dependency visibility and compliance requirements.\n- Leverage the [Vulnerability Report](https://docs.gitlab.com/user/application_security/vulnerability_report/) to sort through and triage vulnerabilites via consolidated view of security vulnerabilities found in your codebase.\n- Quickly take action on vulnerabilities using [detailed remdiation guidance](https://docs.gitlab.com/user/application_security/vulnerabilities/) and [risk assessment data](https://docs.gitlab.com/user/application_security/vulnerabilities/risk_assessment_data/).\n- Use [Security Iventory](https://docs.gitlab.com/user/application_security/security_inventory/) to visualize which assets you need to secure and understand the actions you need to take to improve security.\n- Leverage [Compliance Center](https://docs.gitlab.com/user/compliance/compliance_center/) to manage compliance standards adherence reporting, violations reporting, and compliance frameworks.\n\n![Security Inventory](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639429/e9vnakc8yiyjbjm8aj7s.png)\n\u003Cp>\u003C/p>\n\u003Ccenter>\u003Ci>Use Security Inventory to viewing enabled security scanners and vulnerabilities.\u003C/i>\u003C/center>\n\n#### Set up prevention and maintain documentation\n\n- Configure [Security Policies](https://docs.gitlab.com/user/application_security/policies/) to block merges or deployments when high-severity vulnerabilities are detected in dependencies, enforcing security standards automatically.\n- Use [Compliance Frameworks](https://docs.gitlab.com/user/compliance/compliance_frameworks/) to enforce organizational security standards through automated policy checks that verify encryption requirements, credential management practices, and secure workflow implementations are followed.\n- Use GitLab Wiki and repository documentation to maintain security design principles, approved patterns, and architectural decision records that guide developers toward [secure-by-design implementations](https://about.gitlab.com/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/).\n- Implement merge request approval rules requiring security architect review for features involving authentication, authorization, encryption, or sensitive data handling, ensuring design-level security validation.\n- Create tests to verify input validation and allowlist approaches for file paths\n- Use GitLab Issues and Epics to document security requirements and threat models during the design phase, creating a traceable record of security decisions and ensuring security considerations are addressed before implementation begins.\n\n![Security Policy Dashboard](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639429/q4eelq3rqt0oonzhwoyb.png)\n\u003Ccenter>\u003Ci>View and set Security Policies scoped to instance, group, or project.\u003C/i>\u003C/center>\n\n#### Leverage AI\n\n- Use [Code Suggestions](https://docs.gitlab.com/user/project/repository/code_suggestions/) for proactive guidance during development, suggesting secure design patterns like proper password hashing (bcrypt, Argon2), encrypted storage mechanisms, and appropriate error handling that doesn't leak sensitive information.\n- Use [Security Analyst Agent](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/) to review detected insecure design vulnerabilities in context, explaining the architectural implications, assessing risk based on your application's threat model, and providing remediation strategies that address root design flaws rather than just symptoms.\n- [Review your code using AI](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code) to help ensure consistent code review standards in your project.\n\n![GitLab Security Analyst Agent](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639430/kqvgagepwleabt5zdkco.png)\n\u003Cp>\u003C/p>\n\u003Ccenter>\u003Ci>Leverage Security Analyst Agent to quickly triage and assess security vulnerabilities.\u003C/i>\u003C/center>\n\n## Key takeaways for development teams\n\n- **Supply chain security is critical**: With A03's addition and high-impact scores, securing your software supply chain is no longer optional. Implement SBOM tracking, dependency scanning, and integrity verification throughout your pipeline.\n- **Configuration matters more than ever**: The rise to #2 shows that configuration-based security is now a primary attack vector. Automate configuration verification and implement IaC with security baked in.\n- **Traditional threats persist**: While Injection and Cryptographic Failures dropped in ranking, they remain critical. Don't deprioritize them just because they've fallen on the list.\n- **Error handling is security**: The new A10 category emphasizes that how your application handles failures is a security concern. Implement secure error handling from the start.\n- **Testing must evolve**: The expanded CWE coverage (589 vs. 400 in 2021) means testing strategies must be comprehensive. Combine SAST, DAST, source code analysis, and manual penetration testing for effective coverage.\n\n> Explore our [GitLab Security and Governance Solutions](https://about.gitlab.com/solutions/application-security-testing/) and\n[security scanning documentation](https://docs.gitlab.com/ee/user/application_security/) to start strengthening your\nsecurity posture today.\n","yml",{},true,"/en-us/blog/2025-owasp-top-10-whats-changed-and-why-it-matters",{"title":15,"description":16},"en-us/blog/2025-owasp-top-10-whats-changed-and-why-it-matters",[9,31],"open-source","62oHGgJqMPLyaV5gnp9D85dq1Q_AEP2V_aUthkci4ZE",{"data":34},{"logo":35,"freeTrial":40,"sales":45,"login":50,"items":55,"search":363,"minimal":394,"duo":413,"switchNav":422,"pricingDeployment":433},{"config":36},{"href":37,"dataGaName":38,"dataGaLocation":39},"/","gitlab logo","header",{"text":41,"config":42},"Get free trial",{"href":43,"dataGaName":44,"dataGaLocation":39},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":46,"config":47},"Talk to sales",{"href":48,"dataGaName":49,"dataGaLocation":39},"/sales/","sales",{"text":51,"config":52},"Sign in",{"href":53,"dataGaName":54,"dataGaLocation":39},"https://gitlab.com/users/sign_in/","sign in",[56,83,178,183,284,344],{"text":57,"config":58,"cards":60},"Platform",{"dataNavLevelOne":59},"platform",[61,67,75],{"title":57,"description":62,"link":63},"The intelligent orchestration platform for DevSecOps",{"text":64,"config":65},"Explore our Platform",{"href":66,"dataGaName":59,"dataGaLocation":39},"/platform/",{"title":68,"description":69,"link":70},"GitLab Duo Agent Platform","Agentic AI for the entire software lifecycle",{"text":71,"config":72},"Meet GitLab Duo",{"href":73,"dataGaName":74,"dataGaLocation":39},"/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":76,"description":77,"link":78},"Why GitLab","See the top reasons enterprises choose GitLab",{"text":79,"config":80},"Learn more",{"href":81,"dataGaName":82,"dataGaLocation":39},"/why-gitlab/","why gitlab",{"text":84,"left":26,"config":85,"link":87,"lists":91,"footer":160},"Product",{"dataNavLevelOne":86},"solutions",{"text":88,"config":89},"View all Solutions",{"href":90,"dataGaName":86,"dataGaLocation":39},"/solutions/",[92,116,139],{"title":93,"description":94,"link":95,"items":100},"Automation","CI/CD and automation to accelerate deployment",{"config":96},{"icon":97,"href":98,"dataGaName":99,"dataGaLocation":39},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[101,105,108,112],{"text":102,"config":103},"CI/CD",{"href":104,"dataGaLocation":39,"dataGaName":102},"/solutions/continuous-integration/",{"text":68,"config":106},{"href":73,"dataGaLocation":39,"dataGaName":107},"gitlab duo agent platform - product menu",{"text":109,"config":110},"Source Code Management",{"href":111,"dataGaLocation":39,"dataGaName":109},"/solutions/source-code-management/",{"text":113,"config":114},"Automated Software Delivery",{"href":98,"dataGaLocation":39,"dataGaName":115},"Automated software delivery",{"title":117,"description":118,"link":119,"items":124},"Security","Deliver code faster without compromising security",{"config":120},{"href":121,"dataGaName":122,"dataGaLocation":39,"icon":123},"/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[125,129,134],{"text":126,"config":127},"Application Security Testing",{"href":121,"dataGaName":128,"dataGaLocation":39},"Application security testing",{"text":130,"config":131},"Software Supply Chain Security",{"href":132,"dataGaLocation":39,"dataGaName":133},"/solutions/supply-chain/","Software supply chain security",{"text":135,"config":136},"Software Compliance",{"href":137,"dataGaName":138,"dataGaLocation":39},"/solutions/software-compliance/","software compliance",{"title":140,"link":141,"items":146},"Measurement",{"config":142},{"icon":143,"href":144,"dataGaName":145,"dataGaLocation":39},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[147,151,155],{"text":148,"config":149},"Visibility & Measurement",{"href":144,"dataGaLocation":39,"dataGaName":150},"Visibility and Measurement",{"text":152,"config":153},"Value Stream Management",{"href":154,"dataGaLocation":39,"dataGaName":152},"/solutions/value-stream-management/",{"text":156,"config":157},"Analytics & Insights",{"href":158,"dataGaLocation":39,"dataGaName":159},"/solutions/analytics-and-insights/","Analytics and insights",{"title":161,"items":162},"GitLab for",[163,168,173],{"text":164,"config":165},"Enterprise",{"href":166,"dataGaLocation":39,"dataGaName":167},"/enterprise/","enterprise",{"text":169,"config":170},"Small Business",{"href":171,"dataGaLocation":39,"dataGaName":172},"/small-business/","small business",{"text":174,"config":175},"Public Sector",{"href":176,"dataGaLocation":39,"dataGaName":177},"/solutions/public-sector/","public sector",{"text":179,"config":180},"Pricing",{"href":181,"dataGaName":182,"dataGaLocation":39,"dataNavLevelOne":182},"/pricing/","pricing",{"text":184,"config":185,"link":187,"lists":191,"feature":271},"Resources",{"dataNavLevelOne":186},"resources",{"text":188,"config":189},"View all resources",{"href":190,"dataGaName":186,"dataGaLocation":39},"/resources/",[192,225,243],{"title":193,"items":194},"Getting started",[195,200,205,210,215,220],{"text":196,"config":197},"Install",{"href":198,"dataGaName":199,"dataGaLocation":39},"/install/","install",{"text":201,"config":202},"Quick start guides",{"href":203,"dataGaName":204,"dataGaLocation":39},"/get-started/","quick setup checklists",{"text":206,"config":207},"Learn",{"href":208,"dataGaLocation":39,"dataGaName":209},"https://university.gitlab.com/","learn",{"text":211,"config":212},"Product documentation",{"href":213,"dataGaName":214,"dataGaLocation":39},"https://docs.gitlab.com/","product documentation",{"text":216,"config":217},"Best practice videos",{"href":218,"dataGaName":219,"dataGaLocation":39},"/getting-started-videos/","best practice videos",{"text":221,"config":222},"Integrations",{"href":223,"dataGaName":224,"dataGaLocation":39},"/integrations/","integrations",{"title":226,"items":227},"Discover",[228,233,238],{"text":229,"config":230},"Customer success stories",{"href":231,"dataGaName":232,"dataGaLocation":39},"/customers/","customer success stories",{"text":234,"config":235},"Blog",{"href":236,"dataGaName":237,"dataGaLocation":39},"/blog/","blog",{"text":239,"config":240},"Remote",{"href":241,"dataGaName":242,"dataGaLocation":39},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":244,"items":245},"Connect",[246,251,256,261,266],{"text":247,"config":248},"GitLab Services",{"href":249,"dataGaName":250,"dataGaLocation":39},"/services/","services",{"text":252,"config":253},"Community",{"href":254,"dataGaName":255,"dataGaLocation":39},"/community/","community",{"text":257,"config":258},"Forum",{"href":259,"dataGaName":260,"dataGaLocation":39},"https://forum.gitlab.com/","forum",{"text":262,"config":263},"Events",{"href":264,"dataGaName":265,"dataGaLocation":39},"/events/","events",{"text":267,"config":268},"Partners",{"href":269,"dataGaName":270,"dataGaLocation":39},"/partners/","partners",{"backgroundColor":272,"textColor":273,"text":274,"image":275,"link":279},"#2f2a6b","#fff","Insights for the future of software development",{"altText":276,"config":277},"the source promo card",{"src":278},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":280,"config":281},"Read the latest",{"href":282,"dataGaName":283,"dataGaLocation":39},"/the-source/","the source",{"text":285,"config":286,"lists":288},"Company",{"dataNavLevelOne":287},"company",[289],{"items":290},[291,296,302,304,309,314,319,324,329,334,339],{"text":292,"config":293},"About",{"href":294,"dataGaName":295,"dataGaLocation":39},"/company/","about",{"text":297,"config":298,"footerGa":301},"Jobs",{"href":299,"dataGaName":300,"dataGaLocation":39},"/jobs/","jobs",{"dataGaName":300},{"text":262,"config":303},{"href":264,"dataGaName":265,"dataGaLocation":39},{"text":305,"config":306},"Leadership",{"href":307,"dataGaName":308,"dataGaLocation":39},"/company/team/e-group/","leadership",{"text":310,"config":311},"Team",{"href":312,"dataGaName":313,"dataGaLocation":39},"/company/team/","team",{"text":315,"config":316},"Handbook",{"href":317,"dataGaName":318,"dataGaLocation":39},"https://handbook.gitlab.com/","handbook",{"text":320,"config":321},"Investor relations",{"href":322,"dataGaName":323,"dataGaLocation":39},"https://ir.gitlab.com/","investor relations",{"text":325,"config":326},"Trust Center",{"href":327,"dataGaName":328,"dataGaLocation":39},"/security/","trust center",{"text":330,"config":331},"AI Transparency Center",{"href":332,"dataGaName":333,"dataGaLocation":39},"/ai-transparency-center/","ai transparency center",{"text":335,"config":336},"Newsletter",{"href":337,"dataGaName":338,"dataGaLocation":39},"/company/contact/#contact-forms","newsletter",{"text":340,"config":341},"Press",{"href":342,"dataGaName":343,"dataGaLocation":39},"/press/","press",{"text":345,"config":346,"lists":347},"Contact us",{"dataNavLevelOne":287},[348],{"items":349},[350,353,358],{"text":46,"config":351},{"href":48,"dataGaName":352,"dataGaLocation":39},"talk to sales",{"text":354,"config":355},"Support portal",{"href":356,"dataGaName":357,"dataGaLocation":39},"https://support.gitlab.com","support portal",{"text":359,"config":360},"Customer portal",{"href":361,"dataGaName":362,"dataGaLocation":39},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":364,"login":365,"suggestions":372},"Close",{"text":366,"link":367},"To search repositories and projects, login to",{"text":368,"config":369},"gitlab.com",{"href":53,"dataGaName":370,"dataGaLocation":371},"search login","search",{"text":373,"default":374},"Suggestions",[375,377,381,383,387,391],{"text":68,"config":376},{"href":73,"dataGaName":68,"dataGaLocation":371},{"text":378,"config":379},"Code Suggestions (AI)",{"href":380,"dataGaName":378,"dataGaLocation":371},"/solutions/code-suggestions/",{"text":102,"config":382},{"href":104,"dataGaName":102,"dataGaLocation":371},{"text":384,"config":385},"GitLab on AWS",{"href":386,"dataGaName":384,"dataGaLocation":371},"/partners/technology-partners/aws/",{"text":388,"config":389},"GitLab on Google Cloud",{"href":390,"dataGaName":388,"dataGaLocation":371},"/partners/technology-partners/google-cloud-platform/",{"text":392,"config":393},"Why GitLab?",{"href":81,"dataGaName":392,"dataGaLocation":371},{"freeTrial":395,"mobileIcon":400,"desktopIcon":405,"secondaryButton":408},{"text":396,"config":397},"Start free trial",{"href":398,"dataGaName":44,"dataGaLocation":399},"https://gitlab.com/-/trials/new/","nav",{"altText":401,"config":402},"Gitlab Icon",{"src":403,"dataGaName":404,"dataGaLocation":399},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":401,"config":406},{"src":407,"dataGaName":404,"dataGaLocation":399},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":409,"config":410},"Get Started",{"href":411,"dataGaName":412,"dataGaLocation":399},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/get-started/","get started",{"freeTrial":414,"mobileIcon":418,"desktopIcon":420},{"text":415,"config":416},"Learn more about GitLab Duo",{"href":73,"dataGaName":417,"dataGaLocation":399},"gitlab duo",{"altText":401,"config":419},{"src":403,"dataGaName":404,"dataGaLocation":399},{"altText":401,"config":421},{"src":407,"dataGaName":404,"dataGaLocation":399},{"button":423,"mobileIcon":428,"desktopIcon":430},{"text":424,"config":425},"/switch",{"href":426,"dataGaName":427,"dataGaLocation":399},"#contact","switch",{"altText":401,"config":429},{"src":403,"dataGaName":404,"dataGaLocation":399},{"altText":401,"config":431},{"src":432,"dataGaName":404,"dataGaLocation":399},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":434,"mobileIcon":439,"desktopIcon":441},{"text":435,"config":436},"Back to pricing",{"href":181,"dataGaName":437,"dataGaLocation":399,"icon":438},"back to pricing","GoBack",{"altText":401,"config":440},{"src":403,"dataGaName":404,"dataGaLocation":399},{"altText":401,"config":442},{"src":407,"dataGaName":404,"dataGaLocation":399},{"title":444,"button":445,"config":450},"See how agentic AI transforms software delivery",{"text":446,"config":447},"Watch GitLab Transcend now",{"href":448,"dataGaName":449,"dataGaLocation":39},"/events/transcend/virtual/","transcend event",{"layout":451,"icon":452,"disabled":26},"release","AiStar",{"data":454},{"text":455,"source":456,"edit":462,"contribute":467,"config":472,"items":477,"minimal":684},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":457,"config":458},"View page source",{"href":459,"dataGaName":460,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":463,"config":464},"Edit this page",{"href":465,"dataGaName":466,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":468,"config":469},"Please contribute",{"href":470,"dataGaName":471,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":473,"facebook":474,"youtube":475,"linkedin":476},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[478,525,579,623,650],{"title":179,"links":479,"subMenu":494},[480,484,489],{"text":481,"config":482},"View plans",{"href":181,"dataGaName":483,"dataGaLocation":461},"view plans",{"text":485,"config":486},"Why Premium?",{"href":487,"dataGaName":488,"dataGaLocation":461},"/pricing/premium/","why premium",{"text":490,"config":491},"Why Ultimate?",{"href":492,"dataGaName":493,"dataGaLocation":461},"/pricing/ultimate/","why ultimate",[495],{"title":496,"links":497},"Contact Us",[498,501,503,505,510,515,520],{"text":499,"config":500},"Contact sales",{"href":48,"dataGaName":49,"dataGaLocation":461},{"text":354,"config":502},{"href":356,"dataGaName":357,"dataGaLocation":461},{"text":359,"config":504},{"href":361,"dataGaName":362,"dataGaLocation":461},{"text":506,"config":507},"Status",{"href":508,"dataGaName":509,"dataGaLocation":461},"https://status.gitlab.com/","status",{"text":511,"config":512},"Terms of use",{"href":513,"dataGaName":514,"dataGaLocation":461},"/terms/","terms of use",{"text":516,"config":517},"Privacy statement",{"href":518,"dataGaName":519,"dataGaLocation":461},"/privacy/","privacy statement",{"text":521,"config":522},"Cookie preferences",{"dataGaName":523,"dataGaLocation":461,"id":524,"isOneTrustButton":26},"cookie preferences","ot-sdk-btn",{"title":84,"links":526,"subMenu":535},[527,531],{"text":528,"config":529},"DevSecOps platform",{"href":66,"dataGaName":530,"dataGaLocation":461},"devsecops platform",{"text":532,"config":533},"AI-Assisted Development",{"href":73,"dataGaName":534,"dataGaLocation":461},"ai-assisted development",[536],{"title":537,"links":538},"Topics",[539,544,549,554,559,564,569,574],{"text":540,"config":541},"CICD",{"href":542,"dataGaName":543,"dataGaLocation":461},"/topics/ci-cd/","cicd",{"text":545,"config":546},"GitOps",{"href":547,"dataGaName":548,"dataGaLocation":461},"/topics/gitops/","gitops",{"text":550,"config":551},"DevOps",{"href":552,"dataGaName":553,"dataGaLocation":461},"/topics/devops/","devops",{"text":555,"config":556},"Version Control",{"href":557,"dataGaName":558,"dataGaLocation":461},"/topics/version-control/","version control",{"text":560,"config":561},"DevSecOps",{"href":562,"dataGaName":563,"dataGaLocation":461},"/topics/devsecops/","devsecops",{"text":565,"config":566},"Cloud Native",{"href":567,"dataGaName":568,"dataGaLocation":461},"/topics/cloud-native/","cloud native",{"text":570,"config":571},"AI for Coding",{"href":572,"dataGaName":573,"dataGaLocation":461},"/topics/devops/ai-for-coding/","ai for coding",{"text":575,"config":576},"Agentic AI",{"href":577,"dataGaName":578,"dataGaLocation":461},"/topics/agentic-ai/","agentic ai",{"title":580,"links":581},"Solutions",[582,584,586,591,595,598,602,605,607,610,613,618],{"text":126,"config":583},{"href":121,"dataGaName":126,"dataGaLocation":461},{"text":115,"config":585},{"href":98,"dataGaName":99,"dataGaLocation":461},{"text":587,"config":588},"Agile development",{"href":589,"dataGaName":590,"dataGaLocation":461},"/solutions/agile-delivery/","agile delivery",{"text":592,"config":593},"SCM",{"href":111,"dataGaName":594,"dataGaLocation":461},"source code management",{"text":540,"config":596},{"href":104,"dataGaName":597,"dataGaLocation":461},"continuous integration & delivery",{"text":599,"config":600},"Value stream management",{"href":154,"dataGaName":601,"dataGaLocation":461},"value stream management",{"text":545,"config":603},{"href":604,"dataGaName":548,"dataGaLocation":461},"/solutions/gitops/",{"text":164,"config":606},{"href":166,"dataGaName":167,"dataGaLocation":461},{"text":608,"config":609},"Small business",{"href":171,"dataGaName":172,"dataGaLocation":461},{"text":611,"config":612},"Public sector",{"href":176,"dataGaName":177,"dataGaLocation":461},{"text":614,"config":615},"Education",{"href":616,"dataGaName":617,"dataGaLocation":461},"/solutions/education/","education",{"text":619,"config":620},"Financial services",{"href":621,"dataGaName":622,"dataGaLocation":461},"/solutions/finance/","financial services",{"title":184,"links":624},[625,627,629,631,634,636,638,640,642,644,646,648],{"text":196,"config":626},{"href":198,"dataGaName":199,"dataGaLocation":461},{"text":201,"config":628},{"href":203,"dataGaName":204,"dataGaLocation":461},{"text":206,"config":630},{"href":208,"dataGaName":209,"dataGaLocation":461},{"text":211,"config":632},{"href":213,"dataGaName":633,"dataGaLocation":461},"docs",{"text":234,"config":635},{"href":236,"dataGaName":237,"dataGaLocation":461},{"text":229,"config":637},{"href":231,"dataGaName":232,"dataGaLocation":461},{"text":239,"config":639},{"href":241,"dataGaName":242,"dataGaLocation":461},{"text":247,"config":641},{"href":249,"dataGaName":250,"dataGaLocation":461},{"text":252,"config":643},{"href":254,"dataGaName":255,"dataGaLocation":461},{"text":257,"config":645},{"href":259,"dataGaName":260,"dataGaLocation":461},{"text":262,"config":647},{"href":264,"dataGaName":265,"dataGaLocation":461},{"text":267,"config":649},{"href":269,"dataGaName":270,"dataGaLocation":461},{"title":285,"links":651},[652,654,656,658,660,662,664,668,673,675,677,679],{"text":292,"config":653},{"href":294,"dataGaName":287,"dataGaLocation":461},{"text":297,"config":655},{"href":299,"dataGaName":300,"dataGaLocation":461},{"text":305,"config":657},{"href":307,"dataGaName":308,"dataGaLocation":461},{"text":310,"config":659},{"href":312,"dataGaName":313,"dataGaLocation":461},{"text":315,"config":661},{"href":317,"dataGaName":318,"dataGaLocation":461},{"text":320,"config":663},{"href":322,"dataGaName":323,"dataGaLocation":461},{"text":665,"config":666},"Sustainability",{"href":667,"dataGaName":665,"dataGaLocation":461},"/sustainability/",{"text":669,"config":670},"Diversity, inclusion and belonging (DIB)",{"href":671,"dataGaName":672,"dataGaLocation":461},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":325,"config":674},{"href":327,"dataGaName":328,"dataGaLocation":461},{"text":335,"config":676},{"href":337,"dataGaName":338,"dataGaLocation":461},{"text":340,"config":678},{"href":342,"dataGaName":343,"dataGaLocation":461},{"text":680,"config":681},"Modern Slavery Transparency Statement",{"href":682,"dataGaName":683,"dataGaLocation":461},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":685},[686,689,692],{"text":687,"config":688},"Terms",{"href":513,"dataGaName":514,"dataGaLocation":461},{"text":690,"config":691},"Cookies",{"dataGaName":523,"dataGaLocation":461,"id":524,"isOneTrustButton":26},{"text":693,"config":694},"Privacy",{"href":518,"dataGaName":519,"dataGaLocation":461},[696],{"id":697,"title":18,"body":8,"config":698,"content":700,"description":8,"extension":24,"meta":704,"navigation":26,"path":705,"seo":706,"stem":707,"__hash__":708},"blogAuthors/en-us/blog/authors/fernando-diaz.yml",{"template":699},"BlogAuthor",{"name":18,"config":701},{"headshot":702,"ctfId":703},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659556/Blog/Author%20Headshots/fern_diaz.png","fjdiaz",{},"/en-us/blog/authors/fernando-diaz",{},"en-us/blog/authors/fernando-diaz","lxRJIOydP4_yzYZvsPcuQevP9AYAKREF7i8QmmdnOWc",[710,722,737],{"content":711,"config":720},{"title":712,"description":713,"authors":714,"tags":715,"heroImage":717,"category":9,"date":718,"body":719},"A complete guide to GitLab Container Scanning","Explore GitLab's various container scanning methods and learn how to secure containers at every lifecycle stage.",[18],[9,716],"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":721,"featured":26,"template":13},"complete-guide-to-gitlab-container-scanning",{"content":723,"config":735},{"title":724,"description":725,"authors":726,"heroImage":729,"date":730,"body":731,"category":9,"tags":732},"Track vulnerability remediation with the updated GitLab Security Dashboard","Quickly prioritize remediation on high-risk projects and measure progress with vulnerability insights.",[727,728],"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,733,734],"product","features",{"featured":12,"template":13,"slug":736},"track-vulnerability-remediation-with-the-updated-gitlab-security-dashboard",{"content":738,"config":747},{"title":739,"description":740,"heroImage":19,"body":741,"date":742,"category":9,"authors":743,"tags":745},"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.","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",[744],"Omid Khan",[9,716,733,746],"google",{"featured":26,"template":13,"slug":748},"how-to-set-up-gitlab-saml-sso-with-google-workspace",{"promotions":750},[751,765,776],{"id":752,"categories":753,"header":755,"text":756,"button":757,"image":762},"ai-modernization",[754],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":758,"config":759},"Get your AI maturity score",{"href":760,"dataGaName":761,"dataGaLocation":237},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":763},{"src":764},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":766,"categories":767,"header":768,"text":756,"button":769,"image":773},"devops-modernization",[733,563],"Are you just managing tools or shipping innovation?",{"text":770,"config":771},"Get your DevOps maturity score",{"href":772,"dataGaName":761,"dataGaLocation":237},"/assessments/devops-modernization-assessment/",{"config":774},{"src":775},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":777,"categories":778,"header":779,"text":756,"button":780,"image":784},"security-modernization",[9],"Are you trading speed for security?",{"text":781,"config":782},"Get your security maturity score",{"href":783,"dataGaName":761,"dataGaLocation":237},"/assessments/security-modernization-assessment/",{"config":785},{"src":786},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":788,"blurb":789,"button":790,"secondaryButton":795},"Start building faster today","See what your team can do with the intelligent orchestration platform for DevSecOps.\n",{"text":791,"config":792},"Get your free trial",{"href":793,"dataGaName":44,"dataGaLocation":794},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":499,"config":796},{"href":48,"dataGaName":49,"dataGaLocation":794},1773871192594]