[{"data":1,"prerenderedAt":819},["ShallowReactive",2],{"/de-de/blog/migration-guide-github-advanced-security-to-gitlab-ultimate":3,"navigation-de-de":43,"banner-de-de":457,"footer-de-de":467,"blog-post-authors-de-de-Fernando Diaz":703,"blog-related-posts-de-de-migration-guide-github-advanced-security-to-gitlab-ultimate":717,"blog-promotions-de-de":757,"next-steps-de-de":809},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":28,"isFeatured":12,"meta":29,"navigation":12,"path":30,"publishedDate":20,"seo":31,"stem":38,"tagSlugs":39,"__hash__":42},"blogPosts/de-de/blog/migration-guide-github-advanced-security-to-gitlab-ultimate.yml","Migration Guide Github Advanced Security To Gitlab Ultimate",[7],"fernando-diaz",null,"security",{"slug":11,"featured":12,"template":13},"migration-guide-github-advanced-security-to-gitlab-ultimate",true,"BlogPost",{"heroImage":15,"body":16,"authors":17,"updatedDate":19,"date":20,"title":21,"tags":22,"description":27,"category":9},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666187/Blog/Hero%20Images/blog-image-template-1800x945__6_.png","GitLab ist die umfassendste KI-gestützte DevSecOps-Plattform. Unternehmen können mit dieser Plattform für den gesamten Lebenszyklus der\nSoftwareentwicklung (SDLC) sicherere Software schneller bereitstellen. \n\nGitHub bietet eine Advanced Security-Erweiterung, die zusätzliche Sicherheitsfunktionen in GitHub ermöglicht. Es fehlen jedoch die Tiefe und Breite der Sicherheitsfunktionen, die GitLab nativ bereitstellt. \n\nUnternehmen, die auf GitLab Ultimate migrieren möchten, um ihre Sicherheit in allen Bereichen des SDLC zu verbessern, können diesen Leitfaden verwenden, um die beiden Angebote zu vergleichen. Er kann auch als Tutorial für den Wechsel zur GitLab-Plattform genutzt werden.\n\n**Hinweis**: Dieser Artikel wurde zuletzt im Juni 2025 aktualisiert, um die neuesten Änderungen in GitHubs Produktstrategie zu berücksichtigen.\n\nIn diesem Artikel findest du folgende Kapitel:\n\n- [Ein Vergleich zwischen GitLab Ultimate und GitHub Advanced Security](#a-comparison-between-gitlab-ultimate-and-github-advanced-security)\n\n- [So migrierst du ein GitHub-Repository zu GitLab](#how-to-migrate-a-github-repository-to-gitlab)\n\n- [So migrierst du Feature für Feature von GitHub Advanced Security zu GitLab Ultimate](#how-to-migrate-feature-by-feature)\n\n- [Eine Einführung in die zusätzlichen Sicherheitsfunktionen von GitLab Ultimate](#additional-gitlab-ultimate-security-features)\n\n## Ein Vergleich zwischen GitLab Ultimate und GitHub Advanced Security\n\n[GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/) ist die höchste Abonnementstufe von GitLab für Unternehmen, die sichere Software schneller bereitstellen möchten. GitHub Advanced Security ist eine Erweiterung für GitHub Enterprise und ermöglicht zusätzliche Sicherheitsfunktionen.\n\n### Ähnlichkeiten zwischen GitLab Ultimate und GitHub Advanced Security\n\nGitLab Ultimate und GitHub Advanced Security bieten:\n\n- Statische Anwendungssicherheitstests ([SAST](https://docs.gitlab.com/user/application_security/sast/)), Geheimnis- und Abhängigkeitssuche\n\n- kontextbezogene Intelligenz von Sicherheitslücken und Lösungsberatung \n\n- eine Liste von Abhängigkeiten oder Software-Stückliste ([SBOM](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/))\n\n- Sicherheitsmetriken und -einblicke\n\n### Unterschiede zwischen GitLab Ultimate und GitHub Advanced Security\n\nWährend sich GitHubs Sicherheitstools verbessert haben (mit Push Protection, die 2024 Millionen von Secrets blockiert hat), bietet GitLab Ultimate weiterhin eine tiefere DevSecOps-Integration mit Funktionen, die in GitHubs eigenständigen Produkten nicht verfügbar sind:\n\n* [Compliance-Frameworks und Audit-Management](https://docs.gitlab.com/user/compliance/compliance_center/)\n\n* [Sicherheits-Dashboard](https://docs.gitlab.com/user/application_security/security_dashboard/) über gesamte Gruppen/Organisationen\n\n* Native [DAST](https://docs.gitlab.com/user/application_security/dast/) und [API-Fuzzing](https://docs.gitlab.com/user/application_security/api_fuzzing/)\n\n* Integrierter Workflow für [Schwachstellenmanagement](https://docs.gitlab.com/user/application_security/vulnerability_report/)\n\n* [Benutzerdefinierte Sicherheitsrichtlinien](https://docs.gitlab.com/user/application_security/policies/) mit [granularen Kontrollen](https://docs.gitlab.com/user/custom_roles/)\n\nDiese integrierten Funktionen bedeuten, dass Teams weniger Zeit mit dem Wechsel zwischen Tools verbringen und mehr Zeit für die Sicherung ihrer Anwendungen haben.\n\nGitLab Ultimate bietet auch zusätzliche Sicherheits- und Konformitätsfunktionen, Portfolio- und Wertschöpfungskettenmanagement, Unterstützung bei Live-Upgrades und mehr. Weitere Informationen zu diesen zusätzlichen Funktionen findest du in der [GitLab Ultimate-Dokumentation](https://about.gitlab.com/pricing/ultimate/).RetryClaude can make mistakes. Please double-check responses.\n\n### Wichtige Änderungen bei GitHub Advanced Security (2025)\n\nSeit April 2025 hat GitHub Advanced Security in zwei separate Produkte aufgeteilt: Secret Protection (19$/Monat pro aktivem Committer) und Code Security (30$/Monat pro aktivem Committer). Obwohl dieser modulare Ansatz kosteneffektiv erscheinen mag, benötigen Organisationen in der Regel beide Produkte für umfassende Sicherheitsabdeckung, was zu 49$/Monat pro aktivem Committer führt - wodurch GitLab Ultimates einheitlicher Ansatz für Teams, die vollständige Sicherheitsfunktionen benötigen, potenziell wirtschaftlicher ist.\n\nGitHub bietet diese Sicherheitsprodukte nun auch Team-Plan-Kunden ohne Enterprise-Abonnement an. GitLabs integrierte DevSecOps-Plattform bedeutet jedoch, dass Sicherheitsfunktionen vom ersten Tag an nahtlos mit CI/CD, Projektmanagement und anderen Tools zusammenarbeiten - ohne zusätzliche Käufe oder Integrationen. Diese native Integration führt oft zu schnellerer Implementierung und besseren Sicherheitsergebnissen.\n\n## So migrierst du ein GitHub-Repository zu GitLab\n\nGitLab bietet einen integrierten Importer, mit dem du deine GitHub-Projekte entweder von GitHub.com oder GitHub Enterprise nach GitLab importieren kannst. Mit dem Importer kannst du nicht nur das GitHub-Repository nach GitLab migrieren, sondern auch verschiedene andere Objekte, einschließlich Tickets, Beteiligte (Mitglieder) und Pull Requests. Eine vollständige Liste der migrierbaren Daten findest du in der [Dokumentation zum Import von Daten von GitHub](https://docs.gitlab.com/user/project/import/github/#imported-data). Die Migration wird wie folgt durchgeführt:\n\n1. Wähle oben in der linken Menüleiste **Neu erstellen (+)** aus.\n\n2. Wähle im Abschnitt **In GitLab** **Neues Projekt/Repository**aus.\n\n3. Wähle **Projekt importieren** aus.\n\n![Projektauswahl importieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/1-Import-Project.png)\n\n4. Wähle die Schaltfläche **GitHub** aus.\n - Wenn du GitLab Self-Managed verwendest, musst du [den GitHub-Importer aktivieren](https://docs.gitlab.com/administration/settings/import_and_export_settings/#configure-allowed-import-sources).\n - Beachte, dass andere Importer auf dieselbe Weise initiiert werden können.\n5. Jetzt kannst du einen der folgenden Schritte ausführen:\n - Autorisiere dich mit GitHub Oauth, indem du **Mit GitHub autorisieren** auswählst.\n - Verwende einen persönlichen GitHub-Zugriffstoken:\n - Gehe zu \u003Chttps://github.com/settings/tokens/new>.\n - Gib im Feld **Hinweis** eine Token-Beschreibung ein.\n - Wähle den **Repo**-Geltungsbereich aus.\n - Um Beteiligte zu importieren, wähle optional den Geltungsbereich **read:org** aus.\n - Wähle die Schaltfläche **Token generieren** aus.\n - Füge auf der GitLab-Importseite im Feld „Persönlicher Zugriffstoken“ den persönlichen GitHub-Zugriffstoken ein.\n\n6. Wähle die Schaltfläche **Authentifizieren** aus.\n\n7. Wähle die Elemente aus, die du migrieren möchtest.\n\n8. Wähle die Projekte aus, die du migrieren möchtest, und wohin du sie migrieren möchtest.\n\n9. Wähle die Schaltfläche **Importieren** aus.\n\nDein importiertes Projekt sollte sich nun in deinem Arbeitsbereich befinden. Weitere Informationen über die Migration von GitHub zu GitLab findest du in diesem Video:\n\n\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=HEpZVy94cpfPfAky\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\nDu kannst die Migration auch mit einem [persönlichen GitHub-Zugriffstoken](https://docs.gitlab.com/user/project/import/github/#use-a-github-personal-access-token) oder der [GitLab REST API(https://docs.gitlab.com/user/project/import/github/#use-the-api) durchführen. Der Importer ermöglicht auch den Import aus anderen Quellen wie Bitbucket oder Gitea. Weitere Informationen findest du in der [Importer-Dokumentation](https://docs.gitlab.com/user/project/import/).\n\n## So migrierst du Funktion für Funktion\n\nIm Folgenden erfährst du, wie du die einzelnen Funktionen von GitHub Advanced Security in GitLab Ultimate nutzen kannst. Du benötigst eine [GitLab Ultimate-Lizenz](https://about.gitlab.com/pricing/ultimate/), um fortzufahren. GitLab bietet eine [kostenlose Testversion](https://about.gitlab.com/free-trial/devsecops/), um dir den Einstieg zu erleichtern.\n\n### Scannen von Code\n\nMit dem Scannen von Code bietet GitLab kontextbezogene Intelligenz von Sicherheitslücken und Ratschläge für statischen Quellcode. Das Gleiche kannst du in GitLab erreichen, indem du [SAST](https://docs.gitlab.com/user/application_security/sast/) aktivierst. GitLab SAST-Scanner decken ein breiteres Spektrum an Programmiersprachen und Frameworks ab als [CodeQL](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql#about-codeql) von GitHub.\n\nUm das Scannen von Code in GitLab zu aktivieren, kannst du einfach die [SAST-Vorlage](https://docs.gitlab.com/user/application_security/sast/#configure-sast-in-your-cicd-yaml) zu deiner ‚.gitlab-ci.yml‘ hinzufügen:\n\n```yaml\ninclude:\n - template: Jobs/SAST.gitlab-ci.yml\n```\n\nSobald die Vorlage hinzugefügt wurde, erkennt SAST automatisch jedes Mal, wenn neuer Code eingecheckt wird, die [Programmiersprachen](https://docs.gitlab.com/user/application_security/sast/#supported-languages-and-frameworks), die in deinem Projekt verwendet werden. Es scannt dann den Quellcode nach bekannten Schwachstellen.\n\n**Hinweis:** Sicherheitsscanner können deinem Projekt auch mithilfe der \\[Sicherheitskonfiguration] von GitLab (https://docs.gitlab.com/user/application_security/configuration/) hinzugefügt werden. Diese kann automatisch einen Merge Request erstellen, um deine Pipeline zu aktualisieren. Weitere Informationen findest du in der [Dokumentation zum Konfigurieren von SAST mithilfe der UI](https://docs.gitlab.com/user/application_security/sast/#configure-sast-by-using-the-ui).\n\nDie SAST-Ergebnisse zwischen dem Feature-Branch und der Zielbranch werden im Merge-Request-Widget angezeigt. Das Merge Request-Widget zeigt SAST-Ergebnisse und -Auflösungen an, die durch die Änderungen im Merge Request eingeführt wurden.\n\n![Sicherheits-Scanning in Merge Request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/2-SAST-MR-View.png)\n\nJede Sicherheitslücke zeigt Daten an, die bei der Behebung helfen, einschließlich detaillierter Beschreibung, Schweregrad, Standort und Lösungsinformationen:\n\n![SAST-Sicherheitslückendetails](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/3-SAST-MR-View-Detailed.png)\n\nDu kannst Maßnahmen gegen diese Sicherheitslücken ergreifen:\n\n- **Sicherheitslücke ignorieren**: Ermöglicht es Entwickler(inne)n, die Sicherheitslücke mit einem Kommentar zu ignorieren. Dies unterstützt das Sicherheitsteam bei der Durchführung einer Review.\n\n- **Ticket erstellen**: Ermöglicht das Erstellen eines Tickets, um eine Sicherheitslücke zu verfolgen, die eine zusätzliche Überwachung erfordert.\n\nDiese Änderungen sind auch inline sichtbar, wenn du innerhalb des Merge Request zur Ansicht **Änderungen** wechselst.\n\n![SAST-Änderungsansicht für Sicherheitslücken](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/4-SAST-MR-View-Changes.png)\n\n#### Anpassen von SAST-Scannern\n\nMit GitLab kannst du eine SAST-Jobdefinition überschreiben und Eigenschaften wie Variablen, Abhängigkeiten oder Regeln ändern. Dazu musst du einen Job mit demselben Namen erstellen, wie der SAST-Job, den du überschreiben willst. Platziere dann diesen neuen Job nach dem Einfügen der Vorlage und gib alle zusätzlichen Schlüssel darunter an.\n\nEin Beispiel ist die folgende Konfiguration:\n\n- überschreibt die Version, die der ‚semgrep-sast‘-Scanner verwendet\n\n- führt ein Skript aus, um Module aus privaten Projekten abzurufen, bevor ‚gosec-sast‘ ausgeführt wird \n\n- konfiguriert alle Scanner so, dass sie in einer maximalen Tiefe von 10 suchen\n\n```yaml\ninclude:\n - template: Jobs/SAST.gitlab-ci.yml\n\nvariables:\n SEARCH_MAX_DEPTH: 10\n\nsemgrep-sast:\n variables:\n SAST_ANALYZER_IMAGE_TAG: \"3.7\"\n\ngosec-sast:\n before_script:\n - |\n cat \u003C\u003CEOF > ~/.netrc\n machine gitlab.com\n login $CI_DEPLOY_USER\n password $CI_DEPLOY_PASSWORD\n EOF\n```\n\n**Hinweis:** Die verfügbaren SAST-Jobs findest du in der [Vorlage ‚SAST.gitlab-ci.yml‘](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml). Konfigurationen findest du in der [Dokumentation für verfügbare SAST CI/CD Variablen](https://docs.gitlab.com/user/application_security/sast/#available-cicd-variables).\n\n#### Anpassen von SAST-Regelsätzen\n\nFür jeden SAST-Analysator verarbeitet GitLab den Code und verwendet dann Regeln, um mögliche Schwachstellen im Quellcode zu finden. Diese Regeln bestimmen, welche Arten von Schwachstellen der Scanner meldet.\n\n- Für Semgrep-basierte SAST-Scanner erstellt, pflegt und unterstützt GitLab die verwendeten Regeln. Es kombiniert die Open-Source-Engine Semgrep, von GitLab verwaltete Erkennungsregeln und die proprietäre Technologie von GitLab für das Verfolgen von Sicherheitslücken und die Erkennung von falschen positiven Ergebnissen.\n\n- Für andere SAST-Analysatoren werden die Regeln in den Upstream-Projekten für jeden Scanner definiert.\n\nDu kannst das Verhalten der SAST-Scanner anpassen, indem du eine Regelsatz-Konfigurationsdatei im gescannten Repository definierst:\n\n- Vordefinierte Regeln deaktivieren (für alle Analysatoren verfügbar)\n\n- Vordefinierte Regeln überschreiben (für alle Analysatoren verfügbar)\n\n- Vordefinierte Regeln ersetzen, indem du eine benutzerdefinierte Konfiguration mithilfe von Passthroughs synthetisierst\n\nWeitere Informationen und Beispiele zum Konfigurieren von SAST-Regeln findest du in den [SAST-Regeln](https://docs.gitlab.com/user/application_security/sast/rules/) und in der [Dokumentation zum Anpassen von Regelsätzen](https://docs.gitlab.com/user/application_security/sast/customize_rulesets/).\n\n### Geheimnissuche\n\nDas GitHub-Feature Geheimnissuche findet, blockiert und widerruft durchgesickerte Geheimnisse. Das Gleiche kannst du in GitLab erreichen, indem du die Funktion [Erkennung von Geheimnissen](https://docs.gitlab.com/user/application_security/secret_detection/) aktivierst.\n\nUm die Erkennung von Geheimnissen in GitLab zu aktivieren, kannst du einfach die folgende Vorlage zu deiner ‚.gitlab-ci.yml‘ hinzufügen:\n\n```yaml\ninclude:\n - template: Jobs/Secret-Detection.gitlab-ci.yml\n```\n\nSobald die Vorlage hinzugefügt wurde, scannt der Geheimnisscanner jedes Mal, wenn neuer Code eingecheckt wird (oder eine Pipeline ausgeführt wird), den Quellcode auf bekannte Geheimnisse. Je nach Situation scannt die Erkennung von Geheimnissen für Pipelines verschiedene Aspekte deines Codes. Für alle Methoden außer dem „Standard-Branch“ scannt die Erkennung von Geheimnissen für Pipelines Commits, nicht den Arbeitsbaum. Weitere Informationen zur Geheimnissuche findest du in der [Dokumentation zur Erkennung von Geheimnissen](https://docs.gitlab.com/user/application_security/secret_detection/pipeline/#coverage).\n\nWenn du einen Merge Request erstellst, scannt die Funktion Erkennung von Geheimnissen jeden Commit, der im Quellbranch vorgenommen wurde. Genau wie in SAST liefert jede erkannte Sicherheitslücke die folgenden Informationen (z. B. Standort) und Bezeichner, um den Behebungsprozess zu unterstützen:\n\n![Sicherheitslückendetails für die Erkennung von Geheimnissen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/5-Secret-Detection-MR-Detailed.png)\n\nÄhnlich wie bei SAST kannst du Maßnahmen gegen diese Sicherheitslücken direkt aus der Merge Request heraus ergreifen, einschließlich des Ignorierens von Sicherheitslücken und des Erstellens von Tickets.\n\n#### Anpassen von Jobs der Erkennung von Geheimnissen\n\nMit GitLab kannst du eine Jobdefinition der Erkennung von Geheimnissen überschreiben, sodass du Eigenschaften wie Variablen, Abhängigkeiten oder Regeln ändern kannst. Dazu musst du einen Job mit demselben Namen erstellen, wie der Job zur Erkennung von Geheimnissen, den du überschreiben willst. Platziere dann diesen neuen Job nach dem Einfügen der Vorlage und gib alle zusätzlichen Schlüssel darunter an. Ein Beispiel ist die folgende Konfiguration:\n\n- überschreibt die Phase, auf der der Job zur Erkennung von Geheimnissen ausgeführt wird, zu ‚security‘\n\n- ermöglicht Verlaufsscans\n\n- ändert die Analysatorversion für Geheimnisse auf 4.5\n\n```yaml\ninclude:\n - template: Jobs/Secret-Detection.gitlab-ci.yml\n\nsecret_detection:\n stage: security\n variables:\n SECRET_DETECTION_HISTORIC_SCAN: \"true\"\n SECRETS_ANALYZER_VERSION: \"4.5\"\n```\n\n**Hinweis:** Die verfügbaren Jobs zur Erkennung von Geheimnissen findest du in der [Vorlage SAST.gitlab-ci.yml](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml). Verfügbare Konfigurationen findest du in der [Dokumentation zu verfügbaren CI/CD-Variablen der Erkennung von Geheimnissen](https://docs.gitlab.com/user/application_security/secret_detection/pipeline/#customizing-analyzer-settings).\n\n#### Anpassen von Regeln für die Erkennung von Geheimnissen\n\nMit dem Analysator für die Erkennung von Geheimnissen kannst du anzupassen, welche Geheimnisse in der GitLab-UI gemeldet werden. Die folgenden Anpassungsoptionen können einzeln oder in Kombination verwendet werden:\n\n- vordefinierte Regeln deaktivieren\n\n- vordefinierte Regeln überschreiben\n\n- eine benutzerdefinierte Konfiguration synthetisieren\n\n- eine Remote-Konfigurationsdatei spezifizieren\n\nWenn du zum Beispiel die Datei ‚.gitlab/secret-detection-ruleset.toml‘ im Stammverzeichnis deines Projekts erstellst, wird das Standard-GitLeaks-Paket erweitert, sodass Testtoken von der Erkennung ausgeschlossen werden:\n\n```yaml\n### extended-gitleaks-config.toml\ntitle = \"extension of gitlab's default gitleaks config\"\n[extend]\n### Extends default packaged path\npath = \"/gitleaks.toml\"\n[allowlist]\n description = \"allow list of test tokens to ignore in detection\"\n regexTarget = \"match\"\n regexes = [\n '''glpat-1234567890abcdefghij''',\n ]\n```\n\nWeitere Informationen zum Überschreiben der vordefinierten Analysatorregeln findest du in der [Dokumentation zur Erkennung von Geheimnissen](https://docs.gitlab.com/user/application_security/secret_detection/pipeline/#override-predefined-analyzer-rules).\n\n#### Automatische Reaktion auf durchgesickerte Geheimnisse\n\nDie Funktion zur Erkennung von Geheimnissen von GitLab reagiert automatisch, wenn sie bestimmte Arten von durchgesickerten Geheimnissen findet. Automatische Antworten können:\n\n- das Geheimnis automatisch widerrufen\n\n- den Partner, der das Geheimnis ausgestellt hat, benachrichtigen; der Partner kann dann das Geheimnis widerrufen, seine(n) Eigentümer(in) benachrichtigen oder sich auf andere Weise vor Missbrauch schützen\n\nGitLab kann Partner auch benachrichtigen, wenn von ihnen ausgestellte Anmeldeinformationen in öffentlichen Repositorys auf GitLab.com durchgesickert sind. Wenn du ein Cloud- oder SaaS-Produkt betreibst und diese Benachrichtigungen erhalten möchtest, kannst du eine Partner-API implementieren, die von der GitLab Token Revocation API aufgerufen wird.\n\nWeitere Informationen findest du in der [Dokumentation zu automatischen Antworten für durchgesickerte Geheimnisse](https://docs.gitlab.com/user/application_security/secret_detection/automatic_response/).\n\n### Sicherheit der Lieferkette\n\nMit GitHub kannst du Software-Lieferketten mit automatisierten Sicherheits- und Versionsaktualisierungen und SBOMs mit einem Klick sichern, verwalten und Berichte darüber erstellen. GitLab kann deine Sicherheitsbedürfnisse in der Lieferkette mithilfe der Funktionen der Abhängigkeitssuche und der Liste der Abhängigkeiten (SBOM) erfüllen.\n\nUm das Scannen von Abhängigkeiten in GitLab zu aktivieren, kannst du einfach die folgende Vorlage zu deiner ‚.gitlab-ci.yml‘ hinzufügen:\n\n```yaml\ninclude:\n - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n```\n\nSobald die Vorlage hinzugefügt wurde erkennt die Abhängigkeitssuche jedes Mal, wenn neuer Code eingecheckt wird, automatisch die [Paketmanager](https://docs.gitlab.com/user/application_security/dependency_scanning/#supported-languages-and-package-managers), die in deinem Projekt verwendet werden. Sie scannt dann die verwendeten Abhängigkeiten auf bekannte Schwachstellen.\n\nDie Ergebnisse der Abhängigkeitssuche zwischen dem Feature-Branch und dem Zielbranch werden im Merge-Request-Widget angezeigt. Das Merge-Request-Widget zeigt die Ergebnisse der Abhängigkeitssuche, die durch die Änderungen im Merge Request eingeführt wurden, und schlägt Lösungen vor. Innerhalb eines Merge Request werden für jede Sicherheitslücke relevante Informationen angezeigt, die bei der Behebung hilfreich sind, wie Bezeichner, Beweise und Lösungen:\n\n![Sicherheitslückendetails der Abhängigkeitssuche](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/6-Dependency-Scanner-MR-View-Detailed.png)\n\nÄhnlich wie bei SAST und der Erkennung von Geheimnissen kannst du Maßnahmen gegen diese Sicherheitslücken direkt aus dem Merge Request heraus ergreifen. Dazu gehören das Ignorieren von Sicherheitslücken und das Erstellen von Tickets.\n\n#### Konfigurieren der Abhängigkeitssuche\n\nUm eine Jobdefinition zu überschreiben (z. B. um Eigenschaften wie Variablen oder Abhängigkeiten zu ändern), erstellst du einen neuen Job mit dem gleichen Namen wie den, den du überschreiben willst. Platziere dann diesen neuen Job nach dem Einfügen der Vorlage und gib alle zusätzlichen Schlüssel darunter an. Ein Beispiel ist der folgende Code:\n\n- deaktiviert die automatische Behebung anfälliger Abhängigkeiten\n\n- erfordert einen Build-Job, der vor der Abhängigkeitssuche abgeschlossen werden muss\n\n```yaml\ninclude:\n - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n\ngemnasium-dependency_scanning:\n variables:\n DS_REMEDIATE: \"false\"\n dependencies: [\"build\"]\n```\n\nWeitere Informationen zur Konfiguration der Abhängigkeitssuche findest du in der [Dokumentation zum Anpassen des Verhaltens des Analysators](https://docs.gitlab.com/user/application_security/dependency_scanning/#customizing-analyzer-behavior).\n\n#### Das Generieren eines SBOM\n\nGitLab bietet eine Liste der Abhängigkeiten (Dependency List, SBOM), mit der du die Abhängigkeiten deines Projekts oder deiner Gruppe sowie wichtige Details zu diesen Abhängigkeiten, einschließlich ihrer bekannten Sicherheitslücken, überprüfen kannst. Diese Liste ist eine Ansammlung von Abhängigkeiten in deinem Projekt, einschließlich bestehender und neuer Resultate. Die Liste der Abhängigkeiten wird generiert, nachdem die Abhängigkeitssuche erfolgreich auf dem [Standard-Branch](https://docs.gitlab.com/user/project/repository/branches/default/) ausgeführt wurde. So greifst du auf die Liste der Abhängigkeiten zu:\n\n1. Wähle in der linken Seitenleiste **Suchen oder aufrufen** aus und suche nach deinem Projekt.\n\n2. Wähle **Sicher > Liste der Abhängigkeiten** aus.\n\n![Liste der Abhängigkeiten (SBOM)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/7-Dependency-List.png)\n\nHier findest du die folgenden Informationen zu deinen Abhängigkeiten:\n\n| Feld | Beschreibung |\n| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Komponente | Name und Version der Abhängigkeit. |\n| Paketerstellungs-Manager | Der Paketerstellungs-Manager, mit dem die Abhängigkeit installiert wurde. |\n| Standort | Bei Systemabhängigkeiten wird das gescannte Image aufgelistet. Bei Anwendungsabhängigkeiten wird hier ein Link zu der für den Paketerstellungs-Manager spezifischen Lock-Datei in deinem Projekt angezeigt, in der die Abhängigkeit deklariert ist. Hier wird auch der Abhängigkeitspfad zu einer übergeordneten Abhängigkeit angegeben, falls diese vorhanden ist und unterstützt wird. |\n| Lizenz | Links zu den Softwarelizenzen der Abhängigen. Ein Warnhinweis, der die Anzahl der in der Abhängigkeit erkannten Sicherheitslücken enthält. |\n| Projekte | Link zum Projekt mit der Abhängigkeit. Wenn mehrere Projekte die gleiche Abhängigkeit haben, wird die Gesamtzahl der Projekte angezeigt. So öffnest du ein Projekt mit dieser Abhängigkeit: Wähle die Projektnummer aus, suche dann nach dem Namen und wähle ihn aus. Die Projektsuche wird nur bei Gruppen unterstützt, die maximal 600 Einträge in ihrer Gruppenhierarchie haben. |\n\n\u003Cp>\u003C/p>\n\nWeitere Informationen findest du in der [Dokumentation zur Liste der Abhängigkeiten](https://docs.gitlab.com/user/application_security/dependency_list/).\n\n### Sicherheits- und Konformitätsverwaltung\n\nMit GitHub Advanced Security kannst du Sicherheitsmetriken und -einblicke anzeigen und das Sicherheitsrisiko von Code bewerten. Wir sehen uns jetzt an, wie man das gleiche mit GitLab Ultimate macht.\n\n#### Anzeigen von Sicherheitsmetriken und -einblicken\n\nGitLab bietet [Sicherheits-Dashboards](https://docs.gitlab.com/user/application_security/security_dashboard/), mit denen du den Sicherheitsstatus deiner Anwendungen bewerten kannst. Diese Dashboards zeigen eine Sammlung von Metriken, Bewertungen und Diagrammen für die von den Sicherheitsscannern in deinem Projekt erkannten Sicherheitslücken:\n\n- Sicherheitslückentrends über einen Zeitraum von 30, 60 oder 90 Tagen für alle Projekte in einer Gruppe\n\n- eine Einstufung für jedes Projekt nach der Schwere der Sicherheitslücke\n\n- die Gesamtzahl der in den letzten 365 Tagen entdeckten Sicherheitslücken, einschließlich ihres Schweregrads\n\nSo greifst du auf das Sicherheits-Dashboard zu:\n\n1. Wähle in der linken Menüleiste **Suchen oder aufrufen** und suche nach deinem Projekt oder deiner Gruppe.\n\n2. Wähle auf dem seitlichen Tab das Dashboard **Sicher > Sicherheit** aus.\n\n3. Filtere und suche nach dem, was du brauchst.\n\nDie Gruppenansicht zeigt deine Sicherheitslage für alle Projekte in deiner Gruppe an:\n\n![Dashboard Gruppensicherheit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/8-SD-Group.png)\n\nDie Projektansicht zeigt deine Sicherheitslage nur für das Projekt an:\n\n![Dashboard Projektsicherheit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/9-SD-Project.png)\n\n#### Beurteile das Sicherheitsrisiko des Codes\n\nGitLab Ultimate verfügt über einen [Sicherheitslückenbericht](https://docs.gitlab.com/user/application_security/vulnerability_report/), der Informationen über Sicherheitslücken aus Scans des Standard-Branchs enthält. Er enthält kumulative Ergebnisse aller erfolgreichen Jobs, unabhängig davon, ob die Pipeline erfolgreich war. Der Sicherheitslückenbericht enthält auf allen Ebenen:\n\n- Die Gesamtanzahl der Sicherheitslücken pro Schweregrad\n\n- Filter für gängige Attribute für Sicherheitslücken\n\n- Details zu jeder Sicherheitslücke, dargestellt in einem tabellarischen Layout\n\n![Sicherheitslückenbericht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/10-Vulnerability-Report.png)\n\nWenn du auf eine Sicherheitslücke klickst, gelangst du zur [Seite der Sicherheitslücke](https://docs.gitlab.com/user/application_security/vulnerabilities/), die Details zu der Sicherheitslücke enthält, wie z. B. eine Beschreibung, den Ort, die Bezeichner und mehr. Nachfolgend findest du ein Beispiel für die Seite einer SQL Injection-Sicherheitslücke, die von unserem SAST-Scanner erkannt wurde:\n\n![Seite einer SQL Injection-Sicherheitslücke](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/11-Vulnerability-Page-1.png)\n\nAuf dieser Seite kann das Sicherheitsteam zusammenarbeiten, indem es [den Status einer Sicherheitslücke](https://docs.gitlab.com/user/application_security/vulnerabilities/#change-the-status-of-a-vulnerability) zusammen mit einer Begründung ändert und [Tickets erstellt, um Änderungen besser verfolgen zu können](https://docs.gitlab.com/user/application_security/vulnerabilities/#create-a-gitlab-issue-for-a-vulnerability).\n\nAuf der Seite der Sicherheitslücke kannst du auch [GitLab Duo](https://about.gitlab.com/gitlab-duo-agent-platform/), unsere KI-gestützte Suite von Funktionen, nutzen. Es kann dir die Sicherheitslücke erklären und [automatisch einen Merge Request für die Behebung der Sicherheitslücke erstellen](https://docs.gitlab.com/user/application_security/vulnerabilities/#vulnerability-resolution).\n\nDie \\[Erklärung der Sicherheitslücke] von GitLab Duo (https://docs.gitlab.com/user/application_security/vulnerabilities/#vulnerability-explanation) verwendet ein umfangreiches Sprachmodell, um:\n\n- Die Sicherheitslücke zusammenzufassen\n\n- Entwickler(inne)n und Sicherheitsanalyst(inn)en zu helfen, die Sicherheitslücke zu verstehen und wie sie ausgenutzt und behoben werden kann,\n\n- Eine vorgeschlagene Abhilfemaßnahme vorzuschlagen\n\n![Erklärung einer SQL Injection von der GitLab Duo-KI](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/13-Explain-Vulnerability.png)\n\n## Zusätzliche GitLab Ultimate-Sicherheitsfunktionen\n\nGitLab Ultimate enthält viele weitere Sicherheitsfunktionen, die in GitHub Advanced Security nicht vorhanden sind. Einige Beispiele für diese zusätzlichen Sicherheitsfunktionen sind: zusätzliche Sicherheitsscanner für den gesamten Lebenszyklus der Softwareentwicklung (SDLC), granulare Sicherheitsleitlinien und benutzerdefinierte Berechtigungen.\n\n### Sicherheitsscanner für den gesamten SDLC\n\nUnser Portfolio an Sicherheitsscannern erstreckt sich über den kompletten SDLC.\n\n| Name des Scanners | Scans | Gescannte Sprachen/Dateien |\n| ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ | ----------------------------------------------------- |\n| [Statische Anwendungssicherheitstests (SAST)](https://docs.gitlab.com/user/application_security/sast/) | Statischer Quellcode | C/C++, Java, Python, Go, JavaScript, C# und weitere |\n| [Dynamische Anwendungssicherheitstests (DAST)](https://docs.gitlab.com/user/application_security/dast/) | Ausgeführte Webanwendung, Live-API | Sprachunabhängig |\n| [Scannen von Infrastructure as Code (IaC)](https://docs.gitlab.com/user/application_security/iac_scanning/) | IaC-Dateien | Terraform, AWS Cloud Formation, Ansible, und weitere |\n| [Container-Scanning](https://docs.gitlab.com/user/application_security/container_scanning/) | Statische und ausgeführte Container-Images | Dockerfile |\n| [Abhängigkeitssuche und Lizenz-Scanning](https://docs.gitlab.com/user/application_security/dependency_scanning/) | Anwendungsabhängigkeiten | Requirements.txt, Yarn, Gradle, Npm und weitere |\n| [Web-API-Fuzz-Testing](https://docs.gitlab.com/user/application_security/api_fuzzing/) | Sendet zufällige/falsche Daten an die Web-API | OpenAPI, GraphQL, HAR, Postman Collection |\n| [Abdeckungsgesteuertes Fuzz-Testing](https://docs.gitlab.com/user/application_security/coverage_fuzzing/) | Sendet zufällige/fehlerhafte Daten an Funktionen | C/C++, Go, Swift, Python, Rust, Java, JavaScript, AFL |\n\n\u003Cp>\u003C/p>\n\nGitLab ermöglicht auch die Integration von [Drittanbieter-Scannern](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/) und [benutzerdefinierten Scannern](https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab/) in die Plattform. Nach der Integration werden die Scannerergebnisse automatisch an verschiedenen Stellen in GitLab angezeigt, z. B. in der Pipeline-Ansicht, im Merge-Request-Widget und im Sicherheits-Dashboard. Weitere Informationen findest du in der [Dokumentation zur Integration von Sicherheitsscannern](https://docs.gitlab.com/development/integrations/secure/).\n\n### Granulare Sicherheits- und Konformitätsrichtlinien\n\nMit den Richtlinien in GitLab können Sicherheits- und Konformitätsteams [Kontrollen weltweit in ihrem Unternehmen durchsetzen](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/). Sicherheitsteams können Folgendes sicherstellen:\n\n- Sicherheitsscanner werden in den Pipelines des Entwicklungsteams mit der richtigen Konfiguration durchgesetzt.\n\n- Alle Scan-Jobs werden ohne Änderungen oder Modifikationen ausgeführt.\n\n- Ordnungsgemäße Genehmigungen für Merge Requests werden auf der Grundlage der Ergebnisse dieser Befunde erteilt.\n\n![Sicherheitsrichtlinien für Merge Requests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/14-MR-Policy.png)\n\nKonformitätsteams können zentral mehrere Genehmigende für alle Merge Requests erzwingen und sicherstellen, dass verschiedene Einstellungen für Projekte im Rahmen der organisatorischen Anforderungen aktiviert sind, z. B. die Aktivierung oder Sperrung von Merge Requests und Repository-Einstellungen. Weitere Informationen findest du in der [GitLab-Sicherheitsrichtlinie](https://docs.gitlab.com/user/application_security/policies/).\n\n### Benutzerdefinierte Rollen und granulare Berechtigungen\n\n[GitLab Ultimate bietet benutzerdefinierte Rollen](https://about.gitlab.com/blog/how-to-tailor-gitlab-access-with-custom-roles/), mit denen ein Unternehmen Benutzerrollen mit genau den Privilegien und Berechtigungen erstellen kann, die für die Bedürfnisse dieses Unternehmen erforderlich sind.\n\nZum Beispiel könnte ein(e) Benutzer(in) eine „Security Auditor“-Rolle mit Berechtigungen zum Anzeigen von Sicherheitslücken im System erstellen, mit der aber kein Quellcode angezeigt oder Änderungen im Repository vorgenommen werden kann. Dieser granulare Satz von Berechtigungen ermöglicht eine klar definierte Aufgabentrennung.\n\n![Benutzerdefinierte Rollenerstellung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/15-Custom-Roles.png)\n\nWeitere Informationen findest du in den Dokumentationen zu [benutzerdefinierten Rollen](https://docs.gitlab.com/user/custom_roles/) und [verfügbaren granularen Berechtigungen](https://docs.gitlab.com/user/custom_roles/abilities/).\n\n### Konformitäts-Center\n\nDas Konformitäts-Center ist der zentrale Ort für Konformitätsteams, um die Konformitätsstandards, die Berichterstattung über Verstöße und die Konformitätsframeworks für ihre Gruppe zu verwalten. Das Konformitäts-Center umfasst Folgendes:\n\n- Das [Dashboard zur Einhaltung von Konformitätsstandards](https://docs.gitlab.com/user/compliance/compliance_center/compliance_standards_adherence_dashboard/) listet den Status der Einhaltung von Projekten auf, die dem GitLab-Standard entsprechen.\n\n- Der [Bericht über Konformitätsverstöße](https://docs.gitlab.com/user/compliance/compliance_center/compliance_violations_report/) zeigt eine allgemeine Ansicht der Merge-Request-Aktivität für alle Projekte in der Gruppe.\n\n- Der [Bericht über Konformitätsframeworks](https://docs.gitlab.com/user/compliance/compliance_center/compliance_frameworks_report/) zeigt alle Konformitätsframeworks einer Gruppe.\n\n- Der [Bericht über Konformitätsprojekte](https://docs.gitlab.com/user/compliance/compliance_center/compliance_projects_report/) zeigt die Konformitätsframeworks, die auf Projekte einer Gruppe angewendet werden.\n\n![Konformitäts-Center](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/16-Compliance-Center.png)\n\nMit diesen Dashboards kannst du sicherstellen, dass die Aufgabentrennung eingehalten wird, um die Konformität in deinem Unternehmen zu optimieren. Weitere Informationen findest du in der [Konformitäts-Center-Dokumentation](https://docs.gitlab.com/user/compliance/compliance_center/).\n\n## Weiterlesen\n\nDieser Artikel behandelt nur einen Teil des breiten Spektrums an Sicherheitsfunktionen, die GitLab Ultimate bietet. Schau dir diese Ressourcen an, um mehr darüber zu erfahren, wie GitLab Ultimate dazu beitragen kann, die Sicherheit deines Unternehmens und die Effizienz deiner Entwickler(innen) zu verbessern:\n\n- [Was spricht für GitLab Ultimate?](https://about.gitlab.com/pricing/ultimate/)\n\n- [Tutorial: Erste Schritte mit DevSecOps](https://gitlab-da.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/)\n\n- [Beispielprojekt: Erste Schritte mit DevSecOps](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n\n- [Dokumentation: Importiere dein Projekt von GitHub in GitLab](https://docs.gitlab.com/user/project/import/github/)\n\n- [Dokumentation: Migration von GitHub Actions](https://docs.gitlab.com/ci/migration/github_actions/)\n\n- [Tutorial: Erstelle deine erste GitLab CI/CD-Pipeline und führe sie aus](https://docs.gitlab.com/ci/quick_start/)\n\n- [Tutorial: Erstelle eine komplexe Pipeline](https://docs.gitlab.com/ci/quick_start/tutorial/)\n\n- [CI/CD-YAML-Syntaxreferenz](https://docs.gitlab.com/ci/yaml/)",[18],"Fernando Diaz","2025-06-24","2024-05-01","GitLab Ultimate vs. GitHub Security: Der vollständige Vergleich und Migrationsleitfaden 2025",[23,24,9,25,26],"tutorial","zero trust","DevSecOps platform","testing","GitHub hat Advanced Security in zwei teure Einzelprodukte aufgeteilt. Entdecke, wie GitLab Ultimate mehr bietet und spare dabei Geld. Inklusive vollständiger Migrationsanleitung und aktuellem Feature-Vergleich 2025.","yml",{},"/de-de/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"ogTitle":32,"ogImage":15,"ogDescription":33,"ogSiteName":34,"noIndex":35,"ogType":36,"ogUrl":37,"title":32,"canonicalUrls":37,"description":33},"GitLab Ultimate vs GitHub Security: Vergleich & Migration","GitLab Ultimate vs GitHub Security 2025: Vergleiche Features, Preise und Vorteile. Plus Schritt-für-Schritt-Anleitung für deine erfolgreiche Migration.","https://about.gitlab.com",false,"article","https://about.gitlab.com/blog/migration-guide-github-advanced-security-to-gitlab-ultimate","de-de/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",[23,40,9,41,26],"zero-trust","devsecops-platform","HI6uFodqOtCss9QbTcdaD2VGlYX2-wVj_wmEP_6_2nM",{"data":44},{"logo":45,"freeTrial":50,"sales":55,"login":60,"items":65,"search":375,"minimal":409,"duo":427,"switchNav":436,"pricingDeployment":447},{"config":46},{"href":47,"dataGaName":48,"dataGaLocation":49},"/de-de/","gitlab logo","header",{"text":51,"config":52},"Kostenlose Testversion anfordern",{"href":53,"dataGaName":54,"dataGaLocation":49},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de&glm_content=default-saas-trial/","free trial",{"text":56,"config":57},"Vertrieb kontaktieren",{"href":58,"dataGaName":59,"dataGaLocation":49},"/de-de/sales/","sales",{"text":61,"config":62},"Anmelden",{"href":63,"dataGaName":64,"dataGaLocation":49},"https://gitlab.com/users/sign_in/","sign in",[66,93,190,195,296,356],{"text":67,"config":68,"cards":70},"Plattform",{"dataNavLevelOne":69},"platform",[71,77,85],{"title":67,"description":72,"link":73},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":74,"config":75},"Die Plattform erkunden",{"href":76,"dataGaName":69,"dataGaLocation":49},"/de-de/platform/",{"title":78,"description":79,"link":80},"GitLab Duo Agent Platform","Agentische KI für den gesamten Software-Lebenszyklus",{"text":81,"config":82},"Lerne GitLab Duo kennen",{"href":83,"dataGaName":84,"dataGaLocation":49},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":86,"description":87,"link":88},"Warum GitLab?","Erfahre, warum sich Unternehmen für GitLab entscheiden",{"text":89,"config":90},"Mehr erfahren",{"href":91,"dataGaName":92,"dataGaLocation":49},"/de-de/why-gitlab/","why gitlab",{"text":94,"left":12,"config":95,"link":97,"lists":101,"footer":172},"Produkt",{"dataNavLevelOne":96},"solutions",{"text":98,"config":99},"Alle Lösungen anzeigen",{"href":100,"dataGaName":96,"dataGaLocation":49},"/de-de/solutions/",[102,127,150],{"title":103,"description":104,"link":105,"items":110},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":106},{"icon":107,"href":108,"dataGaName":109,"dataGaLocation":49},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[111,115,118,123],{"text":112,"config":113},"CI/CD",{"href":114,"dataGaLocation":49,"dataGaName":112},"/de-de/solutions/continuous-integration/",{"text":78,"config":116},{"href":83,"dataGaLocation":49,"dataGaName":117},"gitlab duo agent platform - product menu",{"text":119,"config":120},"Quellcodeverwaltung",{"href":121,"dataGaLocation":49,"dataGaName":122},"/de-de/solutions/source-code-management/","Source Code Management",{"text":124,"config":125},"Automatische Softwarebereitstellung",{"href":108,"dataGaLocation":49,"dataGaName":126},"Automated software delivery",{"title":128,"description":129,"link":130,"items":135},"Sicherheit","Entwickle Code schneller ohne Abstriche bei der Sicherheit",{"config":131},{"href":132,"dataGaName":133,"dataGaLocation":49,"icon":134},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[136,140,145],{"text":137,"config":138},"Anwendungssicherheitstests",{"href":132,"dataGaName":139,"dataGaLocation":49},"Application security testing",{"text":141,"config":142},"Schutz der Software-Lieferkette",{"href":143,"dataGaLocation":49,"dataGaName":144},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":146,"config":147},"Software-Compliance",{"href":148,"dataGaName":149,"dataGaLocation":49},"/de-de/solutions/software-compliance/","software compliance",{"title":151,"link":152,"items":157},"Auswertung",{"config":153},{"icon":154,"href":155,"dataGaName":156,"dataGaLocation":49},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[158,162,167],{"text":159,"config":160},"Sichtbarkeit und Auswertung",{"href":155,"dataGaLocation":49,"dataGaName":161},"Visibility and Measurement",{"text":163,"config":164},"Wertstrommanagement",{"href":165,"dataGaLocation":49,"dataGaName":166},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":168,"config":169},"Analysen und Einblicke",{"href":170,"dataGaLocation":49,"dataGaName":171},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":173,"items":174},"GitLab für",[175,180,185],{"text":176,"config":177},"Enterprise",{"href":178,"dataGaLocation":49,"dataGaName":179},"/de-de/enterprise/","enterprise",{"text":181,"config":182},"Kleinunternehmen",{"href":183,"dataGaLocation":49,"dataGaName":184},"/de-de/small-business/","small business",{"text":186,"config":187},"Öffentlicher Sektor",{"href":188,"dataGaLocation":49,"dataGaName":189},"/de-de/solutions/public-sector/","public sector",{"text":191,"config":192},"Preise",{"href":193,"dataGaName":194,"dataGaLocation":49,"dataNavLevelOne":194},"/de-de/pricing/","pricing",{"text":196,"config":197,"link":199,"lists":203,"feature":283},"Ressourcen",{"dataNavLevelOne":198},"resources",{"text":200,"config":201},"Alle Ressourcen anzeigen",{"href":202,"dataGaName":198,"dataGaLocation":49},"/de-de/resources/",[204,237,255],{"title":205,"items":206},"Erste Schritte",[207,212,217,222,227,232],{"text":208,"config":209},"Installieren",{"href":210,"dataGaName":211,"dataGaLocation":49},"/de-de/install/","install",{"text":213,"config":214},"Kurzanleitungen",{"href":215,"dataGaName":216,"dataGaLocation":49},"/de-de/get-started/","quick setup checklists",{"text":218,"config":219},"Lernen",{"href":220,"dataGaLocation":49,"dataGaName":221},"https://university.gitlab.com/","learn",{"text":223,"config":224},"Produktdokumentation",{"href":225,"dataGaName":226,"dataGaLocation":49},"https://docs.gitlab.com/","product documentation",{"text":228,"config":229},"Best-Practice-Videos",{"href":230,"dataGaName":231,"dataGaLocation":49},"/de-de/getting-started-videos/","best practice videos",{"text":233,"config":234},"Integrationen",{"href":235,"dataGaName":236,"dataGaLocation":49},"/de-de/integrations/","integrations",{"title":238,"items":239},"Entdecken",[240,245,250],{"text":241,"config":242},"Kundenerfolge",{"href":243,"dataGaName":244,"dataGaLocation":49},"/de-de/customers/","customer success stories",{"text":246,"config":247},"Blog",{"href":248,"dataGaName":249,"dataGaLocation":49},"/de-de/blog/","blog",{"text":251,"config":252},"Remote",{"href":253,"dataGaName":254,"dataGaLocation":49},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":256,"items":257},"Vernetzen",[258,263,268,273,278],{"text":259,"config":260},"GitLab Services",{"href":261,"dataGaName":262,"dataGaLocation":49},"/de-de/services/","services",{"text":264,"config":265},"Community",{"href":266,"dataGaName":267,"dataGaLocation":49},"/community/","community",{"text":269,"config":270},"Forum",{"href":271,"dataGaName":272,"dataGaLocation":49},"https://forum.gitlab.com/","forum",{"text":274,"config":275},"Veranstaltungen",{"href":276,"dataGaName":277,"dataGaLocation":49},"/events/","events",{"text":279,"config":280},"Partner",{"href":281,"dataGaName":282,"dataGaLocation":49},"/de-de/partners/","partners",{"backgroundColor":284,"textColor":285,"text":286,"image":287,"link":291},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":288,"config":289},"The Source Promo-Karte",{"src":290},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":292,"config":293},"Aktuelles",{"href":294,"dataGaName":295,"dataGaLocation":49},"/de-de/the-source/","the source",{"text":297,"config":298,"lists":300},"Unternehmen",{"dataNavLevelOne":299},"company",[301],{"items":302},[303,308,314,316,321,326,331,336,341,346,351],{"text":304,"config":305},"Über",{"href":306,"dataGaName":307,"dataGaLocation":49},"/de-de/company/","about",{"text":309,"config":310,"footerGa":313},"Karriere",{"href":311,"dataGaName":312,"dataGaLocation":49},"/jobs/","jobs",{"dataGaName":312},{"text":274,"config":315},{"href":276,"dataGaName":277,"dataGaLocation":49},{"text":317,"config":318},"Geschäftsführung",{"href":319,"dataGaName":320,"dataGaLocation":49},"/company/team/e-group/","leadership",{"text":322,"config":323},"Team",{"href":324,"dataGaName":325,"dataGaLocation":49},"/company/team/","team",{"text":327,"config":328},"Handbuch",{"href":329,"dataGaName":330,"dataGaLocation":49},"https://handbook.gitlab.com/","handbook",{"text":332,"config":333},"Investor Relations",{"href":334,"dataGaName":335,"dataGaLocation":49},"https://ir.gitlab.com/","investor relations",{"text":337,"config":338},"Trust Center",{"href":339,"dataGaName":340,"dataGaLocation":49},"/de-de/security/","trust center",{"text":342,"config":343},"AI Transparency Center",{"href":344,"dataGaName":345,"dataGaLocation":49},"/de-de/ai-transparency-center/","ai transparency center",{"text":347,"config":348},"Newsletter",{"href":349,"dataGaName":350,"dataGaLocation":49},"/company/contact/#contact-forms","newsletter",{"text":352,"config":353},"Presse",{"href":354,"dataGaName":355,"dataGaLocation":49},"/press/","press",{"text":357,"config":358,"lists":359},"Kontakt",{"dataNavLevelOne":299},[360],{"items":361},[362,365,370],{"text":56,"config":363},{"href":58,"dataGaName":364,"dataGaLocation":49},"talk to sales",{"text":366,"config":367},"Support-Portal",{"href":368,"dataGaName":369,"dataGaLocation":49},"https://support.gitlab.com","support portal",{"text":371,"config":372},"Kundenportal",{"href":373,"dataGaName":374,"dataGaLocation":49},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":376,"login":377,"suggestions":384},"Schließen",{"text":378,"link":379},"Um Repositorys und Projekte zu durchsuchen, melde dich an bei",{"text":380,"config":381},"gitlab.com",{"href":63,"dataGaName":382,"dataGaLocation":383},"search login","search",{"text":385,"default":386},"Vorschläge",[387,389,394,396,401,406],{"text":78,"config":388},{"href":83,"dataGaName":78,"dataGaLocation":383},{"text":390,"config":391},"Codevorschläge (KI)",{"href":392,"dataGaName":393,"dataGaLocation":383},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":112,"config":395},{"href":114,"dataGaName":112,"dataGaLocation":383},{"text":397,"config":398},"GitLab auf AWS",{"href":399,"dataGaName":400,"dataGaLocation":383},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":402,"config":403},"GitLab auf Google Cloud",{"href":404,"dataGaName":405,"dataGaLocation":383},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":86,"config":407},{"href":91,"dataGaName":408,"dataGaLocation":383},"Why GitLab?",{"freeTrial":410,"mobileIcon":415,"desktopIcon":420,"secondaryButton":423},{"text":411,"config":412},"Kostenlos testen",{"href":413,"dataGaName":54,"dataGaLocation":414},"https://gitlab.com/-/trials/new/","nav",{"altText":416,"config":417},"GitLab-Symbol",{"src":418,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":416,"config":421},{"src":422,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":205,"config":424},{"href":425,"dataGaName":426,"dataGaLocation":414},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/get-started/","get started",{"freeTrial":428,"mobileIcon":432,"desktopIcon":434},{"text":429,"config":430},"Mehr über GitLab Duo erfahren",{"href":83,"dataGaName":431,"dataGaLocation":414},"gitlab duo",{"altText":416,"config":433},{"src":418,"dataGaName":419,"dataGaLocation":414},{"altText":416,"config":435},{"src":422,"dataGaName":419,"dataGaLocation":414},{"button":437,"mobileIcon":442,"desktopIcon":444},{"text":438,"config":439},"/Option",{"href":440,"dataGaName":441,"dataGaLocation":414},"#contact","switch",{"altText":416,"config":443},{"src":418,"dataGaName":419,"dataGaLocation":414},{"altText":416,"config":445},{"src":446,"dataGaName":419,"dataGaLocation":414},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":448,"mobileIcon":453,"desktopIcon":455},{"text":449,"config":450},"Zurück zur Preisübersicht",{"href":193,"dataGaName":451,"dataGaLocation":414,"icon":452},"back to pricing","GoBack",{"altText":416,"config":454},{"src":418,"dataGaName":419,"dataGaLocation":414},{"altText":416,"config":456},{"src":422,"dataGaName":419,"dataGaLocation":414},{"title":458,"button":459,"config":464},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":460,"config":461},"GitLab Transcend jetzt ansehen",{"href":462,"dataGaName":463,"dataGaLocation":49},"/de-de/events/transcend/virtual/","transcend event",{"layout":465,"icon":466,"disabled":12},"release","AiStar",{"data":468},{"text":469,"source":470,"edit":476,"contribute":481,"config":486,"items":491,"minimal":694},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":471,"config":472},"Quelltext der Seite anzeigen",{"href":473,"dataGaName":474,"dataGaLocation":475},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":477,"config":478},"Diese Seite bearbeiten",{"href":479,"dataGaName":480,"dataGaLocation":475},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":482,"config":483},"Beteilige dich",{"href":484,"dataGaName":485,"dataGaLocation":475},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":487,"facebook":488,"youtube":489,"linkedin":490},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[492,537,590,632,659],{"title":191,"links":493,"subMenu":508},[494,498,503],{"text":495,"config":496},"Tarife anzeigen",{"href":193,"dataGaName":497,"dataGaLocation":475},"view plans",{"text":499,"config":500},"Vorteile von Premium",{"href":501,"dataGaName":502,"dataGaLocation":475},"/de-de/pricing/premium/","why premium",{"text":504,"config":505},"Vorteile von Ultimate",{"href":506,"dataGaName":507,"dataGaLocation":475},"/de-de/pricing/ultimate/","why ultimate",[509],{"title":357,"links":510},[511,513,515,517,522,527,532],{"text":56,"config":512},{"href":58,"dataGaName":59,"dataGaLocation":475},{"text":366,"config":514},{"href":368,"dataGaName":369,"dataGaLocation":475},{"text":371,"config":516},{"href":373,"dataGaName":374,"dataGaLocation":475},{"text":518,"config":519},"Status",{"href":520,"dataGaName":521,"dataGaLocation":475},"https://status.gitlab.com/","status",{"text":523,"config":524},"Nutzungsbedingungen",{"href":525,"dataGaName":526,"dataGaLocation":475},"/terms/","terms of use",{"text":528,"config":529},"Datenschutzerklärung",{"href":530,"dataGaName":531,"dataGaLocation":475},"/de-de/privacy/","privacy statement",{"text":533,"config":534},"Cookie-Einstellungen",{"dataGaName":535,"dataGaLocation":475,"id":536,"isOneTrustButton":12},"cookie preferences","ot-sdk-btn",{"title":94,"links":538,"subMenu":547},[539,543],{"text":540,"config":541},"DevSecOps-Plattform",{"href":76,"dataGaName":542,"dataGaLocation":475},"devsecops platform",{"text":544,"config":545},"KI-unterstützte Entwicklung",{"href":83,"dataGaName":546,"dataGaLocation":475},"ai-assisted development",[548],{"title":549,"links":550},"Themen",[551,555,560,565,570,575,580,585],{"text":112,"config":552},{"href":553,"dataGaName":554,"dataGaLocation":475},"/de-de/topics/ci-cd/","cicd",{"text":556,"config":557},"GitOps",{"href":558,"dataGaName":559,"dataGaLocation":475},"/de-de/topics/gitops/","gitops",{"text":561,"config":562},"DevOps",{"href":563,"dataGaName":564,"dataGaLocation":475},"/de-de/topics/devops/","devops",{"text":566,"config":567},"Versionskontrolle",{"href":568,"dataGaName":569,"dataGaLocation":475},"/de-de/topics/version-control/","version control",{"text":571,"config":572},"DevSecOps",{"href":573,"dataGaName":574,"dataGaLocation":475},"/de-de/topics/devsecops/","devsecops",{"text":576,"config":577},"Cloud-nativ",{"href":578,"dataGaName":579,"dataGaLocation":475},"/de-de/topics/cloud-native/","cloud native",{"text":581,"config":582},"KI für das Programmieren",{"href":583,"dataGaName":584,"dataGaLocation":475},"/de-de/topics/devops/ai-for-coding/","ai for coding",{"text":586,"config":587},"Agentische KI",{"href":588,"dataGaName":589,"dataGaLocation":475},"/de-de/topics/agentic-ai/","agentic ai",{"title":591,"links":592},"Lösungen",[593,596,598,603,607,610,613,616,618,620,622,627],{"text":137,"config":594},{"href":132,"dataGaName":595,"dataGaLocation":475},"Application Security Testing",{"text":124,"config":597},{"href":108,"dataGaName":109,"dataGaLocation":475},{"text":599,"config":600},"Agile Entwicklung",{"href":601,"dataGaName":602,"dataGaLocation":475},"/de-de/solutions/agile-delivery/","agile delivery",{"text":604,"config":605},"SCM",{"href":121,"dataGaName":606,"dataGaLocation":475},"source code management",{"text":112,"config":608},{"href":114,"dataGaName":609,"dataGaLocation":475},"continuous integration & delivery",{"text":163,"config":611},{"href":165,"dataGaName":612,"dataGaLocation":475},"value stream management",{"text":556,"config":614},{"href":615,"dataGaName":559,"dataGaLocation":475},"/de-de/solutions/gitops/",{"text":176,"config":617},{"href":178,"dataGaName":179,"dataGaLocation":475},{"text":181,"config":619},{"href":183,"dataGaName":184,"dataGaLocation":475},{"text":186,"config":621},{"href":188,"dataGaName":189,"dataGaLocation":475},{"text":623,"config":624},"Bildungswesen",{"href":625,"dataGaName":626,"dataGaLocation":475},"/de-de/solutions/education/","education",{"text":628,"config":629},"Finanzdienstleistungen",{"href":630,"dataGaName":631,"dataGaLocation":475},"/de-de/solutions/finance/","financial services",{"title":196,"links":633},[634,636,638,640,643,645,647,649,651,653,655,657],{"text":208,"config":635},{"href":210,"dataGaName":211,"dataGaLocation":475},{"text":213,"config":637},{"href":215,"dataGaName":216,"dataGaLocation":475},{"text":218,"config":639},{"href":220,"dataGaName":221,"dataGaLocation":475},{"text":223,"config":641},{"href":225,"dataGaName":642,"dataGaLocation":475},"docs",{"text":246,"config":644},{"href":248,"dataGaName":249,"dataGaLocation":475},{"text":241,"config":646},{"href":243,"dataGaName":244,"dataGaLocation":475},{"text":251,"config":648},{"href":253,"dataGaName":254,"dataGaLocation":475},{"text":259,"config":650},{"href":261,"dataGaName":262,"dataGaLocation":475},{"text":264,"config":652},{"href":266,"dataGaName":267,"dataGaLocation":475},{"text":269,"config":654},{"href":271,"dataGaName":272,"dataGaLocation":475},{"text":274,"config":656},{"href":276,"dataGaName":277,"dataGaLocation":475},{"text":279,"config":658},{"href":281,"dataGaName":282,"dataGaLocation":475},{"title":297,"links":660},[661,663,665,667,669,671,673,678,683,685,687,689],{"text":304,"config":662},{"href":306,"dataGaName":299,"dataGaLocation":475},{"text":309,"config":664},{"href":311,"dataGaName":312,"dataGaLocation":475},{"text":317,"config":666},{"href":319,"dataGaName":320,"dataGaLocation":475},{"text":322,"config":668},{"href":324,"dataGaName":325,"dataGaLocation":475},{"text":327,"config":670},{"href":329,"dataGaName":330,"dataGaLocation":475},{"text":332,"config":672},{"href":334,"dataGaName":335,"dataGaLocation":475},{"text":674,"config":675},"Nachhaltigkeit",{"href":676,"dataGaName":677,"dataGaLocation":475},"/sustainability/","Sustainability",{"text":679,"config":680},"Vielfalt, Inklusion und Zugehörigkeit",{"href":681,"dataGaName":682,"dataGaLocation":475},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":337,"config":684},{"href":339,"dataGaName":340,"dataGaLocation":475},{"text":347,"config":686},{"href":349,"dataGaName":350,"dataGaLocation":475},{"text":352,"config":688},{"href":354,"dataGaName":355,"dataGaLocation":475},{"text":690,"config":691},"Transparenzerklärung zu moderner Sklaverei",{"href":692,"dataGaName":693,"dataGaLocation":475},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":695},[696,698,701],{"text":523,"config":697},{"href":525,"dataGaName":526,"dataGaLocation":475},{"text":699,"config":700},"Cookies",{"dataGaName":535,"dataGaLocation":475,"id":536,"isOneTrustButton":12},{"text":528,"config":702},{"href":530,"dataGaName":531,"dataGaLocation":475},[704],{"id":705,"title":18,"body":8,"config":706,"content":708,"description":8,"extension":28,"meta":712,"navigation":12,"path":713,"seo":714,"stem":715,"__hash__":716},"blogAuthors/en-us/blog/authors/fernando-diaz.yml",{"template":707},"BlogAuthor",{"name":18,"config":709},{"headshot":710,"ctfId":711},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659556/Blog/Author%20Headshots/fern_diaz.png","fjdiaz",{},"/en-us/blog/authors/fernando-diaz",{},"en-us/blog/authors/fernando-diaz","lxRJIOydP4_yzYZvsPcuQevP9AYAKREF7i8QmmdnOWc",[718,731,745],{"content":719,"config":729},{"title":720,"description":721,"authors":722,"heroImage":724,"date":725,"body":726,"category":9,"tags":727},"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.",[723],"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",[728,9,25],"AI/ML",{"featured":12,"template":13,"slug":730},"prepare-your-pipeline-for-ai-discovered-zero-days",{"content":732,"config":743},{"title":733,"description":734,"authors":735,"heroImage":737,"date":738,"category":9,"tags":739,"body":742},"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.",[736],"Grant Hickman","https://res.cloudinary.com/about-gitlab-com/image/upload/v1774375772/kpaaaiqhokevxxeoxvu0.png","2026-03-25",[9,23,571,740,741],"features","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":744,"featured":12,"template":13},"auto-dismiss-vulnerability-management-policy",{"content":746,"config":755},{"title":747,"description":748,"authors":749,"heroImage":751,"date":752,"body":753,"category":9,"tags":754},"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.",[750],"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/).",[741,9,740],{"featured":35,"template":13,"slug":756},"gitlab-18-10-brings-ai-native-triage-and-remediation",{"promotions":758},[759,773,784,795],{"id":760,"categories":761,"header":763,"text":764,"button":765,"image":770},"ai-modernization",[762],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":766,"config":767},"Get your AI maturity score",{"href":768,"dataGaName":769,"dataGaLocation":249},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":771},{"src":772},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":774,"categories":775,"header":776,"text":764,"button":777,"image":781},"devops-modernization",[741,574],"Are you just managing tools or shipping innovation?",{"text":778,"config":779},"Get your DevOps maturity score",{"href":780,"dataGaName":769,"dataGaLocation":249},"/assessments/devops-modernization-assessment/",{"config":782},{"src":783},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":785,"categories":786,"header":787,"text":764,"button":788,"image":792},"security-modernization",[9],"Are you trading speed for security?",{"text":789,"config":790},"Get your security maturity score",{"href":791,"dataGaName":769,"dataGaLocation":249},"/assessments/security-modernization-assessment/",{"config":793},{"src":794},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":796,"paths":797,"header":800,"text":801,"button":802,"image":807},"github-azure-migration",[798,799],"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":803,"config":804},"See how GitLab compares to GitHub",{"href":805,"dataGaName":806,"dataGaLocation":249},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":808},{"src":783},{"header":810,"blurb":811,"button":812,"secondaryButton":817},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":813,"config":814},"Kostenlosen Test starten",{"href":815,"dataGaName":54,"dataGaLocation":816},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/de-de/","feature",{"text":56,"config":818},{"href":58,"dataGaName":59,"dataGaLocation":816},1777576594302]