[{"data":1,"prerenderedAt":765},["ShallowReactive",2],{"/de-de/blog/a-guide-to-the-breaking-changes-in-gitlab-19-0":3,"navigation-de-de":33,"banner-de-de":436,"footer-de-de":446,"blog-post-authors-de-de-Martin Brümmer":651,"blog-related-posts-de-de-a-guide-to-the-breaking-changes-in-gitlab-19-0":666,"blog-promotions-de-de":702,"next-steps-de-de":755},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":24,"isFeatured":11,"meta":25,"navigation":26,"path":27,"publishedDate":15,"seo":28,"stem":30,"tagSlugs":31,"__hash__":32},"blogPosts/de-de/blog/a-guide-to-the-breaking-changes-in-gitlab-19-0.yml","A Guide To The Breaking Changes In Gitlab 19 0",[7],"martin-brmmer",null,"product",{"featured":11,"template":12,"slug":13},false,"BlogPost","a-guide-to-the-breaking-changes-in-gitlab-19-0",{"date":15,"body":16,"category":9,"tags":17,"authors":19,"title":21,"description":22,"heroImage":23},"2026-04-15","GitLab 17.0 enthielt 80 Breaking Changes – also inkompatible Änderungen, die beim Upgrade manuellen Anpassungsbedarf erzeugen. GitLab 18.0 hatte 27. Das bevorstehende Release GitLab 19.0 wird voraussichtlich 15 enthalten.\n\nWir wissen, dass die Verwaltung von Breaking Changes bei einem Major-Upgrade aufwändig ist: Es erfordert Analyse und Koordination im gesamten Unternehmen. Als Reaktion darauf haben wir eine [Genehmigungspflicht für Breaking Changes](https://docs.gitlab.com/development/deprecation_guidelines/#how-do-i-get-approval-to-move-forward-with-a-breaking-change) eingeführt, die eine Folgenabschätzung und die Freigabe durch die Führungsebene vorschreibt, bevor ein Breaking Change umgesetzt werden kann. Dieser Prozess zeigt Wirkung, und wir sind entschlossen, die Zahl weiter zu senken.\n\nIm Folgenden sind alle Breaking Changes in GitLab 19.0 aufgeführt, geordnet nach Deployment-Typ und Auswirkung, zusammen mit den Migrationsschritten für ein reibungsloses Upgrade.\n\n\n## Deployment-Fenster\n\n\nFolgende Deployment-Fenster sind relevant.\n\n### GitLab.com\n\nInkompatible Änderungen für GitLab.com sind auf diese zwei Fenster begrenzt:\n\n- **4.–6. Mai 2026** (09:00–22:00 UTC) — primäres Fenster\n- **11.–13. Mai 2026** (09:00–22:00 UTC) — Ausweichfenster\n\nViele weitere Änderungen werden im Laufe des Monats ausgerollt. Mehr zu den Breaking Changes innerhalb dieser Fenster in der [Dokumentation zu Breaking-Change-Fenstern](https://docs.gitlab.com/update/breaking_windows/).\n\n**Hinweis:** In Ausnahmefällen können Breaking Changes geringfügig außerhalb dieser Fenster fallen.\n\n### GitLab Self-Managed\n\nGitLab 19.0 wird ab dem 21. Mai 2026 verfügbar sein.\n\n> Mehr zum [Release-Zeitplan](https://about.gitlab.com/releases/).\n\n### GitLab Dedicated\n\nDas Upgrade auf GitLab 19.0 findet im zugewiesenen Wartungsfenster statt. Das Wartungsfenster ist im Switchboard-Portal einsehbar. GitLab Dedicated-Instanzen werden auf Release N-1 gehalten, das Upgrade auf GitLab 19.0 erfolgt daher im Wartungsfenster in der Woche ab dem 22. Juni 2026.\n\nAuf der [Deprecations-Seite](https://docs.gitlab.com/update/deprecations/?removal_milestone=19.0&breaking_only=true) ist die vollständige Liste der für GitLab 19.0 geplanten Entfernungen zu finden. Im Folgenden wird erläutert, was kommt und wie man sich je nach Deployment darauf vorbereitet.\n\n\n## Breaking Changes\n\n\nFolgende Breaking Changes haben hohe Auswirkungen.\n\n### Hohe Auswirkung\n\n**1. NGINX Ingress-Unterstützung durch Gateway API mit Envoy Gateway ersetzt**\n\n_GitLab Self-Managed (Helm chart)_\n\nDer GitLab Helm chart hat NGINX Ingress als Standard-Netzwerkkomponente gebündelt. NGINX Ingress hat im März 2026 das End-of-Life erreicht. GitLab wechselt nun zu Gateway API mit Envoy Gateway als neuem Standard.\n\nAb GitLab 19.0 werden Gateway API und das gebündelte Envoy Gateway zur Standard-Netzwerkkonfiguration. Falls eine Migration zu Envoy Gateway für das eigene Deployment nicht sofort möglich ist, kann das gebündelte NGINX Ingress explizit wieder aktiviert werden — es bleibt bis zur geplanten Entfernung in GitLab 20.0 verfügbar.\n\nDiese Änderung betrifft nicht:\n\n- Das im Linux-Paket enthaltene NGINX\n- GitLab Helm chart- und GitLab Operator-Instanzen, die einen extern verwalteten Ingress- oder Gateway-API-Controller verwenden\n\nGitLab stellt bis zur vollständigen Entfernung Best-Effort-Sicherheitswartung für den geforkten NGINX Ingress chart und die zugehörigen Builds bereit. Für einen reibungslosen Übergang empfiehlt sich eine frühzeitige Migration zur bereitgestellten Gateway-API-Lösung oder zu einem extern verwalteten Ingress-Controller.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/590800)\n\n\n**2. Gebündelte PostgreSQL-, Redis- und MinIO-Komponenten aus dem GitLab Helm chart entfernt**\n\n_GitLab Self-Managed (Helm chart)_\n\nDer GitLab Helm chart hat Bitnami PostgreSQL, Bitnami Redis und einen Fork des offiziellen MinIO-Charts gebündelt, um die Einrichtung von GitLab in Proof-of-Concept- und Testumgebungen zu erleichtern. Aufgrund von Änderungen bei Lizenzierung, Projektpflege und Verfügbarkeit öffentlicher Images werden diese Komponenten ohne Ersatz aus dem GitLab Helm chart und dem GitLab Operator entfernt.\n\nDiese Charts sind ausdrücklich als nicht für den Produktionseinsatz geeignet dokumentiert. Ihr einziger Zweck war die Bereitstellung schneller Testumgebungen.\n\nWer eine Instanz mit gebündeltem PostgreSQL, Redis oder MinIO betreibt, muss vor dem Upgrade auf GitLab 19.0 der [Migrationsanleitung](https://docs.gitlab.com/charts/installation/migration/bundled_chart_migration/) folgen, um externe Dienste zu konfigurieren. Redis und PostgreSQL aus dem Linux-Paket sind von dieser Änderung nicht betroffen.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/590797)\n\n\n**3. Resource Owner Password Credentials (ROPC) OAuth Grant entfernt**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nDie Unterstützung für den Resource Owner Password Credentials (ROPC) Grant als OAuth-Flow wird in GitLab 19.0 vollständig entfernt. Dies entspricht dem OAuth RFC Version 2.1-Standard, der ROPC aufgrund seiner inhärenten Sicherheitsschwächen entfernt.\n\nGitLab hat seit dem 8. April 2025 bereits eine Client-Authentifizierung für ROPC auf GitLab.com vorgeschrieben. In Version 18.0 wurde eine Administrator-Einstellung hinzugefügt, die einen kontrollierten Opt-out vor der Entfernung ermöglicht.\n\nNach dem Upgrade auf 19.0 kann ROPC unter keinen Umständen mehr verwendet werden, auch nicht mit Client-Credentials. Alle Anwendungen oder Integrationen, die diesen Grant-Typ verwenden, müssen vor dem Upgrade auf einen unterstützten OAuth-Flow migrieren — beispielsweise den Authorization Code Flow.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/457353)\n\n\n**4. PostgreSQL 16 nicht mehr unterstützt — PostgreSQL 17 ist das neue Minimum**\n\n_GitLab Self-Managed_\n\nGitLab folgt einem [jährlichen Upgrade-Rhythmus für PostgreSQL](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/database-framework/postgresql-upgrade-cadence/). In GitLab 19.0 wird PostgreSQL 17 zur Mindestanforderung, die Unterstützung für PostgreSQL 16 wird eingestellt.\n\nPostgreSQL 17 ist ab GitLab 18.9 verfügbar und kann jederzeit vor dem 19.0-Release upgradet werden.\n\nBei Instanzen mit einer einzelnen, über das Linux-Paket installierten PostgreSQL-Instanz wird beim Upgrade auf 18.11 möglicherweise ein automatisches Upgrade auf PostgreSQL 17 durchgeführt. Für das Upgrade ist ausreichend freier Speicherplatz einzuplanen.\n\nBei Instanzen mit PostgreSQL Cluster oder solchen, die das automatische Upgrade deaktivieren, ist vor dem Upgrade auf GitLab 19.0 ein manuelles Upgrade auf PostgreSQL 17 erforderlich.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/589774) | [Upgrade-Anleitung](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server)\n\n\n### Mittlere Auswirkung\n\nFolgende Breaking Changes haben mittlere Auswirkungen.\n\n**1. Linux-Paket-Unterstützung für Ubuntu 20.04 eingestellt**\n\n_GitLab Self-Managed_\n\nDer Standard-Support für Ubuntu 20.04 endete im Mai 2025. Gemäß der [Richtlinie für unterstützte Plattformen im Linux-Paket](https://docs.gitlab.com/install/package/#supported-platforms) werden Pakete eingestellt, sobald ein Anbieter den Support für das Betriebssystem beendet.\n\nAb GitLab 19.0 werden keine Pakete mehr für Ubuntu 20.04 bereitgestellt. GitLab 18.11 ist das letzte Release mit Linux-Paketen für diese Distribution.\n\nWer GitLab derzeit auf Ubuntu 20.04 betreibt, muss vor dem Upgrade auf GitLab 19.0 auf Ubuntu 22.04 oder ein anderes [unterstütztes Betriebssystem](https://docs.gitlab.com/install/package/#supported-platforms) wechseln. Canonical stellt eine [Upgrade-Anleitung](https://documentation.ubuntu.com/server/how-to/software/upgrade-your-release/) für die Migration bereit.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/8915)\n\n\n**2. Unterstützung für Redis 6 entfernt**\n\n_GitLab Self-Managed_\n\nIn GitLab 19.0 wird die Unterstützung für Redis 6 entfernt. Instanzen mit einem externen Redis-6-Deployment müssen vor dem Upgrade auf Redis 7.2 oder Valkey 7.2 migrieren; Valkey 7.2 ist ab GitLab 18.9 in der Beta verfügbar, die allgemeine Verfügbarkeit ist für GitLab 19.0 geplant.\n\nDas im Linux-Paket enthaltene Redis verwendet seit GitLab 16.2 Redis 7 und ist nicht betroffen. Handlungsbedarf besteht nur bei Instanzen mit einem externen Redis-6-Deployment.\n\nMigrationsressourcen für gängige Plattformen:\n\n- **AWS ElastiCache:** Upgrade auf [Redis 7.2 oder Valkey 7.2](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/supported-engine-versions.html)\n- **GCP Memorystore:** Upgrade auf [Redis 7.2 oder Valkey 7.2](https://cloud.google.com/memorystore/docs/redis/supported-versions)\n- **Azure Cache for Redis:** Managed Redis 7.2 oder Valkey 7.2 ist auf Azure noch nicht verfügbar. Als Alternative kann ein selbstgehostetes Deployment auf Azure VMs oder AKS genutzt werden, oder die Linux-Paket-Installation, die Valkey 7.2 mit GitLab 19.0 GA unterstützen wird.\n- **Self-hosted:** Upgrade der Redis-6-Instanz auf Redis 7.2 oder Valkey 7.2.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/585839) | [Anforderungsdokumentation](https://docs.gitlab.com/install/requirements/)\n\n\n**3. `heroku/builder:22`-Image durch `heroku/builder:24` ersetzt**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nDas Cloud-Native-Buildpack (CNB) Builder-Image in Auto DevOps wurde auf `heroku/builder:24` aktualisiert. Betroffen sind Pipelines, die das [`auto-build-image`](https://gitlab.com/gitlab-org/cluster-integration/auto-build-image) der [Auto Build-Stage von Auto DevOps](https://docs.gitlab.com/topics/autodevops/stages/#auto-build) verwenden.\n\nDie meisten Workloads sind nicht betroffen. Für einige Nutzende kann dies jedoch ein Breaking Change sein. Vor dem Upgrade sollten die [Heroku-24-Stack-Release-Notes](https://devcenter.heroku.com/articles/heroku-24-stack#what-s-new) und [Upgrade-Hinweise](https://devcenter.heroku.com/articles/heroku-24-stack#upgrade-notes) geprüft werden.\n\nWer nach GitLab 19.0 weiterhin `heroku/builder:22` verwenden möchte, setzt die CI/CD-Variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER` auf `heroku/builder:22`.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/cluster-integration/auto-build-image/-/issues/79)\n\n\n**4. Mattermost aus dem Linux-Paket entfernt**\n\n_GitLab Self-Managed_\n\nIn GitLab 19.0 wird das gebündelte Mattermost aus dem Linux-Paket entfernt. Mattermost wurde seit 2015 mit GitLab gebündelt, verfügt inzwischen aber über ausgereifte eigenständige Deployment-Optionen. Mit Mattermost v11 wurde zudem [GitLab SSO aus dem kostenlosen Angebot entfernt](https://forum.mattermost.com/t/mattermost-v11-changes-in-free-offerings/25126), was den Mehrwert der gebündelten Integration verringert.\n\nWer das gebündelte Mattermost nicht verwendet, ist nicht betroffen. Bei Bedarf steht in der Mattermost-Dokumentation eine Anleitung zur [Migration von GitLab Omnibus zu Mattermost Standalone](https://docs.mattermost.com/administration-guide/onboard/migrate-gitlab-omnibus.html) zur Verfügung.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/590798)\n\n\n**5. Linux-Paket-Unterstützung für SUSE-Distributionen eingestellt**\n\n_GitLab Self-Managed_\n\nIn GitLab 19.0 wird die Linux-Paket-Unterstützung für SUSE-Distributionen eingestellt. Betroffen sind:\n\n- openSUSE Leap 15.6\n- SUSE Linux Enterprise Server 12.5\n- SUSE Linux Enterprise Server 15.6\n\nGitLab 18.11 ist das letzte Release mit Linux-Paketen für diese Distributionen. Der empfohlene Weg ist eine Migration zu einem [Docker-Deployment von GitLab](https://docs.gitlab.com/install/docker/installation/) auf der bestehenden Distribution — so ist kein Wechsel des Betriebssystems nötig, um weiterhin Upgrades zu erhalten.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/590801)\n\n\n### Geringe Auswirkung\n\nFolgende Breaking Changes haben geringe Auswirkungen.\n\n**1. Spamcheck aus Linux-Paket und GitLab Helm chart entfernt**\n\n_GitLab Self-Managed_\n\nIn GitLab 19.0 wird [Spamcheck](https://docs.gitlab.com/administration/reporting/spamcheck/) aus dem Linux-Paket und dem GitLab Helm chart entfernt. Es ist in erster Linie für große öffentliche Instanzen relevant — ein Sonderfall in der GitLab-Kundenbasis. Die Entfernung reduziert die Paketgröße und den Abhängigkeits-Footprint für die Mehrheit der Nutzenden.\n\nWer Spamcheck nicht verwendet, ist nicht betroffen. Wer das gebündelte Spamcheck nutzt, kann es separat über [Docker](https://gitlab.com/gitlab-org/gl-security/security-engineering/security-automation/spam/spamcheck) bereitstellen. Eine Datenmigration ist nicht erforderlich.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/590796)\n\n\n**2. Slack-Slash-Commands-Integration entfernt**\n\n_GitLab Self-Managed | Dedicated_\n\nDie [Slack-Slash-Commands-Integration](https://docs.gitlab.com/user/project/integrations/slack_slash_commands/) wird zugunsten der [GitLab for Slack-App](https://docs.gitlab.com/user/project/integrations/gitlab_slack_application/) eingestellt, die eine sicherere Integration mit denselben Funktionen bietet.\n\nAb GitLab 19.0 können Slack Slash Commands nicht mehr konfiguriert oder verwendet werden. Diese Integration existiert nur in GitLab Self-Managed und GitLab Dedicated — GitLab.com-Nutzende sind nicht betroffen.\n\nOb die eigene Instanz betroffen ist, lässt sich mit der [Betroffenheitsprüfung](https://gitlab.com/gitlab-org/gitlab/-/work_items/569345#am-i-impacted) feststellen.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/569345)\n\n\n**3. Bitbucket-Cloud-Import über API unterstützt keine App-Passwörter mehr**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nAtlassian hat App-Passwörter (Benutzername-Passwort-Authentifizierung) für Bitbucket Cloud eingestellt und angekündigt, dass diese Authentifizierungsmethode ab dem 9. Juni 2026 nicht mehr funktioniert.\n\nAb GitLab 19.0 erfordert der Import von Repositories aus Bitbucket Cloud über die GitLab API [User-API-Tokens](https://support.atlassian.com/organization-administration/docs/understand-user-api-tokens/) anstelle von App-Passwörtern. Nutzende, die aus Bitbucket Server oder über die GitLab-Benutzeroberfläche aus Bitbucket Cloud importieren, sind nicht betroffen.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/588961) | [Betroffenheitsprüfung](https://gitlab.com/gitlab-org/gitlab/-/work_items/588961#am-i-impacted)\n\n\n**4. Trending-Tab auf der Seite „Projekte erkunden\" entfernt**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nDer Tab **Trending** unter **Erkunden > Projekte** und die zugehörigen GraphQL-Argumente werden in GitLab 19.0 entfernt. Der Trending-Algorithmus berücksichtigt nur öffentliche Projekte und ist daher für Self-Managed-Instanzen, die hauptsächlich interne oder private Projektsichtbarkeit verwenden, nicht zielführend.\n\nIm Monat vor dem GitLab-19.0-Release wird der Tab **Trending** auf GitLab.com auf den Tab **Aktiv**, sortiert nach Sternen in absteigender Reihenfolge, weitergeleitet.\n\nEbenfalls entfernt: das `trending`-Argument in den GraphQL-Typen `Query.adminProjects`, `Query.projects` und `Organization.projects`.\n\n[Deprecation notice](https://gitlab.com/groups/gitlab-org/-/work_items/18493)\n\n\n**5. Container-Registry-Speichertreiber-Updates**\n\n_GitLab Self-Managed_\n\nZwei ältere Container-Registry-Speichertreiber werden in GitLab 19.0 ersetzt:\n\n- **Azure-Speichertreiber:** Der ältere `azure`-Treiber wird zu einem Alias für den neuen `azure_v2`-Treiber. Es ist keine manuelle Aktion erforderlich, eine proaktive Migration wird jedoch für verbesserte Zuverlässigkeit und Leistung empfohlen. Migrationsschritte sind in der [Object-Storage-Dokumentation](https://docs.gitlab.com/administration/packages/container_registry/#use-object-storage) beschrieben. [Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/523096)\n\n- **S3-Speichertreiber (AWS SDK v1):** Der ältere `s3`-Treiber wird zu einem Alias für den neuen `s3_v2`-Treiber. Der `s3_v2`-Treiber unterstützt Signature Version 2 nicht — eine vorhandene `v4auth: false`-Konfiguration wird transparent ignoriert. Vor dem Upgrade ist eine Migration auf Signature Version 4 erforderlich. [Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/523095)\n\n\n**6. `ciJobTokenScopeAddProject`-GraphQL-Mutation entfernt**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nDie `ciJobTokenScopeAddProject`-GraphQL-Mutation wird zugunsten von `ciJobTokenScopeAddGroupOrProject` eingestellt, das zusammen mit den CI/CD-Job-Token-Scope-Änderungen in GitLab 18.0 eingeführt wurde. Automatisierungen oder Tools, die die veraltete Mutation verwenden, müssen vor dem Upgrade aktualisiert werden.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/474175)\n\n\n**7. `ci_job_token_scope_enabled`-Attribut der Projects API entfernt**\n\n_GitLab.com | Self-Managed | Dedicated_\n\nDas Attribut `ci_job_token_scope_enabled` in der [Projects REST API](https://docs.gitlab.com/api/projects/) wird in GitLab 19.0 entfernt. Das Attribut wurde in GitLab 18.0 eingestellt, als die zugrundeliegende Einstellung entfernt wurde, und hat seitdem stets `false` zurückgegeben.\n\nZur Steuerung des CI/CD-Job-Token-Zugriffs werden die [CI/CD-Job-Token-Projekteinstellungen](https://docs.gitlab.com/ci/jobs/ci_job_token/#control-job-token-access-to-your-project) verwendet.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/issues/423091)\n\n\n**8. Paginierungslimit für nicht authentifizierte Projects-API auf GitLab.com eingeführt**\n\n_GitLab.com_\n\nZur Sicherstellung der Plattformstabilität und konsistenten Leistung wird für alle nicht authentifizierten Anfragen an die Projects-List-REST-API auf GitLab.com ein maximales Offset-Limit von 50.000 eingeführt. Beispielsweise ist der `page`-Parameter bei 20 Ergebnissen pro Seite auf 2.500 Seiten begrenzt.\n\nWorkflows, die Zugriff auf mehr Daten benötigen, müssen keyset-basierte Paginierungsparameter verwenden. Dieses Limit gilt nur für GitLab.com. In GitLab Self-Managed und GitLab Dedicated ist das Offset-Limit standardmäßig deaktiviert und hinter einem Feature-Flag verfügbar.\n\n[Deprecation notice](https://gitlab.com/gitlab-org/gitlab/-/work_items/585176)\n\n\n## Ressourcen zur Folgenabschätzung\n\nGitLab stellt spezifische Tools bereit, mit denen sich die Auswirkungen der geplanten Änderungen auf die eigene GitLab-Instanz analysieren lassen. Nach der Folgenabschätzung empfiehlt sich die Prüfung der Migrationsschritte in der jeweiligen Dokumentation für einen reibungslosen Übergang zu GitLab 19.0.\n\n**[GitLab Detective](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective) (nur Self-Managed):** Dieses experimentelle Tool prüft eine GitLab-Installation automatisch auf bekannte Probleme, indem es Konfigurationsdateien und Datenbankwerte analysiert. Hinweis: Es muss direkt auf den GitLab-Nodes ausgeführt werden.\n\nNutzende mit einem kostenpflichtigen Plan, die Fragen haben oder Unterstützung bei diesen Änderungen benötigen, können ein Support-Ticket im [GitLab Support-Portal](https://support.gitlab.com/) eröffnen.\n\nKostenlose GitLab.com-Nutzende können zusätzlichen Support über Community-Ressourcen wie die [GitLab-Dokumentation](https://docs.gitlab.com/), das [GitLab Community Forum](https://forum.gitlab.com/) und [Stack Overflow](https://stackoverflow.com/questions/tagged/gitlab) erhalten.\n",[9,18],"news",[20],"Martin Brümmer","Ein Leitfaden zu den Breaking Changes in GitLab 19.0","GitLab 19.0 steht vor der Tür: Was sich ändert, welche Anpassungen das eigene Deployment erfordert und wie man sich auf das Upgrade vorbereitet.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1775561395/bhe1as7ttjvzltxwgo5m.png","yml",{},true,"/de-de/blog/a-guide-to-the-breaking-changes-in-gitlab-19-0",{"config":29,"title":21,"description":22},{"noIndex":11},"de-de/blog/a-guide-to-the-breaking-changes-in-gitlab-19-0",[9,18],"4eez8wk9sVzesDG-0gBPhItMmvqPkAUGaqF0ORt_mEs",{"data":34},{"logo":35,"freeTrial":40,"sales":45,"login":50,"items":55,"search":364,"minimal":399,"duo":417,"pricingDeployment":426},{"config":36},{"href":37,"dataGaName":38,"dataGaLocation":39},"/de-de/","gitlab logo","header",{"text":41,"config":42},"Kostenlose Testversion anfordern",{"href":43,"dataGaName":44,"dataGaLocation":39},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de&glm_content=default-saas-trial/","free trial",{"text":46,"config":47},"Vertrieb kontaktieren",{"href":48,"dataGaName":49,"dataGaLocation":39},"/de-de/sales/","sales",{"text":51,"config":52},"Anmelden",{"href":53,"dataGaName":54,"dataGaLocation":39},"https://gitlab.com/users/sign_in/","sign in",[56,83,179,184,285,345],{"text":57,"config":58,"cards":60},"Plattform",{"dataNavLevelOne":59},"platform",[61,67,75],{"title":57,"description":62,"link":63},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":64,"config":65},"Erkunde unsere Plattform",{"href":66,"dataGaName":59,"dataGaLocation":39},"/de-de/platform/",{"title":68,"description":69,"link":70},"GitLab Duo Agent Platform","Agentische KI für den gesamten Softwareentwicklungszyklus",{"text":71,"config":72},"Lerne GitLab Duo kennen",{"href":73,"dataGaName":74,"dataGaLocation":39},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":76,"description":77,"link":78},"Gründe, die für GitLab sprechen","Erfahre, warum Unternehmen auf GitLab setzen",{"text":79,"config":80},"Mehr erfahren",{"href":81,"dataGaName":82,"dataGaLocation":39},"/de-de/why-gitlab/","why gitlab",{"text":84,"left":26,"config":85,"link":87,"lists":91,"footer":161},"Produkt",{"dataNavLevelOne":86},"solutions",{"text":88,"config":89},"Alle Lösungen anzeigen",{"href":90,"dataGaName":86,"dataGaLocation":39},"/de-de/solutions/",[92,117,139],{"title":93,"description":94,"link":95,"items":100},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":96},{"icon":97,"href":98,"dataGaName":99,"dataGaLocation":39},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[101,105,108,113],{"text":102,"config":103},"CI/CD",{"href":104,"dataGaLocation":39,"dataGaName":102},"/de-de/solutions/continuous-integration/",{"text":68,"config":106},{"href":73,"dataGaLocation":39,"dataGaName":107},"gitlab duo agent platform - product menu",{"text":109,"config":110},"Quellcodeverwaltung",{"href":111,"dataGaLocation":39,"dataGaName":112},"/de-de/solutions/source-code-management/","Source Code Management",{"text":114,"config":115},"Automatisierte Softwarebereitstellung",{"href":98,"dataGaLocation":39,"dataGaName":116},"Automated software delivery",{"title":118,"description":119,"link":120,"items":125},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":121},{"href":122,"dataGaName":123,"dataGaLocation":39,"icon":124},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[126,130,135],{"text":127,"config":128},"Application Security Testing",{"href":122,"dataGaName":129,"dataGaLocation":39},"Application security testing",{"text":131,"config":132},"Schutz der Software-Lieferkette",{"href":133,"dataGaLocation":39,"dataGaName":134},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":136,"config":137},"Software Compliance",{"href":138,"dataGaName":136,"dataGaLocation":39},"/de-de/solutions/software-compliance/",{"title":140,"link":141,"items":146},"Bewertung",{"config":142},{"icon":143,"href":144,"dataGaName":145,"dataGaLocation":39},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[147,151,156],{"text":148,"config":149},"Sichtbarkeit und Bewertung",{"href":144,"dataGaLocation":39,"dataGaName":150},"Visibility and Measurement",{"text":152,"config":153},"Wertstrommanagement",{"href":154,"dataGaLocation":39,"dataGaName":155},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":157,"config":158},"Analysen und Einblicke",{"href":159,"dataGaLocation":39,"dataGaName":160},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":162,"items":163},"GitLab für",[164,169,174],{"text":165,"config":166},"Enterprise",{"href":167,"dataGaLocation":39,"dataGaName":168},"/de-de/enterprise/","enterprise",{"text":170,"config":171},"Kleinunternehmen",{"href":172,"dataGaLocation":39,"dataGaName":173},"/de-de/small-business/","small business",{"text":175,"config":176},"den öffentlichen Sektor",{"href":177,"dataGaLocation":39,"dataGaName":178},"/de-de/solutions/public-sector/","public sector",{"text":180,"config":181},"Preise",{"href":182,"dataGaName":183,"dataGaLocation":39,"dataNavLevelOne":183},"/de-de/pricing/","pricing",{"text":185,"config":186,"link":188,"lists":192,"feature":272},"Ressourcen",{"dataNavLevelOne":187},"resources",{"text":189,"config":190},"Alle Ressourcen anzeigen",{"href":191,"dataGaName":187,"dataGaLocation":39},"/de-de/resources/",[193,226,244],{"title":194,"items":195},"Erste Schritte",[196,201,206,211,216,221],{"text":197,"config":198},"Installieren",{"href":199,"dataGaName":200,"dataGaLocation":39},"/de-de/install/","install",{"text":202,"config":203},"Kurzanleitungen",{"href":204,"dataGaName":205,"dataGaLocation":39},"/de-de/get-started/","quick setup checklists",{"text":207,"config":208},"Lernen",{"href":209,"dataGaLocation":39,"dataGaName":210},"https://university.gitlab.com/","learn",{"text":212,"config":213},"Produktdokumentation",{"href":214,"dataGaName":215,"dataGaLocation":39},"https://docs.gitlab.com/","product documentation",{"text":217,"config":218},"Best-Practice-Videos",{"href":219,"dataGaName":220,"dataGaLocation":39},"/de-de/getting-started-videos/","best practice videos",{"text":222,"config":223},"Integrationen",{"href":224,"dataGaName":225,"dataGaLocation":39},"/de-de/integrations/","integrations",{"title":227,"items":228},"Entdecken",[229,234,239],{"text":230,"config":231},"Kundenerfolge",{"href":232,"dataGaName":233,"dataGaLocation":39},"/de-de/customers/","customer success stories",{"text":235,"config":236},"Blog",{"href":237,"dataGaName":238,"dataGaLocation":39},"/de-de/blog/","blog",{"text":240,"config":241},"Remote",{"href":242,"dataGaName":243,"dataGaLocation":39},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":245,"items":246},"Vernetzen",[247,252,257,262,267],{"text":248,"config":249},"GitLab-Services",{"href":250,"dataGaName":251,"dataGaLocation":39},"/de-de/services/","services",{"text":253,"config":254},"Community",{"href":255,"dataGaName":256,"dataGaLocation":39},"/community/","community",{"text":258,"config":259},"Forum",{"href":260,"dataGaName":261,"dataGaLocation":39},"https://forum.gitlab.com/","forum",{"text":263,"config":264},"Veranstaltungen",{"href":265,"dataGaName":266,"dataGaLocation":39},"/events/","events",{"text":268,"config":269},"Partner",{"href":270,"dataGaName":271,"dataGaLocation":39},"/de-de/partners/","partners",{"backgroundColor":273,"textColor":274,"text":275,"image":276,"link":280},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":277,"config":278},"the source promo card",{"src":279},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":281,"config":282},"Lies die News",{"href":283,"dataGaName":284,"dataGaLocation":39},"/de-de/the-source/","the source",{"text":286,"config":287,"lists":289},"Unternehmen",{"dataNavLevelOne":288},"company",[290],{"items":291},[292,297,303,305,310,315,320,325,330,335,340],{"text":293,"config":294},"Über",{"href":295,"dataGaName":296,"dataGaLocation":39},"/de-de/company/","about",{"text":298,"config":299,"footerGa":302},"Karriere",{"href":300,"dataGaName":301,"dataGaLocation":39},"/jobs/","jobs",{"dataGaName":301},{"text":263,"config":304},{"href":265,"dataGaName":266,"dataGaLocation":39},{"text":306,"config":307},"Geschäftsführung",{"href":308,"dataGaName":309,"dataGaLocation":39},"/company/team/e-group/","leadership",{"text":311,"config":312},"Team",{"href":313,"dataGaName":314,"dataGaLocation":39},"/company/team/","team",{"text":316,"config":317},"Handbuch",{"href":318,"dataGaName":319,"dataGaLocation":39},"https://handbook.gitlab.com/","handbook",{"text":321,"config":322},"Investor Relations",{"href":323,"dataGaName":324,"dataGaLocation":39},"https://ir.gitlab.com/","investor relations",{"text":326,"config":327},"Trust Center",{"href":328,"dataGaName":329,"dataGaLocation":39},"/de-de/security/","trust center",{"text":331,"config":332},"AI Transparency Center",{"href":333,"dataGaName":334,"dataGaLocation":39},"/de-de/ai-transparency-center/","ai transparency center",{"text":336,"config":337},"Newsletter",{"href":338,"dataGaName":339,"dataGaLocation":39},"/company/contact/#contact-forms","newsletter",{"text":341,"config":342},"Presse",{"href":343,"dataGaName":344,"dataGaLocation":39},"/press/","press",{"text":346,"config":347,"lists":348},"Kontakt",{"dataNavLevelOne":288},[349],{"items":350},[351,354,359],{"text":46,"config":352},{"href":48,"dataGaName":353,"dataGaLocation":39},"talk to sales",{"text":355,"config":356},"Support-Portal",{"href":357,"dataGaName":358,"dataGaLocation":39},"https://support.gitlab.com","support portal",{"text":360,"config":361},"Kundenportal",{"href":362,"dataGaName":363,"dataGaLocation":39},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":365,"login":366,"suggestions":373},"Schließen",{"text":367,"link":368},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":369,"config":370},"gitlab.com",{"href":53,"dataGaName":371,"dataGaLocation":372},"search login","search",{"text":374,"default":375},"Vorschläge",[376,378,383,385,390,395],{"text":68,"config":377},{"href":73,"dataGaName":68,"dataGaLocation":372},{"text":379,"config":380},"Code Suggestions (KI)",{"href":381,"dataGaName":382,"dataGaLocation":372},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":102,"config":384},{"href":104,"dataGaName":102,"dataGaLocation":372},{"text":386,"config":387},"GitLab auf AWS",{"href":388,"dataGaName":389,"dataGaLocation":372},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":391,"config":392},"GitLab auf Google Cloud",{"href":393,"dataGaName":394,"dataGaLocation":372},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":396,"config":397},"Warum GitLab?",{"href":81,"dataGaName":398,"dataGaLocation":372},"Why GitLab?",{"freeTrial":400,"mobileIcon":405,"desktopIcon":410,"secondaryButton":413},{"text":401,"config":402},"Kostenlos testen",{"href":403,"dataGaName":44,"dataGaLocation":404},"https://gitlab.com/-/trials/new/","nav",{"altText":406,"config":407},"GitLab-Symbol",{"src":408,"dataGaName":409,"dataGaLocation":404},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":406,"config":411},{"src":412,"dataGaName":409,"dataGaLocation":404},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":194,"config":414},{"href":415,"dataGaName":416,"dataGaLocation":404},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/get-started/","get started",{"freeTrial":418,"mobileIcon":422,"desktopIcon":424},{"text":419,"config":420},"Erfahre mehr über GitLab Duo",{"href":73,"dataGaName":421,"dataGaLocation":404},"gitlab duo",{"altText":406,"config":423},{"src":408,"dataGaName":409,"dataGaLocation":404},{"altText":406,"config":425},{"src":412,"dataGaName":409,"dataGaLocation":404},{"freeTrial":427,"mobileIcon":432,"desktopIcon":434},{"text":428,"config":429},"Zurück zur Preisübersicht",{"href":182,"dataGaName":430,"dataGaLocation":404,"icon":431},"back to pricing","GoBack",{"altText":406,"config":433},{"src":408,"dataGaName":409,"dataGaLocation":404},{"altText":406,"config":435},{"src":412,"dataGaName":409,"dataGaLocation":404},{"title":437,"button":438,"config":443},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":439,"config":440},"GitLab Transcend jetzt ansehen",{"href":441,"dataGaName":442,"dataGaLocation":39},"/de-de/events/transcend/virtual/","transcend event",{"layout":444,"icon":445,"disabled":26},"release","AiStar",{"data":447},{"text":448,"source":449,"edit":455,"contribute":460,"config":465,"items":470,"minimal":643},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":450,"config":451},"Quelltext der Seite anzeigen",{"href":452,"dataGaName":453,"dataGaLocation":454},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":456,"config":457},"Diese Seite bearbeiten",{"href":458,"dataGaName":459,"dataGaLocation":454},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":461,"config":462},"Beteilige dich",{"href":463,"dataGaName":464,"dataGaLocation":454},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":466,"facebook":467,"youtube":468,"linkedin":469},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[471,494,549,576,610],{"title":57,"links":472,"subMenu":477},[473],{"text":474,"config":475},"DevSecOps-Plattform",{"href":66,"dataGaName":476,"dataGaLocation":454},"devsecops platform",[478],{"title":180,"links":479},[480,484,489],{"text":481,"config":482},"Tarife anzeigen",{"href":182,"dataGaName":483,"dataGaLocation":454},"view plans",{"text":485,"config":486},"Vorteile von Premium",{"href":487,"dataGaName":488,"dataGaLocation":454},"/de-de/pricing/premium/","why premium",{"text":490,"config":491},"Vorteile von Ultimate",{"href":492,"dataGaName":493,"dataGaLocation":454},"/de-de/pricing/ultimate/","why ultimate",{"title":495,"links":496},"Lösungen",[497,502,505,507,512,517,521,524,527,532,534,536,539,544],{"text":498,"config":499},"Digitale Transformation",{"href":500,"dataGaName":501,"dataGaLocation":454},"/de-de/topics/digital-transformation/","digital transformation",{"text":503,"config":504},"Sicherheit und Compliance",{"href":122,"dataGaName":129,"dataGaLocation":454},{"text":114,"config":506},{"href":98,"dataGaName":99,"dataGaLocation":454},{"text":508,"config":509},"Agile Entwicklung",{"href":510,"dataGaName":511,"dataGaLocation":454},"/de-de/solutions/agile-delivery/","agile delivery",{"text":513,"config":514},"Cloud-Transformation",{"href":515,"dataGaName":516,"dataGaLocation":454},"/de-de/topics/cloud-native/","cloud transformation",{"text":518,"config":519},"SCM",{"href":111,"dataGaName":520,"dataGaLocation":454},"source code management",{"text":102,"config":522},{"href":104,"dataGaName":523,"dataGaLocation":454},"continuous integration & delivery",{"text":152,"config":525},{"href":154,"dataGaName":526,"dataGaLocation":454},"value stream management",{"text":528,"config":529},"GitOps",{"href":530,"dataGaName":531,"dataGaLocation":454},"/de-de/solutions/gitops/","gitops",{"text":165,"config":533},{"href":167,"dataGaName":168,"dataGaLocation":454},{"text":170,"config":535},{"href":172,"dataGaName":173,"dataGaLocation":454},{"text":537,"config":538},"Öffentlicher Sektor",{"href":177,"dataGaName":178,"dataGaLocation":454},{"text":540,"config":541},"Bildungswesen",{"href":542,"dataGaName":543,"dataGaLocation":454},"/de-de/solutions/education/","education",{"text":545,"config":546},"Finanzdienstleistungen",{"href":547,"dataGaName":548,"dataGaLocation":454},"/de-de/solutions/finance/","financial services",{"title":185,"links":550},[551,553,555,557,560,562,564,566,568,570,572,574],{"text":197,"config":552},{"href":199,"dataGaName":200,"dataGaLocation":454},{"text":202,"config":554},{"href":204,"dataGaName":205,"dataGaLocation":454},{"text":207,"config":556},{"href":209,"dataGaName":210,"dataGaLocation":454},{"text":212,"config":558},{"href":214,"dataGaName":559,"dataGaLocation":454},"docs",{"text":235,"config":561},{"href":237,"dataGaName":238,"dataGaLocation":454},{"text":230,"config":563},{"href":232,"dataGaName":233,"dataGaLocation":454},{"text":240,"config":565},{"href":242,"dataGaName":243,"dataGaLocation":454},{"text":248,"config":567},{"href":250,"dataGaName":251,"dataGaLocation":454},{"text":253,"config":569},{"href":255,"dataGaName":256,"dataGaLocation":454},{"text":258,"config":571},{"href":260,"dataGaName":261,"dataGaLocation":454},{"text":263,"config":573},{"href":265,"dataGaName":266,"dataGaLocation":454},{"text":268,"config":575},{"href":270,"dataGaName":271,"dataGaLocation":454},{"title":286,"links":577},[578,580,582,584,586,588,590,594,599,601,603,605],{"text":293,"config":579},{"href":295,"dataGaName":288,"dataGaLocation":454},{"text":298,"config":581},{"href":300,"dataGaName":301,"dataGaLocation":454},{"text":306,"config":583},{"href":308,"dataGaName":309,"dataGaLocation":454},{"text":311,"config":585},{"href":313,"dataGaName":314,"dataGaLocation":454},{"text":316,"config":587},{"href":318,"dataGaName":319,"dataGaLocation":454},{"text":321,"config":589},{"href":323,"dataGaName":324,"dataGaLocation":454},{"text":591,"config":592},"Sustainability",{"href":593,"dataGaName":591,"dataGaLocation":454},"/sustainability/",{"text":595,"config":596},"Vielfalt, Inklusion und Zugehörigkeit",{"href":597,"dataGaName":598,"dataGaLocation":454},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":326,"config":600},{"href":328,"dataGaName":329,"dataGaLocation":454},{"text":336,"config":602},{"href":338,"dataGaName":339,"dataGaLocation":454},{"text":341,"config":604},{"href":343,"dataGaName":344,"dataGaLocation":454},{"text":606,"config":607},"Transparenzerklärung zu moderner Sklaverei",{"href":608,"dataGaName":609,"dataGaLocation":454},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":611,"links":612},"Nimm Kontakt auf",[613,616,621,623,628,633,638],{"text":614,"config":615},"Sprich mit einem Experten/einer Expertin",{"href":48,"dataGaName":49,"dataGaLocation":454},{"text":617,"config":618},"Support",{"href":619,"dataGaName":620,"dataGaLocation":454},"https://support.gitlab.com/hc/en-us/articles/11626483177756-GitLab-Support","get help",{"text":360,"config":622},{"href":362,"dataGaName":363,"dataGaLocation":454},{"text":624,"config":625},"Status",{"href":626,"dataGaName":627,"dataGaLocation":454},"https://status.gitlab.com/","status",{"text":629,"config":630},"Nutzungsbedingungen",{"href":631,"dataGaName":632,"dataGaLocation":454},"/terms/","terms of use",{"text":634,"config":635},"Datenschutzerklärung",{"href":636,"dataGaName":637,"dataGaLocation":454},"/de-de/privacy/","privacy statement",{"text":639,"config":640},"Cookie-Einstellungen",{"dataGaName":641,"dataGaLocation":454,"id":642,"isOneTrustButton":26},"cookie preferences","ot-sdk-btn",{"items":644},[645,647,649],{"text":629,"config":646},{"href":631,"dataGaName":632,"dataGaLocation":454},{"text":634,"config":648},{"href":636,"dataGaName":637,"dataGaLocation":454},{"text":639,"config":650},{"dataGaName":641,"dataGaLocation":454,"id":642,"isOneTrustButton":26},[652],{"id":653,"title":654,"body":8,"config":655,"content":657,"description":8,"extension":24,"meta":661,"navigation":26,"path":662,"seo":663,"stem":664,"__hash__":665},"blogAuthors/en-us/blog/authors/martin-brmmer.yml","Martin Brmmer",{"template":656},"BlogAuthor",{"name":20,"config":658},{"headshot":659,"ctfId":660},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659427/Blog/Author%20Headshots/martin_brummer.webp","1QkLKK0UnkvZDDBzzEhkaA",{},"/en-us/blog/authors/martin-brmmer",{},"en-us/blog/authors/martin-brmmer","5XXFf9xKfqhpm33ots964Z5lLGWP6fmjjylRLOrvUe4",[667,680,691],{"content":668,"config":678},{"title":669,"description":670,"authors":671,"heroImage":673,"date":674,"body":675,"category":9,"tags":676},"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.",[672],"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",[9,677,18],"AI/ML",{"featured":11,"template":12,"slug":679},"gitlab-18-11-budget-guardrails-for-gitlab-credits",{"content":681,"config":689},{"title":682,"description":683,"authors":684,"heroImage":673,"date":674,"body":686,"category":9,"tags":687},"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.",[685],"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",[677,688,9],"features",{"featured":26,"template":12,"slug":690},"ci-expert-and-data-analyst-ai-agents-target-development-gaps",{"content":692,"config":700},{"title":693,"description":694,"authors":695,"heroImage":673,"date":674,"body":697,"category":9,"tags":698},"GitLab 18.11: KI behebt SAST-Schwachstellen – automatisch und 'ready-to-merge'","GitLab 18.11 macht Agentic SAST Vulnerability Resolution allgemein verfügbar und behebt SAST-Schwachstellen per KI-Code-Fix automatisch.",[696],"Alisa Ho","KI generiert Code schneller, als Security-Teams ihn prüfen können. Was früher ein überschaubarer Rückstand an SAST-Befunden (Static Application Security Testing) war, wächst heute mit jedem KI-assistierten Commit weiter an. Laut [GitLab DevSecOps Report 2025](https://about.gitlab.com/resources/developer-survey/) verbringen Entwicklungsteams bereits 11 Stunden pro Monat damit, Schwachstellen nach dem Release zu beheben – also Probleme zu korrigieren, die bereits in der Produktion ausnutzbar sind, statt neue Funktionen zu liefern. Mehr manuelle Remediierung löst dieses Problem grundsätzlich nicht. [Agentic SAST Vulnerability Resolution](https://docs.gitlab.com/user/application_security/vulnerabilities/agentic_vulnerability_resolution/) innerhalb der GitLab Duo Agent Platform ist für genau dieses Problem entwickelt worden.\n\nMit der allgemeinen Verfügbarkeit in GitLab 18.11 generiert Agentic SAST Vulnerability Resolution automatisch zusammenführungsbereite Code-Fixes zur Behebung von SAST-Schwachstellen:\n\n* Entwicklungsteams bleiben im Arbeitsfluss\n* Schwachstellen werden behoben, bevor sie die Produktion erreichen\n* AppSec-Teams verbringen weniger Zeit mit Triage und der Nachverfolgung offener Findings\n\nGitLab 18.11 liefert darüber hinaus schnelleres SAST-Scanning, evidenzbasierte Priorisierung und klar abgegrenzte Governance-Kontrollen.\n\n\n## Auto-Remediierung ohne Unterbrechung des Arbeitsflusses\n\nWenn KI Code in großem Umfang generiert, verändert sich die Ausgangslage grundlegend. Ein Security-Rückstand, der früher linear wuchs, nimmt heute mit jedem modellgestützten Commit weiter zu. Mehr manuelle Kontextwechsel von Entwicklungsteams zu fordern löst dieses Problem nicht – die Mengen sind schlicht zu groß.\n\nAgentic SAST Vulnerability Resolution verändert die Dynamik dieses Zyklus. Sobald ein SAST-Scan abgeschlossen ist, starten die Findings automatisch den [Erkennungsfluss für Fehlalarme (SAST False Positive Detection)](https://docs.gitlab.com/user/application_security/vulnerabilities/false_positive_detection/). Bestätigte True Positives werden direkt in den Agentic SAST Vulnerability Resolution Flow übergeben, wo GitLab Duo Agent Platform:\n\n* die Schwachstelle im Kontext analysiert\n* einen Fix erstellt, der die Grundursache behebt\n* den Fix durch automatisierte Tests validiert\n\nEntwicklungsteams erhalten einen zusammenführungsbereiten MR mit einem Confidence-Score, auf dessen Basis eine fundierte Entscheidung zur Behebung getroffen werden kann. Der Sprint bleibt auf Kurs, Schwachstellen werden behoben, bevor sie die Produktion erreichen.\n\nZum Thema Scan-Geschwindigkeit: GitLab 18.11 führt [inkrementelles Scanning für Advanced SAST](https://docs.gitlab.com/user/application_security/sast/gitlab_advanced_sast/#incremental-scanning) ein. Entwicklungsteams erhalten Schwachstellenergebnisse, ohne auf den Abschluss eines vollständigen Scans warten zu müssen – Pipelines bleiben durchgehend in Bewegung.\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1183195999?badge=0&autopause=0&player_id=0&app_id=58479%2Fembed\" allow=\"autoplay; fullscreen; picture-in-picture\" allowfullscreen=\"\" frameborder=\"0\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\">\u003C/iframe>\n\n\n## Remediierung nach Geschäftsrisiko – nicht nach Score\n\nEine automatisierte Remediierungspipeline funktioniert nur so gut wie das Signal, das sie antreibt. Wenn Schwachstellenscores die tatsächliche Ausnutzbarkeit nicht widerspiegeln, verlieren Entwicklungsteams das Vertrauen in das Signal – und beginnen, es zu ignorieren.\n\nGitLab 18.11 adressiert dieses Problem auf vier Ebenen. Erstens sind [Schwachstellenscores](https://docs.gitlab.com/user/application_security/vulnerabilities/severities/#critical-severity) jetzt im Common Vulnerability Scoring System (CVSS) 4.0 verankert – dem aktuellen Industriestandard mit differenzierteren Metriken zur Erfassung realer Ausnutzbarkeit. Der Score, den Entwicklungsteams in GitLab sehen, entspricht damit dem Stand der Technik für die Bewertung realer Risiken.\n\nDarüber hinaus können AppSec-Teams [richtlinienbasierte Regeln](https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/#severity-override-policies) definieren, die Schwachstellenscores automatisch anpassen – basierend auf Signalen wie Common Vulnerabilities and Exposures (CVE), Common Weakness Enumeration (CWE) sowie Dateipfad oder Verzeichnis. Einmal konfiguriert, greifen die Schweregrad-Anpassungen sofort, sodass Entwicklungsteams an einem Rückstand arbeiten, der das tatsächliche Geschäftsrisiko widerspiegelt und nicht den unbereinigten Scanner-Output.\n\nDie risikobasierte Steuerung endet nicht beim Rückstand. AppSec-Teams können jetzt [Freigaberichtlinien konfigurieren](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/#vulnerability_attributes-object), die Merges blockieren oder warnen – basierend auf dem Known Exploited Vulnerabilities (KEV)-Status oder dem Exploit Prediction Scoring System (EPSS)-Score. Wird ein Merge blockiert, wissen Entwicklungsteams, dass dies auf realen Ausnutzbarkeitsdaten beruht.\n\nDas [neue Top-CWEs-Diagramm im Security-Dashboard](https://docs.gitlab.com/user/application_security/security_dashboard/#top-10-cwes) gibt Teams abschließend Einblick, welche Schwachstellenklassen in ihren Projekten am häufigsten auftreten. Statt einzelnen Findings nachzujagen, lassen sich Muster erkennen, Grundursachen priorisieren und systemische Risiken adressieren, bevor sie sich auswachsen.\n\n\n## Stärkere Security-Kontrollen bei geringerem operativem Aufwand\n\nEine automatisierte Remediierungspipeline ist nur so gut wie die darunterliegende Scanner-Abdeckung. Inkonsistente Scanner-Konfigurationen führen zu unvollständigen Findings – und damit zu unvollständigen Fixes.\n\nGitLab 18.11 führt den [Security Manager](https://docs.gitlab.com/user/permissions/#default-roles) ein – eine neue Standardrolle, die speziell für Security-Professionals entwickelt wurde. Mit dieser Rolle lassen sich Security-Scanner durchsetzen, Security-Richtlinien definieren und konfigurieren, Triage- und Remediierungs-Workflows für Schwachstellen verwalten sowie Compliance-Frameworks und Audit-Streams pflegen – ohne Code-Änderungs- oder Deployment-Berechtigungen zu benötigen. Security-Teams erhalten genau die Zugriffsrechte, die ihre Aufgaben erfordern, und keine weiteren.\n\nFür AppSec-Teams vereinfachen [SAST-Konfigurationsprofile](https://docs.gitlab.com/user/application_security/configuration/security_configuration_profiles/) die konsistente Scanner-Abdeckung über mehrere Projekte und Gruppen hinweg erheblich. Das Scanning wird einmalig definiert und mit einer Aktion auf alle Projekte einer Gruppe angewendet. Das manuelle Pflegen von YAML-Policy-Dateien, die Abhängigkeit von Entwicklungsteams bei der Scanner-Konfiguration und das Prüfen einzelner Projekte auf Abdeckungslücken entfällt damit.\n\n\n## Automatisierte Vulnerability-Remediierung – jetzt starten\n\nGitLab 18.11 liefert den vollständigen Vulnerability-Workflow auf einer Plattform: KI, die Schwachstellen automatisch behebt, CVSS-4.0-basierte Priorisierung, die Vulnerability-Rauschen reduziert, und Governance-Kontrollen, die Security-Teams den erforderlichen Zugriff und vollständige Abdeckung ermöglichen.\n\n> [GitLab Ultimate kostenlos testen](https://about.gitlab.com/free-trial/?utm_medium=blog&utm_source=blog&utm_campaign=eg_global_x_inbound-request_security_en_) und erleben, wie GitLab Duo Agent Platform die automatisierte Remediierung direkt in den Entwicklungs-Workflow integriert.\n\n\nFür konkrete Compliance-Anforderungen empfiehlt sich die Rücksprache mit entsprechender Fachberatung.\n",[699,677,9,688],"security",{"featured":11,"template":12,"slug":701},"automate-remediation-with-ready-to-merge-ai-code-fixes",{"promotions":703},[704,718,730,741],{"id":705,"categories":706,"header":708,"text":709,"button":710,"image":715},"ai-modernization",[707],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":711,"config":712},"Get your AI maturity score",{"href":713,"dataGaName":714,"dataGaLocation":238},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":716},{"src":717},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":719,"categories":720,"header":722,"text":709,"button":723,"image":727},"devops-modernization",[9,721],"devsecops","Are you just managing tools or shipping innovation?",{"text":724,"config":725},"Get your DevOps maturity score",{"href":726,"dataGaName":714,"dataGaLocation":238},"/assessments/devops-modernization-assessment/",{"config":728},{"src":729},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":731,"categories":732,"header":733,"text":709,"button":734,"image":738},"security-modernization",[699],"Are you trading speed for security?",{"text":735,"config":736},"Get your security maturity score",{"href":737,"dataGaName":714,"dataGaLocation":238},"/assessments/security-modernization-assessment/",{"config":739},{"src":740},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":742,"paths":743,"header":746,"text":747,"button":748,"image":753},"github-azure-migration",[744,745],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":749,"config":750},"See how GitLab compares to GitHub",{"href":751,"dataGaName":752,"dataGaLocation":238},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":754},{"src":729},{"header":756,"blurb":757,"button":758,"secondaryButton":763},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":759,"config":760},"Kostenlosen Test starten",{"href":761,"dataGaName":44,"dataGaLocation":762},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/de-de/","feature",{"text":46,"config":764},{"href":48,"dataGaName":49,"dataGaLocation":762},1776878938820]