[{"data":1,"prerenderedAt":816},["ShallowReactive",2],{"/de-de/blog/how-gitlab-can-support-your-iso-compliance-journey":3,"navigation-de-de":39,"banner-de-de":453,"footer-de-de":463,"blog-post-authors-de-de-Joseph Longo":699,"blog-related-posts-de-de-how-gitlab-can-support-your-iso-compliance-journey":713,"blog-promotions-de-de":754,"next-steps-de-de":806},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":24,"extension":25,"externalUrl":26,"featured":14,"heroImage":17,"isFeatured":14,"meta":27,"navigation":28,"path":29,"publishedDate":20,"rawbody":30,"seo":31,"slug":13,"stem":35,"tagSlugs":36,"tags":37,"template":15,"updatedDate":19,"__hash__":38},"blogPosts/de-de/blog/how-gitlab-can-support-your-iso-compliance-journey.yml","So unterstützt dich GitLab bei deiner ISO-27001-Compliance",[7],"joseph-longo",[9],"Joseph Longo","Als eine durchgängige All-Inclusive-Plattform ist es mit GitLab einfach, deinen DevSecOps-Lebenszyklus zu verwalten. Dank der Plattform von GitLab können Entwickler(innen) schneller bessere Software entwickeln. Das ist aber nicht alles, denn GitLab geht über DevSecOps hinaus.\n\nIm Oktober 2022 veröffentlichte die Internationale Organisation für Normung die neueste Version der Norm ISO 27001. ISO/IEC 27001:2022 enthält mehrere Änderungen gegenüber der vorherigen Version, darunter die neuen Control Kategorien aus Anhang A, bei denen es um sicheres Programmieren und Konfigurationsmanagement geht.\n\nWir bei GitLab nutzen unsere Plattform, um viele Aspekte unseres Sicherheitskonformitätsprogramms zu unterstützen – ein Konzept, das wir intern [Dogfooding](https://handbook.gitlab.com/handbook/product/product-processes/dogfooding-for-r-d/) nennen. Eine Übersicht über den Nachweis der Einhaltung von Vorschriften und Sicherheit findest du in unserem [Trust Center](https://about.gitlab.com/security/).\n\nSehen wir uns nun die wichtigsten Funktionen an, die du bei deiner ISO-27001-Compliance nutzen kannst.\n\n## Organisatorische Controls\n\n\n| Control-ID | Control-Beschreibung |\n| ---- | ---- |\n| 5.3 Aufgabentrennung | Widersprüchliche Aufgaben und Verantwortungsbereiche sind zu trennen. |\n| 5.15 Zugriffskontrolle | Regeln zur Kontrolle des physischen und logischen Zugriffs auf Informationen und andere damit verbundene Vermögenswerte müssen auf der Grundlage der Geschäfts- und Informationssicherheitsanforderungen festgelegt und implementiert werden. |\n| 5.16 Identitätsmanagement | Der gesamte Lebenszyklus von Identitäten ist zu verwalten. |\n| 8.2 Privilegierte Zugriffsrechte | Die Vergabe und Nutzung von privilegierten Zugriffsrechten ist einzuschränken und zu verwalten.|\n| 8.4 Zugriff auf Quellcode | Der Lese- und Schreibzugriff auf Quellcode, Entwicklungstools und Softwarebibliotheken ist angemessen zu verwalten. |\n\n\nMit GitLab kannst du [Benutzer(inne)n eine Rolle zuweisen](https://docs.gitlab.com/user/permissions/), wenn du sie zu einem Projekt oder einer Gruppe hinzufügst. Die Rolle eines Benutzers/einer Benutzerin legt fest, was er/sie in deiner GitLab-Instanz ausführen kann. Folgende Rollen stehen für die Zuweisung zur Verfügung:\n\n* Gast (nur private und interne Projekte)\n\n* Reporter(in)\n\n* Entwickler(in)\n\n* Betreuer(in)\n\n* Eigentümer(in)\n\n* Minimaler Zugriff (nur für die Hauptgruppe verfügbar)\n\nMit den Rollen von GitLab kannst du die Berechtigungen eines Benutzers/einer Benutzerin gemäß dem [Prinzip der geringsten Privilegien](https://csrc.nist.gov/glossary/term/least_privilege) und deinen Geschäfts- und Informationssicherheitsanforderungen einschränken.\n\nAußerdem kannst du dank GitLab die Authentifizierungs- und Autorisierungsverantwortlichkeiten für deine GitLab-Instanz über [SAML-SSO-Integrationen](https://docs.gitlab.com/user/group/saml_sso/) zentralisieren. GitLab lässt sich in eine Vielzahl von Identitätsanbietern integrieren, um die verschiedenen Technologie-Stacks unserer Kund(inn)en zu unterstützen. GitLab unterstützt auch das System für domänenübergreifendes Identitätsmanagement ([SCIM](https://docs.gitlab.com/user/group/saml_sso/scim_setup/)). Durch die SSO- und SCIM-Integrationen von GitLab kannst du den Lebenszyklus deiner Benutzeridentitäten sicher und effizient automatisieren.\n\n[SSO](https://docs.gitlab.com/integration/saml/) und [SCIM](https://docs.gitlab.com/administration/settings/scim_setup/) sind auch für selbstverwaltete Kund(inn)en von GitLab verfügbar.\n\n**Hinweis:** Die technologischen Controls 8.2 und 8.4 in Anhang 8 wurden aufgrund ihrer Nähe zu den organisatorischen Controls 5.3, 5.15 und 5.16 in die oben stehende Tabelle aufgenommen. Für die Anforderungen dieser Controls können die gleichen GitLab-Funktionen angewendet werden.\n\n\n\u003Cbr>\n\n| Control-ID | Control-Beschreibung |\n| ---- | ---- |\n| 5.8 Informationssicherheit im Projektmanagement | Informationssicherheit ist in das Projektmanagement zu integrieren. |\n\nMit GitLab kannst du unsere [Planungstools](https://about.gitlab.com/pricing/feature-comparison/) für dein Projektmanagement nutzen und so sicherstellen, dass die Informationssicherheit in allen Phasen eines Projektlebenszyklus eingehalten wird.\n\n- Mit der [Teamplanung](https://about.gitlab.com/pricing/feature-comparison/#team_planning) von GitLab können Benutzer(innen) Projektarbeiten von der Idee bis zur Produktion organisieren, planen, abstimmen und nachverfolgen.\n\n- [Epics](https://docs.gitlab.com/user/group/epics/), [Tickets](https://docs.gitlab.com/user/project/issues/) und [Aufgaben](https://docs.gitlab.com/user/tasks/) können verwendet werden, um gemeinsam an Ideen zu arbeiten, Probleme zu lösen und Arbeiten mit deinem Informationssicherheitsteam zu planen. [Beschreibungsvorlagen](https://docs.gitlab.com/user/project/description_templates/) und [Checklisten](https://docs.gitlab.com/user/markdown/#task-lists) ermöglichen es den Benutzer(inne)n, konsistente Beschreibungen und Workflows für Tickets oder [Merge Requests](https://docs.gitlab.com/user/project/merge_requests/) einzuhalten. Mit diesen Vorlagen kann die Informationssicherheit konsistent in deinen Projektmanagement-Lebenszyklus integriert werden.\n\n- [Labels](https://docs.gitlab.com/user/project/labels/) ermöglichen es Benutzer(inne)n, Probleme so zu organisieren, wie sie es für richtig halten. Im Hinblick auf die Informationssicherheit können Label verwendet werden, um die Risikostufe eines Projekts zu identifizieren, die Phase eines Projekts anzugeben oder das Informationssicherheitsteam zu markieren, das für eine bestimmte Arbeit zuständig ist. [Labels mit begrenztem Geltungsbereich](https://docs.gitlab.com/user/project/labels/#scoped-labels) können verwendet werden, um Workflows weitere Logik hinzuzufügen. Sie verhindern nämlich, dass bestimmte Labels zusammen verwendet werden. Bei GitLab nutzen wir [Labels mit begrenztem Geltungsbereich](https://docs.gitlab.com/user/project/labels/#scoped-labels), um die Arbeit, die verschiedenen Teams zugewiesen ist, die Projektphase, in der sich die Arbeit befindet, und das Produkt oder den Funktionsumfang, der mit der Arbeit verbunden ist, zu identifizieren.\n\n![Labels mit begrenztem Geltungsbereich](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/scoped-labels.png)\n\nLabels mit begrenztem Geltungsbereich\n\n\n- Mit [Gruppen-](https://docs.gitlab.com/user/project/issue_board/#group-issue-boards) und [Projekt-](https://docs.gitlab.com/user/project/issue_board/)-Issue-Übersichten kannst du deine Arbeit noch besser organisieren und eine zentrale, zusammengefasste Ansicht für alle mit einer Gruppe oder einem Projekt verbundenen Arbeiten bieten.\n\n## Technologische Controls\n\n| Control-ID | Control-Beschreibung |\n| ---- | ---- |\n| 8.8 Management technischer Sicherheitslücken | Informationen über technische Sicherheitslücken der verwendeten Informationssysteme sind einzuholen, die Exposition des Unternehmens gegenüber solchen Sicherheitslücken ist zu bewerten und geeignete Maßnahmen sind zu ergreifen. |\n| 8.9 Konfigurationsmanagement | Konfigurationen von Hardware, Software, Diensten und Netzwerken, einschließlich Sicherheitskonfigurationen, müssen festgelegt, dokumentiert, implementiert, überwacht und überprüft werden. |\n| 8.25 Sicherer Entwicklungslebenszyklus | Regeln für die sichere Entwicklung von Software und Systemen müssen festgelegt und angewendet werden. |\n| 8.26 Anforderungen an die Anwendungssicherheit | Anforderungen an die Informationssicherheit müssen bei der Entwicklung oder dem Erwerb von Anwendungen identifiziert, spezifiziert und genehmigt werden. |\n| 8.27 Sichere Systemarchitektur und technische Grundsätze | Grundsätze für die Entwicklung sicherer Systeme müssen festgelegt, dokumentiert, gepflegt und bei allen Entwicklungsaktivitäten von Informationssystemen angewendet werden |\n\nMit GitLab kannst du deine Hardware- und Softwarekonfigurationen speichern, die Versionskontrolle verwalten, deine Konfigurationen über [Merge Requests](https://docs.gitlab.com/user/project/merge_requests/) aktualisieren und die [CI/CD-Pipelines](https://docs.gitlab.com/ci/pipelines/) von GitLab nutzen, um diese Konfigurationen in deine Anwendungen und Infrastruktur zu übertragen. Mit GitLab können Unternehmen [GitOps](https://about.gitlab.com/topics/gitops/) über eine einzige Plattform implementieren.\n\nMit dem [Infrastructure-as-Code-Scanning](https://docs.gitlab.com/user/application_security/iac_scanning/) von GitLab kannst du deine IaC-Konfigurationsdateien auf bekannte Sicherheitslücken scannen. Das IaC-Scanning von GitLab unterstützt eine Vielzahl von IaC-Konfigurationsdateien und -Sprachen, wodurch es an verschiedene Technologie-Stacks angepasst werden kann.\n\nFür Compliance-Profis ermöglicht GitLab die Implementierung von Automatisierung durch [Compliance-Frameworks](https://docs.gitlab.com/user/group/compliance_frameworks/) und [Compliance-Pipelines](https://docs.gitlab.com/user/group/compliance_frameworks/#compliance-pipelines). Dank dieser Funktionen können Benutzer(innen) kritische Projekte mit bestimmten Compliance-Anforderungen identifizieren und Konfigurationen über Pipelines an diese Projekte pushen. Sie ermöglichen eine konsistente Durchsetzung der Controls und unterstützen dadurch deine Sicherheitslage. Außerdem stellen sie sicher, dass die internen und externen Compliance-Anforderungen deines Unternehmens eingehalten werden.\n\nFür [Ultimate-Kund(inn)en](https://about.gitlab.com/pricing/ultimate/) bietet das [Compliance Center](https://docs.gitlab.com/user/compliance/compliance_center/) von GitLab eine zentrale Ansicht des Compliance-Zustands einer Gruppe, z. B. der verschiedenen Compliance Frameworks, die auf die Projekte in der Gruppe angewendet werden. Du kannst sogar sehen, wie gut du den [GitLab-Standard](https://docs.gitlab.com/user/compliance/compliance_center/#gitlab-standard) erfüllst.\n\n\u003Cbr>\n\n| Control-ID | Control-Beschreibung |\n| ---- | ---- |\n| 8.15 Protokollierung | Protokolle, die Aktivitäten, Ausnahmen, Fehler und andere relevante Ereignisse aufzeichnen, sind zu erstellen, zu speichern, zu schützen und zu analysieren. |\n| 8.16 Kontrolle von Überwachungsaktivitäten | Netzwerke, Systeme und Anwendungen müssen auf anomales Verhalten überwacht und geeignete Maßnahmen zur Bewertung potenzieller Informationssicherheitsvorfälle ergriffen werden. |\n\nMit GitLab kannst du [Audit-Ereignisse](https://docs.gitlab.com/administration/audit_events/) verwenden, um wichtige Ereignisse zu verfolgen, einschließlich der Frage, wer wann die entsprechende Aktion durchgeführt hat. Audit-Ereignisse decken ein breites Spektrum von Kategorien ab, darunter:\n\n* Gruppenverwaltung\n\n* Authentifizierung und Autorisierung\n\n* Benutzerverwaltung\n\n* Compliance und Sicherheit\n\n* CI/CD\n\n* GitLab-Runner\n\n![Audit-Ereignisse](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/example-of-an-audit-event.png)\n\nBeispiel für ein Audit-Ereignis\n\n\nFür [Ultimate-Kund(inn)en](https://about.gitlab.com/pricing/ultimate/) kann das [Audit-Ereignis-Streaming](https://docs.gitlab.com/administration/audit_event_streaming/) aktiviert werden. Mit dem Audit-Ereignis-Streaming können Benutzer(innen) ein Streaming-Ziel für eine Gruppe oder Instanz der obersten Ebene festlegen, um alle Audit-Ereignisse über die Gruppe, Untergruppen und Projekte als strukturierte JSON-Datei zu erhalten.\n\n\u003Cbr>\n\n| Control-ID | Control-Beschreibung |\n| ---- | ---- |\n| 8.28 Sichere Programmierung | Bei der Softwareentwicklung sind die Prinzipien des sicheren Programmierens anzuwenden. |\n| 8.29 Sicherheitstests in Entwicklung und Akzeptanz | Sicherheitstestprozesse sind im Entwicklungslebenszyklus zu definieren und umzusetzen. |\n\nDu kannst die Funktionen in der [Sicherungsphase](https://about.gitlab.com/pricing/feature-comparison/) von GitLab nutzen, um den Lebenszyklus deiner Softwareentwicklung zu verbessern und die Sicherheit deiner Produkte zu verbessern. Zu den Funktionen von GitLab in der Sicherungsphase gehören:\n\n* [Statische Anwendungssicherheitstests (SAST)](https://docs.gitlab.com/user/application_security/sast/)\n\n* [Dynamische Anwendungssicherheitstests (DAST)](https://docs.gitlab.com/user/application_security/dast/)\n\n* [Codequalität](https://docs.gitlab.com/ci/testing/code_quality/)\n\n* [Container-Scanning](https://docs.gitlab.com/user/application_security/container_scanning/)\n\n* [Abhängigkeitssuche](https://docs.gitlab.com/user/application_security/dependency_scanning/)\n\nund vieles mehr!\n\n![Ergebnisse zur Codequalität](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/code-quality-findings.png)\n\nErgebnisse zur Codequalität\n\n\nKompromittierte Geheimnisse sind einer der führenden Katalysatoren für Sicherheitsverletzungen. Die [Erkennung von Geheimnissen](https://docs.gitlab.com/user/application_security/secret_detection/) von GitLab scannt dein Repository, um zu verhindern, dass deine Geheimnisse aufgedeckt werden.\n\nMit der [Richtlinien-Funktion](https://docs.gitlab.com/user/application_security/policies/) von GitLab können Benutzer(innen) [Scanausführungs-](https://docs.gitlab.com/user/application_security/policies/scan-execution-policies/) und [Scanergebnis-Richtlinien](https://docs.gitlab.com/user/application_security/policies/scan-result-policies/) basierend auf konfigurierter Logik implementieren. Diese Richtlinien kombinieren die Scan-Funktionen in der [Sicherungsphase](https://about.gitlab.com/pricing/feature-comparison/) mit [Freigaben für Merge Requests](https://docs.gitlab.com/user/project/merge_requests/approvals/), um die Compliance-Anforderungen weiter durchzusetzen.\n\nZusammen bilden die Sicherheitsfunktionen von GitLab die optimale Grundlage für einen sicheren Lebenszyklus der Softwareentwicklung und ermöglichen es dir, die Prinzipien des sicheren Programmierens sowie die Anforderungen deines Unternehmens einzuhalten.\n\n\u003Cbr>\n\n| Control-ID | Control-Beschreibung |\n| ---- | ----|\n| 8.32 Änderungsmanagement | Änderungen an Informationsverarbeitungseinrichtungen und Informationssystemen unterliegen den Änderungsmanagementverfahren. |\n\nGitLab bietet viele Funktionen, um ein umfassendes Änderungsmanagement zu unterstützen.\n\nMit der Quellcodeverwaltung von GitLab können Benutzer(innen) [geschützte Branches](https://docs.gitlab.com/user/project/protected_branches/) implementieren. Geschützte Branches ermöglichen es GitLab-Benutzer(inne)n, bestimmte Branches einzuschränken, die als kritisch für den Betrieb angesehen werden. Ein geschützter Branch steuert:\n\n* welche Benutzer(innen) in den Branch mergen können\n\n* welche Benutzer(innen) in den Branch pushen können\n\n* wenn Benutzer(innen) den Push in den Branch erzwingen können\n\n* ob Änderungen an Dateien, die in der CODEOWNERS-Datei aufgeführt sind, direkt in den Branch gepusht werden können\n\n* welche Benutzer(innen) den Schutz des Branches aufheben können\n\nDer [Standard-Branch](https://docs.gitlab.com/user/project/repository/branches/default/) in einem Repository wird automatisch als geschützter Branch gekennzeichnet.\n\n![Geschützte Branches](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/protected-branches-settings-within-gitlab.png)\n\nEinstellungen für geschützte Branches in GitLab\n\n\nMerge Requests (MR) sind eine Kernkomponente des Softwareentwicklungszyklus. GitLab-Benutzer(innen) können ihre MRs so konfigurieren, dass sie erst freigegeben werden müssen, bevor sie zusammengeführt werden können. Mit MR-Genehmigungen können Benutzer(innen) die Mindestanzahl der erforderlichen Genehmigungen festlegen, bevor Arbeiten in ein Projekt zusammengeführt werden können. Einige Beispiele für Regeln, die du erstellen kannst, sind:\n\n* Benutzer(innen) mit bestimmten Berechtigungen können Arbeiten jederzeit genehmigen.\n\n* [Code-Eigentümer(innen)](https://docs.gitlab.com/user/project/codeowners/) können Arbeiten für Dateien genehmigen, die sie besitzen.\n\n* Benutzer(innen) mit bestimmten Berechtigungen können Arbeiten im Repository genehmigen, [auch wenn sie keine Merge-Rechte haben](https://docs.gitlab.com/user/project/merge_requests/approvals/rules/#merge-request-approval-segregation-of-duties).\n\n* Benutzer(inne)n mit bestimmten Berechtigungen kann die Möglichkeit gewährt oder verweigert werden, [Genehmigungsregeln für eine bestimmte Merge Request zu überschreiben](https://docs.gitlab.com/user/project/merge_requests/approvals/rules/#edit-or-override-merge-request-approval-rules).\n\nWie bereits erwähnt, können [Tickets](https://docs.gitlab.com/user/project/issues/) und [Aufgaben](https://docs.gitlab.com/user/tasks/) verwendet werden, um Änderungsanfragen zu dokumentieren und zusammenzuarbeiten. [Beschreibungsvorlagen](https://docs.gitlab.com/user/project/description_templates/) ermöglichen es den Benutzer(inne)n, konsistente Beschreibungen für Tickets oder [MRs](https://docs.gitlab.com/user/project/merge_requests/) einzuhalten. Mit diesen Vorlagen kann ein konsistenter Ansatz verfolgt werden, um Änderungen in einer Weise anzufordern, die am besten zu deinem Unternehmen passt.\n\n> **Von 18 auf 3 Monate: So beschleunigt die Deutsche Telekom ihre Releases mit GitLab** 13.000 Entwickler(innen) arbeiten effizienter zusammen und bringen Produkte 6x schneller auf den Markt – erfahre, wie GitLab Ultimate die DevSecOps-Transformation vorantreibt, Silos aufbricht und Sicherheit in den Entwicklungsprozess bringt. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/deutsche-telekom/)\n\n## Mehr erfahren\n\nAls umfassende DevSecOps-Plattform unterstützt GitLab ein breites Spektrum an Anforderungen. ISO hat in der Version 2022 der ISO-Norm zusätzliche Controls für sicheres Programmieren und Konfigurationsmanagement hinzugefügt. Dies zeigt, dass Zertifizierungsstellen insgesamt einen verstärkten Fokus auf die Softwaresicherheit legen. Als strategischer Partner kann GitLab dir dabei helfen, die ISO 27001 einzuhalten und schneller bessere Software zu entwickeln.\n\nWeitere Informationen zu diesen Funktionen findest du in unserer [Tutorial-Bibliothek](https://docs.gitlab.com/tutorials/).","security",{"slug":13,"featured":14,"template":15},"how-gitlab-can-support-your-iso-compliance-journey",false,"BlogPost",{"heroImage":17,"body":10,"authors":18,"updatedDate":19,"date":20,"title":5,"tags":21,"description":24,"category":11},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662877/Blog/Hero%20Images/security-cover-new.png",[9],"2025-04-22","2023-09-06",[11,22,23],"features","customers","GitLab ist dein strategischer Partner und hilft mit seinen Software-Sicherheitsfunktionen dabei, deine ISO-27001-Compliance sicherzustellen.","yml",null,{},true,"/de-de/blog/how-gitlab-can-support-your-iso-compliance-journey","seo:\n  ogTitle: So unterstützt dich GitLab bei deiner ISO-27001-Compliance\n  ogImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662877/Blog/Hero%20Images/security-cover-new.png\n  ogDescription: GitLab ist dein strategischer Partner und hilft mit seinen\n    Software-Sicherheitsfunktionen dabei, deine ISO-27001-Compliance\n    sicherzustellen.\n  ogSiteName: https://about.gitlab.com\n  noIndex: false\n  ogType: article\n  ogUrl: https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey\n  title: So unterstützt dich GitLab bei deiner ISO-27001-Compliance\n  canonicalUrls: https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey\n  description: GitLab ist dein strategischer Partner und hilft mit seinen\n    Software-Sicherheitsfunktionen dabei, deine ISO-27001-Compliance\n    sicherzustellen.\ncontent:\n  heroImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662877/Blog/Hero%20Images/security-cover-new.png\n  body: >-\n    Als eine durchgängige All-Inclusive-Plattform ist es mit GitLab einfach,\n    deinen DevSecOps-Lebenszyklus zu verwalten. Dank der Plattform von GitLab\n    können Entwickler(innen) schneller bessere Software entwickeln. Das ist aber\n    nicht alles, denn GitLab geht über DevSecOps hinaus.\n\n\n    Im Oktober 2022 veröffentlichte die Internationale Organisation für Normung\n    die neueste Version der Norm ISO 27001. ISO/IEC 27001:2022 enthält mehrere\n    Änderungen gegenüber der vorherigen Version, darunter die neuen Control\n    Kategorien aus Anhang A, bei denen es um sicheres Programmieren und\n    Konfigurationsmanagement geht.\n\n\n    Wir bei GitLab nutzen unsere Plattform, um viele Aspekte unseres\n    Sicherheitskonformitätsprogramms zu unterstützen – ein Konzept, das wir\n    intern [Dogfooding](https://handbook.gitlab.com/handbook/product/product-processes/dogfooding-for-r-d/) nennen.\n    Eine Übersicht über den Nachweis der Einhaltung von Vorschriften und\n    Sicherheit findest du in unserem [Trust\n    Center](https://about.gitlab.com/security/).\n\n\n    Sehen wir uns nun die wichtigsten Funktionen an, die du bei deiner\n    ISO-27001-Compliance nutzen kannst.\n\n\n    ## Organisatorische Controls\n\n\n\n    | Control-ID | Control-Beschreibung |\n\n    | ---- | ---- |\n\n    | 5.3 Aufgabentrennung | Widersprüchliche Aufgaben und\n    Verantwortungsbereiche sind zu trennen. |\n\n    | 5.15 Zugriffskontrolle | Regeln zur Kontrolle des physischen und logischen\n    Zugriffs auf Informationen und andere damit verbundene Vermögenswerte müssen\n    auf der Grundlage der Geschäfts- und Informationssicherheitsanforderungen\n    festgelegt und implementiert werden. |\n\n    | 5.16 Identitätsmanagement | Der gesamte Lebenszyklus von Identitäten ist\n    zu verwalten. |\n\n    | 8.2 Privilegierte Zugriffsrechte | Die Vergabe und Nutzung von\n    privilegierten Zugriffsrechten ist einzuschränken und zu verwalten.|\n\n    | 8.4 Zugriff auf Quellcode | Der Lese- und Schreibzugriff auf Quellcode,\n    Entwicklungstools und Softwarebibliotheken ist angemessen zu verwalten. |\n\n\n\n    Mit GitLab kannst du [Benutzer(inne)n eine Rolle\n    zuweisen](https://docs.gitlab.com/user/permissions/), wenn du sie zu\n    einem Projekt oder einer Gruppe hinzufügst. Die Rolle eines Benutzers/einer\n    Benutzerin legt fest, was er/sie in deiner GitLab-Instanz ausführen kann.\n    Folgende Rollen stehen für die Zuweisung zur Verfügung:\n\n\n    * Gast (nur private und interne Projekte)\n\n\n    * Reporter(in)\n\n\n    * Entwickler(in)\n\n\n    * Betreuer(in)\n\n\n    * Eigentümer(in)\n\n\n    * Minimaler Zugriff (nur für die Hauptgruppe verfügbar)\n\n\n    Mit den Rollen von GitLab kannst du die Berechtigungen eines Benutzers/einer\n    Benutzerin gemäß dem [Prinzip der geringsten\n    Privilegien](https://csrc.nist.gov/glossary/term/least_privilege) und deinen\n    Geschäfts- und Informationssicherheitsanforderungen einschränken.\n\n\n    Außerdem kannst du dank GitLab die Authentifizierungs- und\n    Autorisierungsverantwortlichkeiten für deine GitLab-Instanz über\n    [SAML-SSO-Integrationen](https://docs.gitlab.com/user/group/saml_sso/)\n    zentralisieren. GitLab lässt sich in eine Vielzahl von Identitätsanbietern\n    integrieren, um die verschiedenen Technologie-Stacks unserer Kund(inn)en zu\n    unterstützen. GitLab unterstützt auch das System für domänenübergreifendes\n    Identitätsmanagement\n    ([SCIM](https://docs.gitlab.com/user/group/saml_sso/scim_setup/)).\n    Durch die SSO- und SCIM-Integrationen von GitLab kannst du den Lebenszyklus\n    deiner Benutzeridentitäten sicher und effizient automatisieren.\n\n\n    [SSO](https://docs.gitlab.com/integration/saml/) und\n    [SCIM](https://docs.gitlab.com/administration/settings/scim_setup/)\n    sind auch für selbstverwaltete Kund(inn)en von GitLab verfügbar.\n\n\n    **Hinweis:** Die technologischen Controls 8.2 und 8.4 in Anhang 8 wurden\n    aufgrund ihrer Nähe zu den organisatorischen Controls 5.3, 5.15 und 5.16 in\n    die oben stehende Tabelle aufgenommen. Für die Anforderungen dieser Controls\n    können die gleichen GitLab-Funktionen angewendet werden.\n\n\n\n    \u003Cbr>\n\n\n    | Control-ID | Control-Beschreibung |\n\n    | ---- | ---- |\n\n    | 5.8 Informationssicherheit im Projektmanagement | Informationssicherheit\n    ist in das Projektmanagement zu integrieren. |\n\n\n    Mit GitLab kannst du unsere\n    [Planungstools](https://about.gitlab.com/pricing/feature-comparison/) für\n    dein Projektmanagement nutzen und so sicherstellen, dass die\n    Informationssicherheit in allen Phasen eines Projektlebenszyklus eingehalten\n    wird.\n\n\n    - Mit der\n    [Teamplanung](https://about.gitlab.com/pricing/feature-comparison/#team_planning)\n    von GitLab können Benutzer(innen) Projektarbeiten von der Idee bis zur\n    Produktion organisieren, planen, abstimmen und nachverfolgen.\n\n\n    - [Epics](https://docs.gitlab.com/user/group/epics/),\n    [Tickets](https://docs.gitlab.com/user/project/issues/) und\n    [Aufgaben](https://docs.gitlab.com/user/tasks/) können verwendet\n    werden, um gemeinsam an Ideen zu arbeiten, Probleme zu lösen und Arbeiten\n    mit deinem Informationssicherheitsteam zu planen.\n    [Beschreibungsvorlagen](https://docs.gitlab.com/user/project/description_templates/)\n    und [Checklisten](https://docs.gitlab.com/user/markdown/#task-lists)\n    ermöglichen es den Benutzer(inne)n, konsistente Beschreibungen und Workflows\n    für Tickets oder [Merge\n    Requests](https://docs.gitlab.com/user/project/merge_requests/)\n    einzuhalten. Mit diesen Vorlagen kann die Informationssicherheit konsistent\n    in deinen Projektmanagement-Lebenszyklus integriert werden.\n\n\n    - [Labels](https://docs.gitlab.com/user/project/labels/) ermöglichen\n    es Benutzer(inne)n, Probleme so zu organisieren, wie sie es für richtig\n    halten. Im Hinblick auf die Informationssicherheit können Label verwendet\n    werden, um die Risikostufe eines Projekts zu identifizieren, die Phase eines\n    Projekts anzugeben oder das Informationssicherheitsteam zu markieren, das\n    für eine bestimmte Arbeit zuständig ist. [Labels mit begrenztem\n    Geltungsbereich](https://docs.gitlab.com/user/project/labels/#scoped-labels)\n    können verwendet werden, um Workflows weitere Logik hinzuzufügen. Sie\n    verhindern nämlich, dass bestimmte Labels zusammen verwendet werden. Bei\n    GitLab nutzen wir [Labels mit begrenztem\n    Geltungsbereich](https://docs.gitlab.com/user/project/labels/#scoped-labels),\n    um die Arbeit, die verschiedenen Teams zugewiesen ist, die Projektphase, in\n    der sich die Arbeit befindet, und das Produkt oder den Funktionsumfang, der\n    mit der Arbeit verbunden ist, zu identifizieren.\n\n\n    ![Labels mit begrenztem\n    Geltungsbereich](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/scoped-labels.png)\n\n\n    Labels mit begrenztem Geltungsbereich\n\n\n\n    - Mit\n    [Gruppen-](https://docs.gitlab.com/user/project/issue_board/#group-issue-boards)\n    und\n    [Projekt-](https://docs.gitlab.com/user/project/issue_board/)-Issue-Übersichten\n    kannst du deine Arbeit noch besser organisieren und eine zentrale,\n    zusammengefasste Ansicht für alle mit einer Gruppe oder einem Projekt\n    verbundenen Arbeiten bieten.\n\n\n    ## Technologische Controls\n\n\n    | Control-ID | Control-Beschreibung |\n\n    | ---- | ---- |\n\n    | 8.8 Management technischer Sicherheitslücken | Informationen über\n    technische Sicherheitslücken der verwendeten Informationssysteme sind\n    einzuholen, die Exposition des Unternehmens gegenüber solchen\n    Sicherheitslücken ist zu bewerten und geeignete Maßnahmen sind zu ergreifen.\n    |\n\n    | 8.9 Konfigurationsmanagement | Konfigurationen von Hardware, Software,\n    Diensten und Netzwerken, einschließlich Sicherheitskonfigurationen, müssen\n    festgelegt, dokumentiert, implementiert, überwacht und überprüft werden. |\n\n    | 8.25 Sicherer Entwicklungslebenszyklus | Regeln für die sichere\n    Entwicklung von Software und Systemen müssen festgelegt und angewendet\n    werden. |\n\n    | 8.26 Anforderungen an die Anwendungssicherheit | Anforderungen an die\n    Informationssicherheit müssen bei der Entwicklung oder dem Erwerb von\n    Anwendungen identifiziert, spezifiziert und genehmigt werden. |\n\n    | 8.27 Sichere Systemarchitektur und technische Grundsätze | Grundsätze für\n    die Entwicklung sicherer Systeme müssen festgelegt, dokumentiert, gepflegt\n    und bei allen Entwicklungsaktivitäten von Informationssystemen angewendet\n    werden |\n\n\n    Mit GitLab kannst du deine Hardware- und Softwarekonfigurationen speichern,\n    die Versionskontrolle verwalten, deine Konfigurationen über [Merge\n    Requests](https://docs.gitlab.com/user/project/merge_requests/)\n    aktualisieren und die\n    [CI/CD-Pipelines](https://docs.gitlab.com/ci/pipelines/) von GitLab\n    nutzen, um diese Konfigurationen in deine Anwendungen und Infrastruktur zu\n    übertragen. Mit GitLab können Unternehmen\n    [GitOps](https://about.gitlab.com/topics/gitops/) über eine einzige\n    Plattform implementieren.\n\n\n    Mit dem\n    [Infrastructure-as-Code-Scanning](https://docs.gitlab.com/user/application_security/iac_scanning/)\n    von GitLab kannst du deine IaC-Konfigurationsdateien auf bekannte\n    Sicherheitslücken scannen. Das IaC-Scanning von GitLab unterstützt eine\n    Vielzahl von IaC-Konfigurationsdateien und -Sprachen, wodurch es an\n    verschiedene Technologie-Stacks angepasst werden kann.\n\n\n    Für Compliance-Profis ermöglicht GitLab die Implementierung von\n    Automatisierung durch\n    [Compliance-Frameworks](https://docs.gitlab.com/user/group/compliance_frameworks/)\n    und\n    [Compliance-Pipelines](https://docs.gitlab.com/user/group/compliance_frameworks/#compliance-pipelines).\n    Dank dieser Funktionen können Benutzer(innen) kritische Projekte mit\n    bestimmten Compliance-Anforderungen identifizieren und Konfigurationen über\n    Pipelines an diese Projekte pushen. Sie ermöglichen eine konsistente\n    Durchsetzung der Controls und unterstützen dadurch deine Sicherheitslage.\n    Außerdem stellen sie sicher, dass die internen und externen\n    Compliance-Anforderungen deines Unternehmens eingehalten werden.\n\n\n    Für [Ultimate-Kund(inn)en](https://about.gitlab.com/pricing/ultimate/)\n    bietet das [Compliance\n    Center](https://docs.gitlab.com/user/compliance/compliance_center/)\n    von GitLab eine zentrale Ansicht des Compliance-Zustands einer Gruppe, z. B.\n    der verschiedenen Compliance Frameworks, die auf die Projekte in der Gruppe\n    angewendet werden. Du kannst sogar sehen, wie gut du den\n    [GitLab-Standard](https://docs.gitlab.com/user/compliance/compliance_center/#gitlab-standard)\n    erfüllst.\n\n\n    \u003Cbr>\n\n\n    | Control-ID | Control-Beschreibung |\n\n    | ---- | ---- |\n\n    | 8.15 Protokollierung | Protokolle, die Aktivitäten, Ausnahmen, Fehler und\n    andere relevante Ereignisse aufzeichnen, sind zu erstellen, zu speichern, zu\n    schützen und zu analysieren. |\n\n    | 8.16 Kontrolle von Überwachungsaktivitäten | Netzwerke, Systeme und\n    Anwendungen müssen auf anomales Verhalten überwacht und geeignete Maßnahmen\n    zur Bewertung potenzieller Informationssicherheitsvorfälle ergriffen werden.\n    |\n\n\n    Mit GitLab kannst du\n    [Audit-Ereignisse](https://docs.gitlab.com/administration/audit_events/)\n    verwenden, um wichtige Ereignisse zu verfolgen, einschließlich der Frage,\n    wer wann die entsprechende Aktion durchgeführt hat. Audit-Ereignisse decken\n    ein breites Spektrum von Kategorien ab, darunter:\n\n\n    * Gruppenverwaltung\n\n\n    * Authentifizierung und Autorisierung\n\n\n    * Benutzerverwaltung\n\n\n    * Compliance und Sicherheit\n\n\n    * CI/CD\n\n\n    * GitLab-Runner\n\n\n    ![Audit-Ereignisse](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/example-of-an-audit-event.png)\n\n\n    Beispiel für ein Audit-Ereignis\n\n\n\n    Für [Ultimate-Kund(inn)en](https://about.gitlab.com/pricing/ultimate/) kann\n    das\n    [Audit-Ereignis-Streaming](https://docs.gitlab.com/administration/audit_event_streaming/)\n    aktiviert werden. Mit dem Audit-Ereignis-Streaming können Benutzer(innen)\n    ein Streaming-Ziel für eine Gruppe oder Instanz der obersten Ebene\n    festlegen, um alle Audit-Ereignisse über die Gruppe, Untergruppen und\n    Projekte als strukturierte JSON-Datei zu erhalten.\n\n\n    \u003Cbr>\n\n\n    | Control-ID | Control-Beschreibung |\n\n    | ---- | ---- |\n\n    | 8.28 Sichere Programmierung | Bei der Softwareentwicklung sind die\n    Prinzipien des sicheren Programmierens anzuwenden. |\n\n    | 8.29 Sicherheitstests in Entwicklung und Akzeptanz |\n    Sicherheitstestprozesse sind im Entwicklungslebenszyklus zu definieren und\n    umzusetzen. |\n\n\n    Du kannst die Funktionen in der\n    [Sicherungsphase](https://about.gitlab.com/pricing/feature-comparison/) von\n    GitLab nutzen, um den Lebenszyklus deiner Softwareentwicklung zu verbessern\n    und die Sicherheit deiner Produkte zu verbessern. Zu den Funktionen von\n    GitLab in der Sicherungsphase gehören:\n\n\n    * [Statische Anwendungssicherheitstests\n    (SAST)](https://docs.gitlab.com/user/application_security/sast/)\n\n\n    * [Dynamische Anwendungssicherheitstests\n    (DAST)](https://docs.gitlab.com/user/application_security/dast/)\n\n\n    * [Codequalität](https://docs.gitlab.com/ci/testing/code_quality/)\n\n\n    *\n    [Container-Scanning](https://docs.gitlab.com/user/application_security/container_scanning/)\n\n\n    *\n    [Abhängigkeitssuche](https://docs.gitlab.com/user/application_security/dependency_scanning/)\n\n\n    und vieles mehr!\n\n\n    ![Ergebnisse zur\n    Codequalität](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/code-quality-findings.png)\n\n\n    Ergebnisse zur Codequalität\n\n\n\n    Kompromittierte Geheimnisse sind einer der führenden Katalysatoren für\n    Sicherheitsverletzungen. Die [Erkennung von\n    Geheimnissen](https://docs.gitlab.com/user/application_security/secret_detection/)\n    von GitLab scannt dein Repository, um zu verhindern, dass deine Geheimnisse\n    aufgedeckt werden.\n\n\n    Mit der\n    [Richtlinien-Funktion](https://docs.gitlab.com/user/application_security/policies/)\n    von GitLab können Benutzer(innen)\n    [Scanausführungs-](https://docs.gitlab.com/user/application_security/policies/scan-execution-policies/)\n    und\n    [Scanergebnis-Richtlinien](https://docs.gitlab.com/user/application_security/policies/scan-result-policies/)\n    basierend auf konfigurierter Logik implementieren. Diese Richtlinien\n    kombinieren die Scan-Funktionen in der\n    [Sicherungsphase](https://about.gitlab.com/pricing/feature-comparison/) mit\n    [Freigaben für Merge\n    Requests](https://docs.gitlab.com/user/project/merge_requests/approvals/),\n    um die Compliance-Anforderungen weiter durchzusetzen.\n\n\n    Zusammen bilden die Sicherheitsfunktionen von GitLab die optimale Grundlage\n    für einen sicheren Lebenszyklus der Softwareentwicklung und ermöglichen es\n    dir, die Prinzipien des sicheren Programmierens sowie die Anforderungen\n    deines Unternehmens einzuhalten.\n\n\n    \u003Cbr>\n\n\n    | Control-ID | Control-Beschreibung |\n\n    | ---- | ----|\n\n    | 8.32 Änderungsmanagement | Änderungen an\n    Informationsverarbeitungseinrichtungen und Informationssystemen unterliegen\n    den Änderungsmanagementverfahren. |\n\n\n    GitLab bietet viele Funktionen, um ein umfassendes Änderungsmanagement zu\n    unterstützen.\n\n\n    Mit der Quellcodeverwaltung von GitLab können Benutzer(innen) [geschützte\n    Branches](https://docs.gitlab.com/user/project/protected_branches/)\n    implementieren. Geschützte Branches ermöglichen es GitLab-Benutzer(inne)n,\n    bestimmte Branches einzuschränken, die als kritisch für den Betrieb\n    angesehen werden. Ein geschützter Branch steuert:\n\n\n    * welche Benutzer(innen) in den Branch mergen können\n\n\n    * welche Benutzer(innen) in den Branch pushen können\n\n\n    * wenn Benutzer(innen) den Push in den Branch erzwingen können\n\n\n    * ob Änderungen an Dateien, die in der CODEOWNERS-Datei aufgeführt sind,\n    direkt in den Branch gepusht werden können\n\n\n    * welche Benutzer(innen) den Schutz des Branches aufheben können\n\n\n    Der\n    [Standard-Branch](https://docs.gitlab.com/user/project/repository/branches/default/)\n    in einem Repository wird automatisch als geschützter Branch gekennzeichnet.\n\n\n    ![Geschützte\n    Branches](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/protected-branches-settings-within-gitlab.png)\n\n\n    Einstellungen für geschützte Branches in GitLab\n\n\n\n    Merge Requests (MR) sind eine Kernkomponente des Softwareentwicklungszyklus.\n    GitLab-Benutzer(innen) können ihre MRs so konfigurieren, dass sie erst\n    freigegeben werden müssen, bevor sie zusammengeführt werden können. Mit\n    MR-Genehmigungen können Benutzer(innen) die Mindestanzahl der erforderlichen\n    Genehmigungen festlegen, bevor Arbeiten in ein Projekt zusammengeführt\n    werden können. Einige Beispiele für Regeln, die du erstellen kannst, sind:\n\n\n    * Benutzer(innen) mit bestimmten Berechtigungen können Arbeiten jederzeit\n    genehmigen.\n\n\n    *\n    [Code-Eigentümer(innen)](https://docs.gitlab.com/user/project/codeowners/)\n    können Arbeiten für Dateien genehmigen, die sie besitzen.\n\n\n    * Benutzer(innen) mit bestimmten Berechtigungen können Arbeiten im\n    Repository genehmigen, [auch wenn sie keine Merge-Rechte\n    haben](https://docs.gitlab.com/user/project/merge_requests/approvals/rules/#merge-request-approval-segregation-of-duties).\n\n\n    * Benutzer(inne)n mit bestimmten Berechtigungen kann die Möglichkeit gewährt\n    oder verweigert werden, [Genehmigungsregeln für eine bestimmte Merge Request\n    zu\n    überschreiben](https://docs.gitlab.com/user/project/merge_requests/approvals/rules/#edit-or-override-merge-request-approval-rules).\n\n\n    Wie bereits erwähnt, können\n    [Tickets](https://docs.gitlab.com/user/project/issues/) und\n    [Aufgaben](https://docs.gitlab.com/user/tasks/) verwendet werden, um\n    Änderungsanfragen zu dokumentieren und zusammenzuarbeiten.\n    [Beschreibungsvorlagen](https://docs.gitlab.com/user/project/description_templates/)\n    ermöglichen es den Benutzer(inne)n, konsistente Beschreibungen für Tickets\n    oder\n    [MRs](https://docs.gitlab.com/user/project/merge_requests/)\n    einzuhalten. Mit diesen Vorlagen kann ein konsistenter Ansatz verfolgt\n    werden, um Änderungen in einer Weise anzufordern, die am besten zu deinem\n    Unternehmen passt.\n\n\n    > **Von 18 auf 3 Monate: So beschleunigt die Deutsche Telekom ihre Releases\n    mit GitLab** 13.000 Entwickler(innen) arbeiten effizienter zusammen und\n    bringen Produkte 6x schneller auf den Markt – erfahre, wie GitLab Ultimate\n    die DevSecOps-Transformation vorantreibt, Silos aufbricht und Sicherheit in\n    den Entwicklungsprozess bringt. [Erfolgsstory\n    lesen](https://about.gitlab.com/de-de/customers/deutsche-telekom/)\n\n\n    ## Mehr erfahren\n\n\n    Als umfassende DevSecOps-Plattform unterstützt GitLab ein breites Spektrum\n    an Anforderungen. ISO hat in der Version 2022 der ISO-Norm zusätzliche\n    Controls für sicheres Programmieren und Konfigurationsmanagement\n    hinzugefügt. Dies zeigt, dass Zertifizierungsstellen insgesamt einen\n    verstärkten Fokus auf die Softwaresicherheit legen. Als strategischer\n    Partner kann GitLab dir dabei helfen, die ISO 27001 einzuhalten und\n    schneller bessere Software zu entwickeln.\n\n\n    Weitere Informationen zu diesen Funktionen findest du in unserer\n    [Tutorial-Bibliothek](https://docs.gitlab.com/tutorials/).\n  authors:\n    - Joseph Longo\n  updatedDate: 2025-04-22\n  date: 2023-09-06\n  title: So unterstützt dich GitLab bei deiner ISO-27001-Compliance\n  tags:\n    - security\n    - features\n    - customers\n  description: GitLab ist dein strategischer Partner und hilft mit seinen\n    Software-Sicherheitsfunktionen dabei, deine ISO-27001-Compliance\n    sicherzustellen.\n  category: security\nconfig:\n  slug: how-gitlab-can-support-your-iso-compliance-journey\n  featured: false\n  template: BlogPost\n",{"ogTitle":5,"ogImage":17,"ogDescription":24,"ogSiteName":32,"noIndex":14,"ogType":33,"ogUrl":34,"title":5,"canonicalUrls":34,"description":24},"https://about.gitlab.com","article","https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey","de-de/blog/how-gitlab-can-support-your-iso-compliance-journey",[11,22,23],[11,22,23],"eYprWmlYklZInFiDLvzFmO6m_ETvywCKWe3-aK3KqOY",{"data":40},{"logo":41,"freeTrial":46,"sales":51,"login":56,"items":61,"search":371,"minimal":405,"duo":423,"switchNav":432,"pricingDeployment":443},{"config":42},{"href":43,"dataGaName":44,"dataGaLocation":45},"/de-de/","gitlab logo","header",{"text":47,"config":48},"Kostenlose Testversion anfordern",{"href":49,"dataGaName":50,"dataGaLocation":45},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de&glm_content=default-saas-trial/","free trial",{"text":52,"config":53},"Vertrieb kontaktieren",{"href":54,"dataGaName":55,"dataGaLocation":45},"/de-de/sales/","sales",{"text":57,"config":58},"Anmelden",{"href":59,"dataGaName":60,"dataGaLocation":45},"https://gitlab.com/users/sign_in/","sign in",[62,89,186,191,292,352],{"text":63,"config":64,"cards":66},"Plattform",{"dataNavLevelOne":65},"platform",[67,73,81],{"title":63,"description":68,"link":69},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":70,"config":71},"Die Plattform erkunden",{"href":72,"dataGaName":65,"dataGaLocation":45},"/de-de/platform/",{"title":74,"description":75,"link":76},"GitLab Duo Agent Platform","Agentische KI für den gesamten Software-Lebenszyklus",{"text":77,"config":78},"Lerne GitLab Duo kennen",{"href":79,"dataGaName":80,"dataGaLocation":45},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":82,"description":83,"link":84},"Warum GitLab?","Erfahre, warum sich Unternehmen für GitLab entscheiden",{"text":85,"config":86},"Mehr erfahren",{"href":87,"dataGaName":88,"dataGaLocation":45},"/de-de/why-gitlab/","why gitlab",{"text":90,"left":28,"config":91,"link":93,"lists":97,"footer":168},"Produkt",{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"Alle Lösungen anzeigen",{"href":96,"dataGaName":92,"dataGaLocation":45},"/de-de/solutions/",[98,123,146],{"title":99,"description":100,"link":101,"items":106},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":45},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[107,111,114,119],{"text":108,"config":109},"CI/CD",{"href":110,"dataGaLocation":45,"dataGaName":108},"/de-de/solutions/continuous-integration/",{"text":74,"config":112},{"href":79,"dataGaLocation":45,"dataGaName":113},"gitlab duo agent platform - product menu",{"text":115,"config":116},"Quellcodeverwaltung",{"href":117,"dataGaLocation":45,"dataGaName":118},"/de-de/solutions/source-code-management/","Source Code Management",{"text":120,"config":121},"Automatische Softwarebereitstellung",{"href":104,"dataGaLocation":45,"dataGaName":122},"Automated software delivery",{"title":124,"description":125,"link":126,"items":131},"Sicherheit","Entwickle Code schneller ohne Abstriche bei der Sicherheit",{"config":127},{"href":128,"dataGaName":129,"dataGaLocation":45,"icon":130},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[132,136,141],{"text":133,"config":134},"Anwendungssicherheitstests",{"href":128,"dataGaName":135,"dataGaLocation":45},"Application security testing",{"text":137,"config":138},"Schutz der Software-Lieferkette",{"href":139,"dataGaLocation":45,"dataGaName":140},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":142,"config":143},"Software-Compliance",{"href":144,"dataGaName":145,"dataGaLocation":45},"/de-de/solutions/software-compliance/","software compliance",{"title":147,"link":148,"items":153},"Auswertung",{"config":149},{"icon":150,"href":151,"dataGaName":152,"dataGaLocation":45},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[154,158,163],{"text":155,"config":156},"Sichtbarkeit und Auswertung",{"href":151,"dataGaLocation":45,"dataGaName":157},"Visibility and Measurement",{"text":159,"config":160},"Wertstrommanagement",{"href":161,"dataGaLocation":45,"dataGaName":162},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":164,"config":165},"Analysen und Einblicke",{"href":166,"dataGaLocation":45,"dataGaName":167},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":169,"items":170},"GitLab für",[171,176,181],{"text":172,"config":173},"Enterprise",{"href":174,"dataGaLocation":45,"dataGaName":175},"/de-de/enterprise/","enterprise",{"text":177,"config":178},"Kleinunternehmen",{"href":179,"dataGaLocation":45,"dataGaName":180},"/de-de/small-business/","small business",{"text":182,"config":183},"Öffentlicher Sektor",{"href":184,"dataGaLocation":45,"dataGaName":185},"/de-de/solutions/public-sector/","public sector",{"text":187,"config":188},"Preise",{"href":189,"dataGaName":190,"dataGaLocation":45,"dataNavLevelOne":190},"/de-de/pricing/","pricing",{"text":192,"config":193,"link":195,"lists":199,"feature":279},"Ressourcen",{"dataNavLevelOne":194},"resources",{"text":196,"config":197},"Alle Ressourcen anzeigen",{"href":198,"dataGaName":194,"dataGaLocation":45},"/de-de/resources/",[200,233,251],{"title":201,"items":202},"Erste Schritte",[203,208,213,218,223,228],{"text":204,"config":205},"Installieren",{"href":206,"dataGaName":207,"dataGaLocation":45},"/de-de/install/","install",{"text":209,"config":210},"Kurzanleitungen",{"href":211,"dataGaName":212,"dataGaLocation":45},"/de-de/get-started/","quick setup checklists",{"text":214,"config":215},"Lernen",{"href":216,"dataGaLocation":45,"dataGaName":217},"https://university.gitlab.com/","learn",{"text":219,"config":220},"Produktdokumentation",{"href":221,"dataGaName":222,"dataGaLocation":45},"https://docs.gitlab.com/","product documentation",{"text":224,"config":225},"Best-Practice-Videos",{"href":226,"dataGaName":227,"dataGaLocation":45},"/de-de/getting-started-videos/","best practice videos",{"text":229,"config":230},"Integrationen",{"href":231,"dataGaName":232,"dataGaLocation":45},"/de-de/integrations/","integrations",{"title":234,"items":235},"Entdecken",[236,241,246],{"text":237,"config":238},"Kundenerfolge",{"href":239,"dataGaName":240,"dataGaLocation":45},"/de-de/customers/","customer success stories",{"text":242,"config":243},"Blog",{"href":244,"dataGaName":245,"dataGaLocation":45},"/de-de/blog/","blog",{"text":247,"config":248},"Remote",{"href":249,"dataGaName":250,"dataGaLocation":45},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":252,"items":253},"Vernetzen",[254,259,264,269,274],{"text":255,"config":256},"GitLab Services",{"href":257,"dataGaName":258,"dataGaLocation":45},"/de-de/services/","services",{"text":260,"config":261},"Community",{"href":262,"dataGaName":263,"dataGaLocation":45},"/community/","community",{"text":265,"config":266},"Forum",{"href":267,"dataGaName":268,"dataGaLocation":45},"https://forum.gitlab.com/","forum",{"text":270,"config":271},"Veranstaltungen",{"href":272,"dataGaName":273,"dataGaLocation":45},"/events/","events",{"text":275,"config":276},"Partner",{"href":277,"dataGaName":278,"dataGaLocation":45},"/de-de/partners/","partners",{"background":280,"textColor":281,"text":282,"image":283,"link":287},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":284,"config":285},"The Source Promo-Karte",{"src":286},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":288,"config":289},"Aktuelles",{"href":290,"dataGaName":291,"dataGaLocation":45},"/de-de/the-source/","the source",{"text":293,"config":294,"lists":296},"Unternehmen",{"dataNavLevelOne":295},"company",[297],{"items":298},[299,304,310,312,317,322,327,332,337,342,347],{"text":300,"config":301},"Über",{"href":302,"dataGaName":303,"dataGaLocation":45},"/de-de/company/","about",{"text":305,"config":306,"footerGa":309},"Karriere",{"href":307,"dataGaName":308,"dataGaLocation":45},"/jobs/","jobs",{"dataGaName":308},{"text":270,"config":311},{"href":272,"dataGaName":273,"dataGaLocation":45},{"text":313,"config":314},"Geschäftsführung",{"href":315,"dataGaName":316,"dataGaLocation":45},"/company/team/e-group/","leadership",{"text":318,"config":319},"Team",{"href":320,"dataGaName":321,"dataGaLocation":45},"/company/team/","team",{"text":323,"config":324},"Handbuch",{"href":325,"dataGaName":326,"dataGaLocation":45},"https://handbook.gitlab.com/","handbook",{"text":328,"config":329},"Investor Relations",{"href":330,"dataGaName":331,"dataGaLocation":45},"https://ir.gitlab.com/","investor relations",{"text":333,"config":334},"Trust Center",{"href":335,"dataGaName":336,"dataGaLocation":45},"/de-de/security/","trust center",{"text":338,"config":339},"AI Transparency Center",{"href":340,"dataGaName":341,"dataGaLocation":45},"/de-de/ai-transparency-center/","ai transparency center",{"text":343,"config":344},"Newsletter",{"href":345,"dataGaName":346,"dataGaLocation":45},"/company/contact/#contact-forms","newsletter",{"text":348,"config":349},"Presse",{"href":350,"dataGaName":351,"dataGaLocation":45},"/press/","press",{"text":353,"config":354,"lists":355},"Kontakt",{"dataNavLevelOne":295},[356],{"items":357},[358,361,366],{"text":52,"config":359},{"href":54,"dataGaName":360,"dataGaLocation":45},"talk to sales",{"text":362,"config":363},"Support-Portal",{"href":364,"dataGaName":365,"dataGaLocation":45},"https://support.gitlab.com","support portal",{"text":367,"config":368},"Kundenportal",{"href":369,"dataGaName":370,"dataGaLocation":45},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":372,"login":373,"suggestions":380},"Schließen",{"text":374,"link":375},"Um Repositorys und Projekte zu durchsuchen, melde dich an bei",{"text":376,"config":377},"gitlab.com",{"href":59,"dataGaName":378,"dataGaLocation":379},"search login","search",{"text":381,"default":382},"Vorschläge",[383,385,390,392,397,402],{"text":74,"config":384},{"href":79,"dataGaName":74,"dataGaLocation":379},{"text":386,"config":387},"Codevorschläge (KI)",{"href":388,"dataGaName":389,"dataGaLocation":379},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":108,"config":391},{"href":110,"dataGaName":108,"dataGaLocation":379},{"text":393,"config":394},"GitLab auf AWS",{"href":395,"dataGaName":396,"dataGaLocation":379},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":398,"config":399},"GitLab auf Google Cloud",{"href":400,"dataGaName":401,"dataGaLocation":379},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":82,"config":403},{"href":87,"dataGaName":404,"dataGaLocation":379},"Why GitLab?",{"freeTrial":406,"mobileIcon":411,"desktopIcon":416,"secondaryButton":419},{"text":407,"config":408},"Kostenlos testen",{"href":409,"dataGaName":50,"dataGaLocation":410},"https://gitlab.com/-/trials/new/","nav",{"altText":412,"config":413},"GitLab-Symbol",{"src":414,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":412,"config":417},{"src":418,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":201,"config":420},{"href":421,"dataGaName":422,"dataGaLocation":410},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/get-started/","get started",{"freeTrial":424,"mobileIcon":428,"desktopIcon":430},{"text":425,"config":426},"Mehr über GitLab Duo erfahren",{"href":79,"dataGaName":427,"dataGaLocation":410},"gitlab duo",{"altText":412,"config":429},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":431},{"src":418,"dataGaName":415,"dataGaLocation":410},{"button":433,"mobileIcon":438,"desktopIcon":440},{"text":434,"config":435},"/Option",{"href":436,"dataGaName":437,"dataGaLocation":410},"#contact","switch",{"altText":412,"config":439},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":441},{"src":442,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":444,"mobileIcon":449,"desktopIcon":451},{"text":445,"config":446},"Zurück zur Preisübersicht",{"href":189,"dataGaName":447,"dataGaLocation":410,"icon":448},"back to pricing","GoBack",{"altText":412,"config":450},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":452},{"src":418,"dataGaName":415,"dataGaLocation":410},{"title":454,"button":455,"config":460},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":456,"config":457},"GitLab Transcend jetzt ansehen",{"href":458,"dataGaName":459,"dataGaLocation":45},"/de-de/events/transcend/virtual/","transcend event",{"layout":461,"icon":462,"disabled":28},"release","AiStar",{"data":464},{"text":465,"source":466,"edit":472,"contribute":477,"config":482,"items":487,"minimal":690},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":467,"config":468},"Quelltext der Seite anzeigen",{"href":469,"dataGaName":470,"dataGaLocation":471},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":473,"config":474},"Diese Seite bearbeiten",{"href":475,"dataGaName":476,"dataGaLocation":471},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":478,"config":479},"Beteilige dich",{"href":480,"dataGaName":481,"dataGaLocation":471},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":483,"facebook":484,"youtube":485,"linkedin":486},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[488,533,586,628,655],{"title":187,"links":489,"subMenu":504},[490,494,499],{"text":491,"config":492},"Tarife anzeigen",{"href":189,"dataGaName":493,"dataGaLocation":471},"view plans",{"text":495,"config":496},"Vorteile von Premium",{"href":497,"dataGaName":498,"dataGaLocation":471},"/de-de/pricing/premium/","why premium",{"text":500,"config":501},"Vorteile von Ultimate",{"href":502,"dataGaName":503,"dataGaLocation":471},"/de-de/pricing/ultimate/","why ultimate",[505],{"title":353,"links":506},[507,509,511,513,518,523,528],{"text":52,"config":508},{"href":54,"dataGaName":55,"dataGaLocation":471},{"text":362,"config":510},{"href":364,"dataGaName":365,"dataGaLocation":471},{"text":367,"config":512},{"href":369,"dataGaName":370,"dataGaLocation":471},{"text":514,"config":515},"Status",{"href":516,"dataGaName":517,"dataGaLocation":471},"https://status.gitlab.com/","status",{"text":519,"config":520},"Nutzungsbedingungen",{"href":521,"dataGaName":522,"dataGaLocation":471},"/terms/","terms of use",{"text":524,"config":525},"Datenschutzerklärung",{"href":526,"dataGaName":527,"dataGaLocation":471},"/de-de/privacy/","privacy statement",{"text":529,"config":530},"Cookie-Einstellungen",{"dataGaName":531,"dataGaLocation":471,"id":532,"isOneTrustButton":28},"cookie preferences","ot-sdk-btn",{"title":90,"links":534,"subMenu":543},[535,539],{"text":536,"config":537},"DevSecOps-Plattform",{"href":72,"dataGaName":538,"dataGaLocation":471},"devsecops platform",{"text":540,"config":541},"KI-unterstützte Entwicklung",{"href":79,"dataGaName":542,"dataGaLocation":471},"ai-assisted development",[544],{"title":545,"links":546},"Themen",[547,551,556,561,566,571,576,581],{"text":108,"config":548},{"href":549,"dataGaName":550,"dataGaLocation":471},"/de-de/topics/ci-cd/","cicd",{"text":552,"config":553},"GitOps",{"href":554,"dataGaName":555,"dataGaLocation":471},"/de-de/topics/gitops/","gitops",{"text":557,"config":558},"DevOps",{"href":559,"dataGaName":560,"dataGaLocation":471},"/de-de/topics/devops/","devops",{"text":562,"config":563},"Versionskontrolle",{"href":564,"dataGaName":565,"dataGaLocation":471},"/de-de/topics/version-control/","version control",{"text":567,"config":568},"DevSecOps",{"href":569,"dataGaName":570,"dataGaLocation":471},"/de-de/topics/devsecops/","devsecops",{"text":572,"config":573},"Cloud-nativ",{"href":574,"dataGaName":575,"dataGaLocation":471},"/de-de/topics/cloud-native/","cloud native",{"text":577,"config":578},"KI für das Programmieren",{"href":579,"dataGaName":580,"dataGaLocation":471},"/de-de/topics/devops/ai-for-coding/","ai for coding",{"text":582,"config":583},"Agentische KI",{"href":584,"dataGaName":585,"dataGaLocation":471},"/de-de/topics/agentic-ai/","agentic ai",{"title":587,"links":588},"Lösungen",[589,592,594,599,603,606,609,612,614,616,618,623],{"text":133,"config":590},{"href":128,"dataGaName":591,"dataGaLocation":471},"Application Security Testing",{"text":120,"config":593},{"href":104,"dataGaName":105,"dataGaLocation":471},{"text":595,"config":596},"Agile Entwicklung",{"href":597,"dataGaName":598,"dataGaLocation":471},"/de-de/solutions/agile-delivery/","agile delivery",{"text":600,"config":601},"SCM",{"href":117,"dataGaName":602,"dataGaLocation":471},"source code management",{"text":108,"config":604},{"href":110,"dataGaName":605,"dataGaLocation":471},"continuous integration & delivery",{"text":159,"config":607},{"href":161,"dataGaName":608,"dataGaLocation":471},"value stream management",{"text":552,"config":610},{"href":611,"dataGaName":555,"dataGaLocation":471},"/de-de/solutions/gitops/",{"text":172,"config":613},{"href":174,"dataGaName":175,"dataGaLocation":471},{"text":177,"config":615},{"href":179,"dataGaName":180,"dataGaLocation":471},{"text":182,"config":617},{"href":184,"dataGaName":185,"dataGaLocation":471},{"text":619,"config":620},"Bildungswesen",{"href":621,"dataGaName":622,"dataGaLocation":471},"/de-de/solutions/education/","education",{"text":624,"config":625},"Finanzdienstleistungen",{"href":626,"dataGaName":627,"dataGaLocation":471},"/de-de/solutions/finance/","financial services",{"title":192,"links":629},[630,632,634,636,639,641,643,645,647,649,651,653],{"text":204,"config":631},{"href":206,"dataGaName":207,"dataGaLocation":471},{"text":209,"config":633},{"href":211,"dataGaName":212,"dataGaLocation":471},{"text":214,"config":635},{"href":216,"dataGaName":217,"dataGaLocation":471},{"text":219,"config":637},{"href":221,"dataGaName":638,"dataGaLocation":471},"docs",{"text":242,"config":640},{"href":244,"dataGaName":245,"dataGaLocation":471},{"text":237,"config":642},{"href":239,"dataGaName":240,"dataGaLocation":471},{"text":247,"config":644},{"href":249,"dataGaName":250,"dataGaLocation":471},{"text":255,"config":646},{"href":257,"dataGaName":258,"dataGaLocation":471},{"text":260,"config":648},{"href":262,"dataGaName":263,"dataGaLocation":471},{"text":265,"config":650},{"href":267,"dataGaName":268,"dataGaLocation":471},{"text":270,"config":652},{"href":272,"dataGaName":273,"dataGaLocation":471},{"text":275,"config":654},{"href":277,"dataGaName":278,"dataGaLocation":471},{"title":293,"links":656},[657,659,661,663,665,667,669,674,679,681,683,685],{"text":300,"config":658},{"href":302,"dataGaName":295,"dataGaLocation":471},{"text":305,"config":660},{"href":307,"dataGaName":308,"dataGaLocation":471},{"text":313,"config":662},{"href":315,"dataGaName":316,"dataGaLocation":471},{"text":318,"config":664},{"href":320,"dataGaName":321,"dataGaLocation":471},{"text":323,"config":666},{"href":325,"dataGaName":326,"dataGaLocation":471},{"text":328,"config":668},{"href":330,"dataGaName":331,"dataGaLocation":471},{"text":670,"config":671},"Nachhaltigkeit",{"href":672,"dataGaName":673,"dataGaLocation":471},"/sustainability/","Sustainability",{"text":675,"config":676},"Vielfalt, Inklusion und Zugehörigkeit",{"href":677,"dataGaName":678,"dataGaLocation":471},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":333,"config":680},{"href":335,"dataGaName":336,"dataGaLocation":471},{"text":343,"config":682},{"href":345,"dataGaName":346,"dataGaLocation":471},{"text":348,"config":684},{"href":350,"dataGaName":351,"dataGaLocation":471},{"text":686,"config":687},"Transparenzerklärung zu moderner Sklaverei",{"href":688,"dataGaName":689,"dataGaLocation":471},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":691},[692,694,697],{"text":519,"config":693},{"href":521,"dataGaName":522,"dataGaLocation":471},{"text":695,"config":696},"Cookies",{"dataGaName":531,"dataGaLocation":471,"id":532,"isOneTrustButton":28},{"text":524,"config":698},{"href":526,"dataGaName":527,"dataGaLocation":471},[700],{"id":701,"title":9,"body":26,"config":702,"content":704,"description":26,"extension":25,"meta":708,"navigation":28,"path":709,"seo":710,"stem":711,"__hash__":712},"blogAuthors/en-us/blog/authors/joseph-longo.yml",{"template":703},"BlogAuthor",{"name":9,"config":705},{"headshot":706,"ctfId":707},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659681/Blog/Author%20Headshots/jlongo_gitlab-headshot.jpg","jlongogitlab",{},"/en-us/blog/authors/joseph-longo",{},"en-us/blog/authors/joseph-longo","VIlsk9hPcH3cl865aygtOArC3lR9vjVvQqDgvE-S7qU",[714,728,742],{"content":715,"config":726},{"title":716,"description":717,"authors":718,"heroImage":720,"date":721,"body":722,"category":11,"tags":723},"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.",[719],"Omer Azaria","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772195014/ooezwusxjl1f7ijfmbvj.png","2026-04-20","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",[724,11,725],"AI/ML","DevSecOps platform",{"featured":28,"template":15,"slug":727},"prepare-your-pipeline-for-ai-discovered-zero-days",{"content":729,"config":740},{"title":730,"description":731,"authors":732,"heroImage":734,"date":735,"category":11,"tags":736,"body":739},"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.",[733],"Grant Hickman","https://res.cloudinary.com/about-gitlab-com/image/upload/v1774375772/kpaaaiqhokevxxeoxvu0.png","2026-03-25",[11,737,567,22,738],"tutorial","product","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":741,"featured":28,"template":15},"auto-dismiss-vulnerability-management-policy",{"content":743,"config":752},{"title":744,"description":745,"authors":746,"heroImage":748,"date":749,"body":750,"category":11,"tags":751},"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.",[747],"Alisa Ho","https://res.cloudinary.com/about-gitlab-com/image/upload/v1773843921/rm35fx4gylrsu9alf2fx.png","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/).",[738,11,22],{"featured":14,"template":15,"slug":753},"gitlab-18-10-brings-ai-native-triage-and-remediation",{"promotions":755},[756,770,781,792],{"id":757,"categories":758,"header":760,"text":761,"button":762,"image":767},"ai-modernization",[759],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":763,"config":764},"Get your AI maturity score",{"href":765,"dataGaName":766,"dataGaLocation":245},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":768},{"src":769},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":771,"categories":772,"header":773,"text":761,"button":774,"image":778},"devops-modernization",[738,570],"Are you just managing tools or shipping innovation?",{"text":775,"config":776},"Get your DevOps maturity score",{"href":777,"dataGaName":766,"dataGaLocation":245},"/assessments/devops-modernization-assessment/",{"config":779},{"src":780},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":782,"categories":783,"header":784,"text":761,"button":785,"image":789},"security-modernization",[11],"Are you trading speed for security?",{"text":786,"config":787},"Get your security maturity score",{"href":788,"dataGaName":766,"dataGaLocation":245},"/assessments/security-modernization-assessment/",{"config":790},{"src":791},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":793,"paths":794,"header":797,"text":798,"button":799,"image":804},"github-azure-migration",[795,796],"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":800,"config":801},"See how GitLab compares to GitHub",{"href":802,"dataGaName":803,"dataGaLocation":245},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":805},{"src":780},{"header":807,"blurb":808,"button":809,"secondaryButton":814},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":810,"config":811},"Kostenlosen Test starten",{"href":812,"dataGaName":50,"dataGaLocation":813},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/de-de/","feature",{"text":52,"config":815},{"href":54,"dataGaName":55,"dataGaLocation":813},1777493570712]