[{"data":1,"prerenderedAt":787},["ShallowReactive",2],{"/de-de/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features":3,"navigation-de-de":42,"banner-de-de":445,"footer-de-de":455,"blog-post-authors-de-de-Cherry Han|Gavin Peltz":659,"blog-related-posts-de-de-finserv-how-to-implement-gitlabs-separation-of-duties-features":685,"blog-promotions-de-de":724,"next-steps-de-de":777},{"id":4,"title":5,"authorSlugs":6,"body":9,"categorySlug":10,"config":11,"content":15,"description":9,"extension":29,"isFeatured":13,"meta":30,"navigation":31,"path":32,"publishedDate":22,"seo":33,"stem":37,"tagSlugs":38,"__hash__":41},"blogPosts/de-de/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features.yml","Finserv How To Implement Gitlabs Separation Of Duties Features",[7,8],"cherry-han","gavin-peltz",null,"security",{"slug":12,"featured":13,"template":14},"finserv-how-to-implement-gitlabs-separation-of-duties-features",false,"BlogPost",{"title":16,"description":17,"authors":18,"heroImage":21,"date":22,"body":23,"category":10,"tags":24,"updatedDate":28},"FinServ: So implementierst du die Funktion zur Aufgabentrennung von GitLab","Wie GitLab eine sichere Softwareentwicklung mit Aufgabentrennung im Finanzdienstleistungssektor gewährleistet, einschließlich der Einhaltung regulatorischer Rahmenbedingungen.",[19,20],"Cherry Han","Gavin Peltz","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097688/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%286%29_6vL96ttKF8zJLLqfPpvFs_1750097687913.png","2024-08-13","Während der gesamten Softwareentwicklung sind robuste Sicherheits- und Compliance-Maßnahmen erforderlich, insbesondere in Branchen wie Finanzdienstleistungen, in denen Datenintegrität und Einhaltung der Vorschriften nicht verhandelbar sind. Ein kritischer Aspekt bei der Einhaltung dieser Standards ist die **Aufgabentrennung (SoD, \"Segregation of Duties\")**.\n\n**SoD stellt sicher, dass keine Person die vollständige Kontrolle über einen Prozess vom Anfang bis zum Ende hat**, wodurch das Risiko von Fehlern und unbefugten Aktivitäten verringert wird. SoD verringert die Risiken der Software-Lieferkette, indem externe und böswillige Handlungen verhindert werden, die die Integrität des Softwareentwicklungsprozesses beeinträchtigen könnten.\n\n## Bedeutung von SoD in der Finanzdienstleistungsbranche\n\nIm Finanzdienstleistungssektor spielt SoD eine entscheidende Rolle beim Schutz sensibler Informationen und der Einhaltung der Vorschriften. So trägt SoD strategisch zur Branche bei:\n\n* **Risikominderung:** Durch die Verteilung der Verantwortlichkeiten auf verschiedene Rollen verringert SoD das Risiko von Fehlern, Betrug und unbefugten Aktivitäten, die die Systemintegrität oder die Einhaltung der Vorschriften beeinträchtigen könnten.\n* **Verbesserte Verantwortlichkeit:** Eine klare Aufteilung der Aufgaben garantiert, dass keine Person einen Prozess von Anfang bis Ende unabhängig initiieren, autorisieren und ausführen kann. Dies fördert Transparenz und Verantwortlichkeit, die für die Aufrechterhaltung des Vertrauens bei Stakeholdern und Aufsichtsbehörden von entscheidender Bedeutung sind.\n* **Einhaltung der Vorschriften:** SoD ist durch die Finanzvorschriften vorgeschrieben, sodass sensible Vorgänge unter Aufsicht und Kontrolle durchgeführt werden. Die Einhaltung dieser Standards vermeidet nicht nur Strafen, sondern schützt auch den Ruf des Unternehmens.\n* **Betriebliche Widerstandsfähigkeit:** Durch die Dezentralisierung der Entscheidungsfindung und -ausführung werden Unternehmen weniger anfällig für Störungen, die durch menschliche Fehler, böswillige Handlungen oder unerwartete Ereignisse verursacht werden.\n\n## GitLab für SoD und Best Practices\nGitLab bietet eine durchgängige Aufgabentrennung für den DevSecOps-Workflow.\n\n![FinServ SOD - Bild 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097695/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097695697.png)\n\nDas obige Diagramm veranschaulicht die Integration von Schlüsselelementen wie Genehmigungsrichtlinien für die Genehmigung von Merge Requests, geschützte Funktionen, Benutzerberechtigungen, Compliance-Frameworks und Audit-Ereignisse, die alle zusammenarbeiten, um die Prinzipien von SoD aufrechtzuerhalten. Jede dieser Komponenten wird in den folgenden Abschnitten beschrieben und zeigt, wie man eine sichere und konforme Entwicklungsumgebung einrichtet.\n\n### Merge-Request-Genehmigungsrichtlinien\n\nEine Herausforderung für die Finanzdienstleistungsbranche ist die Implementierung von Genehmigungsmechanismen, die verhindern, dass unbefugte oder unkontrollierte Änderungen integriert werden. Hier kommen [Merge-Request-Genehmigungsrichtlinien](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) ins Spiel. Diese Richtlinien erzwingen die Aufgabentrennung zwischen Sicherheit und Entwicklung und verhindern, dass einzelne Entwickler(innen) ihre eigenen Codeänderungen genehmigen, wenn sie Schwachstellen enthalten, und dass Entwicklungsteams ihren Code ohne angemessene Aufsicht direkt in Produktivumgebungen bereitstellen.\nBei der Erstellung einer Richtlinie ist es ratsam zu überlegen, wer eine geeignete Person für die Genehmigung wäre. Dies kann als ein(e) einzelne(r) Benutzer(in), eine Gruppe wie das Anwendungssicherheitsteam oder ein Rollentyp wie ein(e) Betreuer(in) definiert werden. Um weitere Einschränkungen zu implementieren, beachte bitte diese wichtigen Richtlinienmerkmale:\n\n- Verhindern der Genehmigung durch den bzw. die Autor(in): Diese Richtlinie legt Leitlinien fest, sodass ein(e) Merge-Request-Autor(in) seine eigenen Änderungen nicht genehmigen kann. Indem diese Richtlinie eine unabhängige Überprüfung erfordert, hilft sie, Objektivität und Unparteilichkeit im Genehmigungsprozess aufrechtzuerhalten.\n\n- Verhindern von Genehmigungen durch Benutzer(innen), die Commits hinzufügen: Benutzer(innen), die Commits zu einem Merge Request hinzugefügt haben, werden ebenfalls daran gehindert, diesen zu genehmigen. Dadurch wird das Prinzip der unabhängigen Überprüfung weiter durchgesetzt, sodass Änderungen von Teammitgliedern überprüft werden, die nicht direkt an den Änderungen beteiligt sind.\n\n- Verhindern des Bearbeitens von Genehmigungsregeln: Um die Integrität des Genehmigungsprozesses aufrechtzuerhalten, ermöglicht GitLab Administrator(inn)en, das Bearbeiten von Genehmigungsregeln auf Projekt- oder Merge-Request-Ebene zu verhindern. Dies garantiert, dass einmal definierte Genehmigungsrichtlinien nicht von unbefugten Benutzer(inne)n umgangen oder geändert werden können.\n\n- Benutzerpasswort zum Genehmigen anfordern: Für eine zusätzliche Sicherheitsebene kann GitLab von Benutzer(inne)n verlangen, dass sie ihr Passwort eingeben, um einen Merge Request zu genehmigen.\nUm eine klare Aufgabentrennung aufrechtzuerhalten, ist es ratsam, [eine separate Hauptgruppe zu erstellen](https://docs.gitlab.com/ee/user/application_security/policies/#enforce-policies-globally-in-gitlab-dedicated-or-your-gitlab-self-managed-instance), die sich mit der Unterbringung deiner Sicherheitsrichtlinien befasst, einschließlich der Richtlinien für die Genehmigung von Merge Requests. Dieses Setup minimiert die Anzahl der Benutzer(innen), die Berechtigungen erben, und erzwingt eine strengere Kontrolle über die Richtlinienverwaltung. Von dieser separaten Gruppe aus kannst du auf der höchsten Gruppenebene, die mit deinen Zielen übereinstimmt, den Verwaltungsaufwand für Richtlinien reduziert und eine umfassende Abdeckung Ihrer Entwicklungsumgebung bietet, [Sicherheitsrichtlinienprojekte verlinken](https://docs.gitlab.com/ee/user/application_security/policies/#link-to-a-security-policy-project).\n\nDu solltest auch beachten, dass eine Richtlinie, die standardmäßig aktiviert ist, für alle Projekte innerhalb der verlinkten Gruppen, Untergruppen und einzelnen Projekte gilt. Wenn du Richtlinien selektiver durchsetzen möchtest, empfiehlt GitLab, deine Richtlinien auf ein [Compliance-Framework-Label](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html) auszudehnen. In der Regel werden unsere stark regulierten Kund(inn)en Compliance-Labels entwerfen, die den regulatorischen Anforderungen entsprechen, wie „SOX“ und „PCI“. Dieser Link zu einem Framework ermöglicht es dem [nativen Compliance-Center](https://docs.gitlab.com/ee/user/compliance/compliance_center/) auch, Sicherheitsrichtlinien zu verwalten, die auf verschiedene Anwendungsfälle zugeschnitten sind.\n\n### Compliance-Frameworks und -Kontrollen\n\nKund(inn)en in regulierten Branchen stehen vor großen Herausforderungen bei der Einhaltung der Vorschriften in großen Unternehmen. Manuelle Prozesse sind fehleranfällig, und die konsistente Durchsetzung von Richtlinien über Teams hinweg kann schwierig sein.\n\nDurch die Verwendung der Compliance-Frameworks von GitLab können Unternehmen Präventionsmaßnahmen automatisieren und verwalten, Risiken systematisch verwalten und die Einhaltung gesetzlicher Vorschriften nahtlos durchsetzen. Diese Frameworks können Sicherheitsprotokolle und benutzerdefinierte Jobs in jeder Pipeline erzwingen.\nUm die Compliance-Einstellungen auf Organisationsebene zu schützen, ermöglicht GitLab nur Gruppen- oder Projekteigentümer(innen), Compliance Frameworks hinzuzufügen oder zu entfernen. Diese Maßnahme verhindert, dass Entwicklungsteams oder Führungskräfte Compliance-Konfigurationen ohne die entsprechenden Berechtigungsstufen ändern, und bietet auf diese Weise eine zusätzliche Sicherheitsebene. Dabei sollte Folgendes beachtet werden: Wenn Personen mit Betreuerberechtigung eine Untergruppe erstellen können, werden sie zu Eigentümer(innen) der jeweiligen Untergruppe und können das Compliance-Framework ändern. Dies kann verhindert werden, indem [begrenzt wird, welche Personen Untergruppen erstellen können](https://docs.gitlab.com/ee/user/group/subgroups/#change-who-can-create-subgroups), und zwar unter den Berechtigungen und Gruppeneinstellungen.\n\n## SoD durch Berechtigungen und Rollen\n\nUm die Aufgabentrennung in der Finanzdienstleistungsbranche auf effektive Weise durchzusetzen, ist entscheidend, dass eine klare und präzise Zugriffskontrolle etabliert wird. GitLab bietet ein abgestuftes [Berechtigungsmodell](https://docs.gitlab.com/ee/user/permissions.html) mit vordefinierten Rollen, zum Beispiel Gast, Reporter(in), Entwickler(in), Betreuer(in) und Eigentümer(in). Jede Rolle verfügt über eine bestimmte Reihe von Berechtigungen, damit Personen ihre Aufgaben erfüllen können, ohne Grenzen zu überschreiten, was wiederum zu Interessenskonflikten oder Sicherheitsrisiken führen könnte. GitLab empfiehlt eine entsprechende Zuweisung der jeweiligen Rollen für einen [Zugriff gemäß dem Prinzip der geringsten Privilegien](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/).\n\nWas Unternehmen mit granularen Anforderungen betrifft (dies gilt besonders für alle, die GitLab Ultimate nutzen), bieten [benutzerdefinierte Rollen](https://docs.gitlab.com/ee/user/custom_roles.html) noch mehr Flexibilität. Diese Rollen ermöglichen Unternehmen, spezifische Berechtigungen festzulegen, die ganz auf ihre individuellen Workflows und Compliance-Anforderungen zugeschnitten sind. Dies ist besonders nützlich, wenn es darum geht, die Aufgabentrennung durchzusetzen, da auf diese Weise keine Person unvereinbare Aufgaben ausführen kann.\n\nEin gängiger Anwendungsfall ist die Notwendigkeit einer Bereitstellungsrolle – dies betrifft Personen, die Jobs bereitstellen müssen, aber keinen Zugriff für das Bearbeiten oder Pushen von Code haben sollten. GitLab berücksichtigt diese Anforderung durch den Einsatz von [geschützten Umgebungen](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#protecting-environments). Geschützte Umgebungen ermöglichen dir, [Gruppen einzuladen, die zur Bereitstellung von Jobs zugelassen wurden](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#deployment-only-access-to-protected-environments), während die Rolle der Nutzer(innen) auf Reporter(innen) beschränkt wird. Dabei sollte beachtet werden, dass der Bereitstellungsjob auch das Keyword für die Umgebung umfassen sollte. Mit dieser Konfiguration können Nutzer(innen) Jobs bereitstellen, ohne den Code bearbeiten zu können. Damit wird sichergestellt, dass die Compliance-Anforderungen erfüllt werden.\nDurch sorgfältige Festlegung und Durchsetzung von Rollen und Berechtigungen können Unternehmen eine sichere und konforme Entwicklungsumgebung schaffen. Wenn du deine Berechtigungen für Nutzer(innen) in einem breiteren Rahmen überprüfen möchtest, kannst du diesen [Bericht für Gruppenmitglieder](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/gitlab-group-member-report) nutzen, um festzustellen, wie viele Mitglieder einer Rolle in deiner Umgebung sind, und die nächsten Schritte entsprechend beurteilen.\n\n## Geschützte Funktionen\nGitLab bietet mehrere „geschützte” Funktionen, mit denen zusätzliche Ebenen für die Kontrolle über deinen Entwicklungsprozess durchgesetzt werden können. Diese Funktionen können entscheidend für die Aufrechterhaltung der SoD sein, sodass nur bestimmte Personen wesentliche Änderungen vornehmen können.\n\n- Geschützte Branches: Ein geschützter Branch beschränkt, welche Personen zum Branch pushen oder zusammenführen oder einen Push erzwingen können. Dies ist besonders vorteilhaft für Branches wie „Main“ oder „Produktion“. So können nur autorisierte Nutzer(innen) Änderungen vornehmen.\n- Geschützte Git-Tags: Diese Tags ermöglichen Kontrolle darüber, welche Personen zur Erstellung von Tags berechtigt sind. Dies verhindert versehentliche Updates oder Löschungen, nachdem das Tag erstellt wurde, sodass die Integrität deiner Versionsverwaltung erhalten bleibt.\n- Geschützte Umgebungen: Der Schutz bestimmter Umgebungen (besonders Produktionen) vor unbefugtem Zugriff ist unerlässlich. In einer geschützten Umgebung können nur Nutzer(innen) mit den entsprechenden Berechtigungen bereitstellen, wodurch die Umgebung vor unbeabsichtigten Änderungen geschützt wird. Dies basiert auf der bereits erwähnten Funktionalität der Bereitstellungsrolle, bei der Personen zwar Jobs bereitstellen, aber den Code nicht bearbeiten können, sodass Compliance und Sicherheit gewährleistet werden.\n- Geschützte Pakete: Mithilfe von Schutzregeln für Pakete wird eingeschränkt, welche Nutzer(innen) Änderungen an deinen Paketen vornehmen können. Diese geschützten Funktionen tragen zusammen zur Aufrechterhaltung einer sicheren und konformen Entwicklungsumgebung bei, die mit den Grundsätzen der SoD übereinstimmt.\n\n## Audit Event und Compliance Center\nNachdem wir nun die Approvalrichtlinien, Compliance Frameworks, Rollen und geschützten Funktionen behandelt haben, kommen wir zum letzten Schritt: die Frage, wie du mithilfe von GitLab diese Implementierungen überwachen und überprüfen kannst, um die Einhaltung sicherzustellen.\nGitLabs [Audit Events](https://docs.gitlab.com/ee/user/compliance/audit_events.html) bieten Eigentümer(innen) und Administrator(innen) eine detaillierte Aufzeichnung der Aktivitäten und Änderungen, darunter die Aktivität der Nutzer(innen) und Projektänderungen. Diese Protokollierung ist entscheidend, wenn es darum geht, die Aktionen der Nutzer(innen) zu verfolgen und unbefugtes Verhalten zu erkennen.\nDas [Streaming von Audit Events](https://docs.gitlab.com/ee/user/compliance/audit_event_streaming.html) verbessert diesen Aspekt zusätzlich, indem es Unternehmen ermöglicht, Audit Events zur Echtzeitanalyse und Alarme an externe Systeme zu streamen. Auf diese Weise werden jegliche Änderungen oder Verstöße erkannt, was wiederum eine schnelle Behebung ermöglicht.\n\nDas [Compliance Center in GitLab](https://docs.gitlab.com/ee/user/compliance/compliance_center/) ist ein zentraler Punkt für die Verwaltung und Überwachung von Compliance-Aktivitäten. Es bietet einen Überblick zum Compliance-Status über diverse Projekte und Gruppen hinweg und zeigt Verstöße gegen die Approvalregeln für Merge Requests oder andere Richtlinien. Administrator(innen) können Probleme direkt beheben und sich vergewissern, dass die vordefinierten Compliance-Standards eingehalten werden. Dieser zentralisierte Ansatz vereinfacht das Compliance-Management, wobei ein hohes Maß an Beaufsichtigung und Kontrolle gewährleistet wird.\n\n> Weitere Informationen von GitLab zu den Themen SoD und Compliance findest du unter [GitLab-Regulierung der Produktrichtung](https://docs.gitlab.com/user/application_security/) und der [GitLab-Compliance-Dokumentation](https://docs.gitlab.com/ee/administration/compliance.html).\n## Weiterlesen\n\n- [Erfülle regulatorische Standards mit dem Compliance- und Sicherheitsrichtlinien-Management von GitLab](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/) (Englischsprachiger Artikel)\n- [Die Erstellung von GitLab mithilfe von GitLab: Erweiterung unseres Portfolios an Sicherheitszertifizierungen](https://about.gitlab.com/blog/building-gitlab-with-gitlab-expanding-our-security-certification-portfolio/) (Englischsprachiger Artikel)\n- [Der Online-Händler Bol erfüllt die wachsenden Compliance-Anforderungen mit GitLab](https://about.gitlab.com/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab/) (Englischsprachiger Artikel)",[10,25,26,27],"DevSecOps platform","product","financial services","2025-04-22","yml",{},true,"/de-de/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"title":16,"description":17,"ogTitle":16,"ogDescription":17,"noIndex":13,"ogImage":21,"ogUrl":34,"ogSiteName":35,"ogType":36,"canonicalUrls":34},"https://about.gitlab.com/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features","https://about.gitlab.com","article","de-de/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",[10,39,26,40],"devsecops-platform","financial-services","JMu8I8maYAFvcBmxthr3BuIqRymDjmDF49jnMilrXXI",{"data":43},{"logo":44,"freeTrial":49,"sales":54,"login":59,"items":64,"search":373,"minimal":408,"duo":426,"pricingDeployment":435},{"config":45},{"href":46,"dataGaName":47,"dataGaLocation":48},"/de-de/","gitlab logo","header",{"text":50,"config":51},"Kostenlose Testversion anfordern",{"href":52,"dataGaName":53,"dataGaLocation":48},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de&glm_content=default-saas-trial/","free trial",{"text":55,"config":56},"Vertrieb kontaktieren",{"href":57,"dataGaName":58,"dataGaLocation":48},"/de-de/sales/","sales",{"text":60,"config":61},"Anmelden",{"href":62,"dataGaName":63,"dataGaLocation":48},"https://gitlab.com/users/sign_in/","sign in",[65,92,188,193,294,354],{"text":66,"config":67,"cards":69},"Plattform",{"dataNavLevelOne":68},"platform",[70,76,84],{"title":66,"description":71,"link":72},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":73,"config":74},"Erkunde unsere Plattform",{"href":75,"dataGaName":68,"dataGaLocation":48},"/de-de/platform/",{"title":77,"description":78,"link":79},"GitLab Duo Agent Platform","Agentische KI für den gesamten Softwareentwicklungszyklus",{"text":80,"config":81},"Lerne GitLab Duo kennen",{"href":82,"dataGaName":83,"dataGaLocation":48},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":85,"description":86,"link":87},"Gründe, die für GitLab sprechen","Erfahre, warum Unternehmen auf GitLab setzen",{"text":88,"config":89},"Mehr erfahren",{"href":90,"dataGaName":91,"dataGaLocation":48},"/de-de/why-gitlab/","why gitlab",{"text":93,"left":31,"config":94,"link":96,"lists":100,"footer":170},"Produkt",{"dataNavLevelOne":95},"solutions",{"text":97,"config":98},"Alle Lösungen anzeigen",{"href":99,"dataGaName":95,"dataGaLocation":48},"/de-de/solutions/",[101,126,148],{"title":102,"description":103,"link":104,"items":109},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":105},{"icon":106,"href":107,"dataGaName":108,"dataGaLocation":48},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[110,114,117,122],{"text":111,"config":112},"CI/CD",{"href":113,"dataGaLocation":48,"dataGaName":111},"/de-de/solutions/continuous-integration/",{"text":77,"config":115},{"href":82,"dataGaLocation":48,"dataGaName":116},"gitlab duo agent platform - product menu",{"text":118,"config":119},"Quellcodeverwaltung",{"href":120,"dataGaLocation":48,"dataGaName":121},"/de-de/solutions/source-code-management/","Source Code Management",{"text":123,"config":124},"Automatisierte Softwarebereitstellung",{"href":107,"dataGaLocation":48,"dataGaName":125},"Automated software delivery",{"title":127,"description":128,"link":129,"items":134},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":130},{"href":131,"dataGaName":132,"dataGaLocation":48,"icon":133},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[135,139,144],{"text":136,"config":137},"Application Security Testing",{"href":131,"dataGaName":138,"dataGaLocation":48},"Application security testing",{"text":140,"config":141},"Schutz der Software-Lieferkette",{"href":142,"dataGaLocation":48,"dataGaName":143},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Software Compliance",{"href":147,"dataGaName":145,"dataGaLocation":48},"/de-de/solutions/software-compliance/",{"title":149,"link":150,"items":155},"Bewertung",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":48},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[156,160,165],{"text":157,"config":158},"Sichtbarkeit und Bewertung",{"href":153,"dataGaLocation":48,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"Wertstrommanagement",{"href":163,"dataGaLocation":48,"dataGaName":164},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":166,"config":167},"Analysen und Einblicke",{"href":168,"dataGaLocation":48,"dataGaName":169},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLab für",[173,178,183],{"text":174,"config":175},"Enterprise",{"href":176,"dataGaLocation":48,"dataGaName":177},"/de-de/enterprise/","enterprise",{"text":179,"config":180},"Kleinunternehmen",{"href":181,"dataGaLocation":48,"dataGaName":182},"/de-de/small-business/","small business",{"text":184,"config":185},"den öffentlichen Sektor",{"href":186,"dataGaLocation":48,"dataGaName":187},"/de-de/solutions/public-sector/","public sector",{"text":189,"config":190},"Preise",{"href":191,"dataGaName":192,"dataGaLocation":48,"dataNavLevelOne":192},"/de-de/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":281},"Ressourcen",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"Alle Ressourcen anzeigen",{"href":200,"dataGaName":196,"dataGaLocation":48},"/de-de/resources/",[202,235,253],{"title":203,"items":204},"Erste Schritte",[205,210,215,220,225,230],{"text":206,"config":207},"Installieren",{"href":208,"dataGaName":209,"dataGaLocation":48},"/de-de/install/","install",{"text":211,"config":212},"Kurzanleitungen",{"href":213,"dataGaName":214,"dataGaLocation":48},"/de-de/get-started/","quick setup checklists",{"text":216,"config":217},"Lernen",{"href":218,"dataGaLocation":48,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"Produktdokumentation",{"href":223,"dataGaName":224,"dataGaLocation":48},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"Best-Practice-Videos",{"href":228,"dataGaName":229,"dataGaLocation":48},"/de-de/getting-started-videos/","best practice videos",{"text":231,"config":232},"Integrationen",{"href":233,"dataGaName":234,"dataGaLocation":48},"/de-de/integrations/","integrations",{"title":236,"items":237},"Entdecken",[238,243,248],{"text":239,"config":240},"Kundenerfolge",{"href":241,"dataGaName":242,"dataGaLocation":48},"/de-de/customers/","customer success stories",{"text":244,"config":245},"Blog",{"href":246,"dataGaName":247,"dataGaLocation":48},"/de-de/blog/","blog",{"text":249,"config":250},"Remote",{"href":251,"dataGaName":252,"dataGaLocation":48},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":254,"items":255},"Vernetzen",[256,261,266,271,276],{"text":257,"config":258},"GitLab-Services",{"href":259,"dataGaName":260,"dataGaLocation":48},"/de-de/services/","services",{"text":262,"config":263},"Community",{"href":264,"dataGaName":265,"dataGaLocation":48},"/community/","community",{"text":267,"config":268},"Forum",{"href":269,"dataGaName":270,"dataGaLocation":48},"https://forum.gitlab.com/","forum",{"text":272,"config":273},"Veranstaltungen",{"href":274,"dataGaName":275,"dataGaLocation":48},"/events/","events",{"text":277,"config":278},"Partner",{"href":279,"dataGaName":280,"dataGaLocation":48},"/de-de/partners/","partners",{"backgroundColor":282,"textColor":283,"text":284,"image":285,"link":289},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":286,"config":287},"the source promo card",{"src":288},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":290,"config":291},"Lies die News",{"href":292,"dataGaName":293,"dataGaLocation":48},"/de-de/the-source/","the source",{"text":295,"config":296,"lists":298},"Unternehmen",{"dataNavLevelOne":297},"company",[299],{"items":300},[301,306,312,314,319,324,329,334,339,344,349],{"text":302,"config":303},"Über",{"href":304,"dataGaName":305,"dataGaLocation":48},"/de-de/company/","about",{"text":307,"config":308,"footerGa":311},"Karriere",{"href":309,"dataGaName":310,"dataGaLocation":48},"/jobs/","jobs",{"dataGaName":310},{"text":272,"config":313},{"href":274,"dataGaName":275,"dataGaLocation":48},{"text":315,"config":316},"Geschäftsführung",{"href":317,"dataGaName":318,"dataGaLocation":48},"/company/team/e-group/","leadership",{"text":320,"config":321},"Team",{"href":322,"dataGaName":323,"dataGaLocation":48},"/company/team/","team",{"text":325,"config":326},"Handbuch",{"href":327,"dataGaName":328,"dataGaLocation":48},"https://handbook.gitlab.com/","handbook",{"text":330,"config":331},"Investor Relations",{"href":332,"dataGaName":333,"dataGaLocation":48},"https://ir.gitlab.com/","investor relations",{"text":335,"config":336},"Trust Center",{"href":337,"dataGaName":338,"dataGaLocation":48},"/de-de/security/","trust center",{"text":340,"config":341},"AI Transparency Center",{"href":342,"dataGaName":343,"dataGaLocation":48},"/de-de/ai-transparency-center/","ai transparency center",{"text":345,"config":346},"Newsletter",{"href":347,"dataGaName":348,"dataGaLocation":48},"/company/contact/#contact-forms","newsletter",{"text":350,"config":351},"Presse",{"href":352,"dataGaName":353,"dataGaLocation":48},"/press/","press",{"text":355,"config":356,"lists":357},"Kontakt",{"dataNavLevelOne":297},[358],{"items":359},[360,363,368],{"text":55,"config":361},{"href":57,"dataGaName":362,"dataGaLocation":48},"talk to sales",{"text":364,"config":365},"Support-Portal",{"href":366,"dataGaName":367,"dataGaLocation":48},"https://support.gitlab.com","support portal",{"text":369,"config":370},"Kundenportal",{"href":371,"dataGaName":372,"dataGaLocation":48},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":374,"login":375,"suggestions":382},"Schließen",{"text":376,"link":377},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":378,"config":379},"gitlab.com",{"href":62,"dataGaName":380,"dataGaLocation":381},"search login","search",{"text":383,"default":384},"Vorschläge",[385,387,392,394,399,404],{"text":77,"config":386},{"href":82,"dataGaName":77,"dataGaLocation":381},{"text":388,"config":389},"Code Suggestions (KI)",{"href":390,"dataGaName":391,"dataGaLocation":381},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":111,"config":393},{"href":113,"dataGaName":111,"dataGaLocation":381},{"text":395,"config":396},"GitLab auf AWS",{"href":397,"dataGaName":398,"dataGaLocation":381},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":400,"config":401},"GitLab auf Google Cloud",{"href":402,"dataGaName":403,"dataGaLocation":381},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":405,"config":406},"Warum GitLab?",{"href":90,"dataGaName":407,"dataGaLocation":381},"Why GitLab?",{"freeTrial":409,"mobileIcon":414,"desktopIcon":419,"secondaryButton":422},{"text":410,"config":411},"Kostenlos testen",{"href":412,"dataGaName":53,"dataGaLocation":413},"https://gitlab.com/-/trials/new/","nav",{"altText":415,"config":416},"GitLab-Symbol",{"src":417,"dataGaName":418,"dataGaLocation":413},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":415,"config":420},{"src":421,"dataGaName":418,"dataGaLocation":413},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":203,"config":423},{"href":424,"dataGaName":425,"dataGaLocation":413},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/get-started/","get started",{"freeTrial":427,"mobileIcon":431,"desktopIcon":433},{"text":428,"config":429},"Erfahre mehr über GitLab Duo",{"href":82,"dataGaName":430,"dataGaLocation":413},"gitlab duo",{"altText":415,"config":432},{"src":417,"dataGaName":418,"dataGaLocation":413},{"altText":415,"config":434},{"src":421,"dataGaName":418,"dataGaLocation":413},{"freeTrial":436,"mobileIcon":441,"desktopIcon":443},{"text":437,"config":438},"Zurück zur Preisübersicht",{"href":191,"dataGaName":439,"dataGaLocation":413,"icon":440},"back to pricing","GoBack",{"altText":415,"config":442},{"src":417,"dataGaName":418,"dataGaLocation":413},{"altText":415,"config":444},{"src":421,"dataGaName":418,"dataGaLocation":413},{"title":446,"button":447,"config":452},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":448,"config":449},"GitLab Transcend jetzt ansehen",{"href":450,"dataGaName":451,"dataGaLocation":48},"/de-de/events/transcend/virtual/","transcend event",{"layout":453,"icon":454,"disabled":31},"release","AiStar",{"data":456},{"text":457,"source":458,"edit":464,"contribute":469,"config":474,"items":479,"minimal":651},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":459,"config":460},"Quelltext der Seite anzeigen",{"href":461,"dataGaName":462,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":465,"config":466},"Diese Seite bearbeiten",{"href":467,"dataGaName":468,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":470,"config":471},"Beteilige dich",{"href":472,"dataGaName":473,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":475,"facebook":476,"youtube":477,"linkedin":478},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[480,503,557,584,618],{"title":66,"links":481,"subMenu":486},[482],{"text":483,"config":484},"DevSecOps-Plattform",{"href":75,"dataGaName":485,"dataGaLocation":463},"devsecops platform",[487],{"title":189,"links":488},[489,493,498],{"text":490,"config":491},"Tarife anzeigen",{"href":191,"dataGaName":492,"dataGaLocation":463},"view plans",{"text":494,"config":495},"Vorteile von Premium",{"href":496,"dataGaName":497,"dataGaLocation":463},"/de-de/pricing/premium/","why premium",{"text":499,"config":500},"Vorteile von Ultimate",{"href":501,"dataGaName":502,"dataGaLocation":463},"/de-de/pricing/ultimate/","why ultimate",{"title":504,"links":505},"Lösungen",[506,511,514,516,521,526,530,533,536,541,543,545,548,553],{"text":507,"config":508},"Digitale Transformation",{"href":509,"dataGaName":510,"dataGaLocation":463},"/de-de/topics/digital-transformation/","digital transformation",{"text":512,"config":513},"Sicherheit und Compliance",{"href":131,"dataGaName":138,"dataGaLocation":463},{"text":123,"config":515},{"href":107,"dataGaName":108,"dataGaLocation":463},{"text":517,"config":518},"Agile Entwicklung",{"href":519,"dataGaName":520,"dataGaLocation":463},"/de-de/solutions/agile-delivery/","agile delivery",{"text":522,"config":523},"Cloud-Transformation",{"href":524,"dataGaName":525,"dataGaLocation":463},"/de-de/topics/cloud-native/","cloud transformation",{"text":527,"config":528},"SCM",{"href":120,"dataGaName":529,"dataGaLocation":463},"source code management",{"text":111,"config":531},{"href":113,"dataGaName":532,"dataGaLocation":463},"continuous integration & delivery",{"text":161,"config":534},{"href":163,"dataGaName":535,"dataGaLocation":463},"value stream management",{"text":537,"config":538},"GitOps",{"href":539,"dataGaName":540,"dataGaLocation":463},"/de-de/solutions/gitops/","gitops",{"text":174,"config":542},{"href":176,"dataGaName":177,"dataGaLocation":463},{"text":179,"config":544},{"href":181,"dataGaName":182,"dataGaLocation":463},{"text":546,"config":547},"Öffentlicher Sektor",{"href":186,"dataGaName":187,"dataGaLocation":463},{"text":549,"config":550},"Bildungswesen",{"href":551,"dataGaName":552,"dataGaLocation":463},"/de-de/solutions/education/","education",{"text":554,"config":555},"Finanzdienstleistungen",{"href":556,"dataGaName":27,"dataGaLocation":463},"/de-de/solutions/finance/",{"title":194,"links":558},[559,561,563,565,568,570,572,574,576,578,580,582],{"text":206,"config":560},{"href":208,"dataGaName":209,"dataGaLocation":463},{"text":211,"config":562},{"href":213,"dataGaName":214,"dataGaLocation":463},{"text":216,"config":564},{"href":218,"dataGaName":219,"dataGaLocation":463},{"text":221,"config":566},{"href":223,"dataGaName":567,"dataGaLocation":463},"docs",{"text":244,"config":569},{"href":246,"dataGaName":247,"dataGaLocation":463},{"text":239,"config":571},{"href":241,"dataGaName":242,"dataGaLocation":463},{"text":249,"config":573},{"href":251,"dataGaName":252,"dataGaLocation":463},{"text":257,"config":575},{"href":259,"dataGaName":260,"dataGaLocation":463},{"text":262,"config":577},{"href":264,"dataGaName":265,"dataGaLocation":463},{"text":267,"config":579},{"href":269,"dataGaName":270,"dataGaLocation":463},{"text":272,"config":581},{"href":274,"dataGaName":275,"dataGaLocation":463},{"text":277,"config":583},{"href":279,"dataGaName":280,"dataGaLocation":463},{"title":295,"links":585},[586,588,590,592,594,596,598,602,607,609,611,613],{"text":302,"config":587},{"href":304,"dataGaName":297,"dataGaLocation":463},{"text":307,"config":589},{"href":309,"dataGaName":310,"dataGaLocation":463},{"text":315,"config":591},{"href":317,"dataGaName":318,"dataGaLocation":463},{"text":320,"config":593},{"href":322,"dataGaName":323,"dataGaLocation":463},{"text":325,"config":595},{"href":327,"dataGaName":328,"dataGaLocation":463},{"text":330,"config":597},{"href":332,"dataGaName":333,"dataGaLocation":463},{"text":599,"config":600},"Sustainability",{"href":601,"dataGaName":599,"dataGaLocation":463},"/sustainability/",{"text":603,"config":604},"Vielfalt, Inklusion und Zugehörigkeit",{"href":605,"dataGaName":606,"dataGaLocation":463},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":335,"config":608},{"href":337,"dataGaName":338,"dataGaLocation":463},{"text":345,"config":610},{"href":347,"dataGaName":348,"dataGaLocation":463},{"text":350,"config":612},{"href":352,"dataGaName":353,"dataGaLocation":463},{"text":614,"config":615},"Transparenzerklärung zu moderner Sklaverei",{"href":616,"dataGaName":617,"dataGaLocation":463},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":619,"links":620},"Nimm Kontakt auf",[621,624,629,631,636,641,646],{"text":622,"config":623},"Sprich mit einem Experten/einer Expertin",{"href":57,"dataGaName":58,"dataGaLocation":463},{"text":625,"config":626},"Support",{"href":627,"dataGaName":628,"dataGaLocation":463},"https://support.gitlab.com/hc/en-us/articles/11626483177756-GitLab-Support","get help",{"text":369,"config":630},{"href":371,"dataGaName":372,"dataGaLocation":463},{"text":632,"config":633},"Status",{"href":634,"dataGaName":635,"dataGaLocation":463},"https://status.gitlab.com/","status",{"text":637,"config":638},"Nutzungsbedingungen",{"href":639,"dataGaName":640,"dataGaLocation":463},"/terms/","terms of use",{"text":642,"config":643},"Datenschutzerklärung",{"href":644,"dataGaName":645,"dataGaLocation":463},"/de-de/privacy/","privacy statement",{"text":647,"config":648},"Cookie-Einstellungen",{"dataGaName":649,"dataGaLocation":463,"id":650,"isOneTrustButton":31},"cookie preferences","ot-sdk-btn",{"items":652},[653,655,657],{"text":637,"config":654},{"href":639,"dataGaName":640,"dataGaLocation":463},{"text":642,"config":656},{"href":644,"dataGaName":645,"dataGaLocation":463},{"text":647,"config":658},{"dataGaName":649,"dataGaLocation":463,"id":650,"isOneTrustButton":31},[660,673],{"id":661,"title":19,"body":9,"config":662,"content":664,"description":9,"extension":29,"meta":668,"navigation":31,"path":669,"seo":670,"stem":671,"__hash__":672},"blogAuthors/en-us/blog/authors/cherry-han.yml",{"template":663},"BlogAuthor",{"name":19,"config":665},{"headshot":666,"ctfId":667},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750713473/ehktvdbix2o1t0mmcvll.png","6gkuhRkgzCNP1Ee6J14yLu",{},"/en-us/blog/authors/cherry-han",{},"en-us/blog/authors/cherry-han","423YS5YJhamDZ16wrw52ICoxcneLpTgjS66vce3TKcE",{"id":674,"title":20,"body":9,"config":675,"content":676,"description":9,"extension":29,"meta":680,"navigation":31,"path":681,"seo":682,"stem":683,"__hash__":684},"blogAuthors/en-us/blog/authors/gavin-peltz.yml",{"template":663},{"name":20,"config":677},{"headshot":678,"ctfId":679},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662831/Blog/Author%20Headshots/gavin_peltz.png","27UwgXDMqa0oBWV93rXTgN",{},"/en-us/blog/authors/gavin-peltz",{},"en-us/blog/authors/gavin-peltz","Expo-2S0aRtyigiH0p1b68iP-7NhMnFl5iUi637pn-g",[686,699,714],{"content":687,"config":697},{"title":688,"description":689,"authors":690,"heroImage":692,"date":693,"body":694,"category":10,"tags":695},"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.",[691],"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/).",[26,10,696],"features",{"featured":13,"template":14,"slug":698},"gitlab-18-10-brings-ai-native-triage-and-remediation",{"content":700,"config":712},{"title":701,"description":702,"authors":703,"heroImage":705,"date":706,"body":707,"category":10,"tags":708},"SSO und SCIM mit Azure Entra ID – Zentralisiertes Identity-Management","Single Sign-On und SCIM-Benutzerbereitstellung einrichten – SAML-Konfiguration für GitLab mit Azure Entra ID.",[704],"Rob Jackson","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098047/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1097303277_6gTk7M1DNx0tFuovupVFB1_1750098046895.jpg","2026-03-16","Mit wachsender Unternehmensgröße wird es zunehmend schwierig und kritisch, sicherzustellen, dass die richtigen Teammitglieder Zugriff auf die richtigen Gruppen und Projekte haben. GitLab bietet leistungsstarke Methoden zur Zugriffsverwaltung, insbesondere mit [Custom Roles](https://about.gitlab.com/blog/how-to-tailor-gitlab-access-with-custom-roles/). Die manuelle Verwaltung über eine Benutzeroberfläche kann jedoch bei großem Umfang frustrierend sein. Security Assertion Markup Language (SAML) und System for Cross-domain Identity Management (SCIM) bieten eine Lösung.\n\n\n## Was SSO und SCIM bieten\n\n\n**Single Sign-On (SSO) mit SAML** ermöglicht Benutzern, sich einmal bei einem zentralen Identity Provider – wie Azure Entra ID – zu authentifizieren und dann auf mehrere verbundene Anwendungen zuzugreifen, ohne erneute Anmeldung. **SCIM** automatisiert die Benutzerverwaltung: Wenn Benutzer im Identity Provider erstellt, Gruppen zugewiesen oder deaktiviert werden, synchronisiert SCIM diese Änderungen automatisch mit GitLab – einschließlich Berechtigungen basierend auf Gruppenmitgliedschaften.\n\n\n### Vorteile für Unternehmen\n\n\n**Sicherheit:** Zentralisierte Authentifizierung reduziert Passwort-Müdigkeit und Credential-Stuffing-Risiken. Multi-Faktor-Authentifizierung lässt sich auf Identity-Provider-Ebene erzwingen und gilt automatisch für alle verbundenen Anwendungen. Wenn ein Benutzer das Unternehmen verlässt, entfernt die Deaktivierung im Identity Provider sofort den Zugriff auf alle Systeme.\n\n\n**Effizienz:** Automatisierte Benutzerbereitstellung reduziert Onboarding-Zeit von Stunden auf Minuten. Gruppenmitgliedschaften in Azure Entra ID synchronisieren automatisch mit GitLab-Berechtigungen. Identitäten werden einmal im Identity Provider verwaltet und propagieren automatisch – kein manuelles Erstellen, Aktualisieren oder Löschen von Konten in jeder Anwendung erforderlich.\n\n\n## Implementierung\n\n\nDie Konfiguration von GitLab Single Sign-On mit SAML und SCIM erfordert:\n\n- Azure Entra ID Tenant mit Administrator-Zugriff\n- GitLab Premium oder Ultimate mit Top-Level-Gruppe\n- Konfiguration auf beiden Plattformen (Parameter-Austausch, Attribut-Mappings, SCIM-Token)\n\n\n**Vollständige Schritt-für-Schritt-Anleitung:**\n\n→ [How-to: GitLab Single Sign-on with SAML, SCIM and Azure's Entra ID](https://about.gitlab.com/blog/how-to-gitlab-single-sign-on-with-saml-scim-and-azures-entra-id/)\n\n\nDie englische Anleitung bietet:\n\n- 15 detaillierte UI-Screenshots für Azure Entra ID und GitLab\n- Vollständige Attribut-Mapping-Tabellen (SAML Claims, SCIM Provisioning)\n- Parameter-Austausch zwischen Plattformen (Identifier, Reply URL, Certificate, SCIM Token)\n- Fehlerbehebung für häufige Probleme (Email-Attribut-Fehler, NameID-Mismatch)\n\n\n**Kostenlose Testversionen:** [Azure Entra ID](https://azure.microsoft.com/de-de/free/) | [GitLab](https://about.gitlab.com/free-trial/devsecops/)\n\n\n## Weiterführende Informationen\n\n- [The ultimate guide to enabling SAML and SSO on GitLab.com](https://about.gitlab.com/blog/the-ultimate-guide-to-enabling-saml/)\n- [SAML SSO for GitLab.com groups documentation](https://docs.gitlab.com/ee/user/group/saml_sso/)\n",[709,10,25,710,711],"tutorial","DevSecOps","solutions architecture",{"slug":713,"featured":13,"template":14},"how-to-gitlab-single-sign-on-with-saml-scim-and-azures-entra-id",{"content":715,"config":722},{"authors":716,"date":706,"title":718,"description":719,"category":10,"body":720,"heroImage":721},[717],"GitLab Germany Team","Compliance-Standards: Wie du sie identifizierst und einhältst","Was Compliance-Standards genau sind, welche zentralen Standards unvermeidbar sind und wie du Anforderungen direkt in GitLab abbildest.","In vielen Entwicklerteams steigt heute der Druck, schneller zu liefern, während gleichzeitig regulatorische Anforderungen immer weiter zunehmen. Spätestens bei Audits oder Sicherheitsvorfällen wird deutlich, dass ohne klare Regeln für Verantwortlichkeiten, Freigaben und Nachweise Reibungsverluste entstehen können. Compliance-Standards schaffen hier eine gemeinsame Grundlage, um Sicherheit, Datenschutz und Kontrolle konsistent in Entwicklungs- und Betriebsprozessen zu verankern.\n\nIn diesem Beitrag betrachten wir die wichtigsten Standards im IT-Umfeld und zeigen, wie Organisationen sie strukturieren und operationalisieren können. Außerdem zeigen wir dir, wie GitLab als integrierte DevSecOps-Plattform Standards nicht nur abbildet, sondern ihre Umsetzung aktiv unterstützt.\n\n## Was sind Compliance-Standards?\n\nCompliance-Standards sind verbindlich definierte Anforderungen, mit denen Organisationen oft international oder branchenweit sicherstellen, dass ihre Prozesse, Systeme und Datenverarbeitungspraktiken bestimmten Vorgaben entsprechen. Sie entstehen aus rechtlichen Rahmenwerken, regulatorischen Verpflichtungen oder Best-Practice-Katalogen und dienen als gemeinsame Leitlinie für Sicherheit, Datenschutz sowie Qualitäts- und Risikomanagement.\n\nIm IT- und Softwarebereich betreffen diese Standards typischerweise Bereiche wie Zugriffskontrollen, Änderungs- und Release-Prozesse, Protokollierungen, Fehlerbehebungen oder die fortlaufende Überwachung von Systemen.\n\nIn diesem Beitrag verwenden wir „Compliance‑Standards“ als Oberbegriff für Normen, Frameworks und gesetzliche bzw. regulatorische Vorgaben – also etwa ISO‑Standards, Branchenframeworks wie das NIST Cybersecurity Framework sowie Gesetze und Verordnungen wie DSGVO, NIS2 oder HIPAA.\n\n> Wie du dein gesamtes [Compliance-Management automatisieren](https://about.gitlab.com/de-de/blog/automated-compliance-management/) und Ressourcen einsparen kannst, erfährst du in diesem weiterführenden Beitrag mit vielen deutschen Videos!\n\n### Welchen Stellenwert haben Compliance-Standards?\n\nCompliance-Standards sind weit mehr als nur Checklisten. In erster Linie helfen sie, Risiken zu begrenzen und rechtliche bzw. finanzielle Konsequenzen bei Nichteinhaltung zu vermeiden. Zudem erzeugen sie Vertrauen durch eine nachweisbare Einhaltung und werden in vielen Unternehmen auch als Input für Controls, Policies und Prüfprozesse genutzt. Wichtig sind dabei vor allem folgende Ebenen:\n\n* **Gesetze und Verordnungen:** Compliance-Standards wie ISO/IEC 27001 werden oft herangezogen, um die Einhaltung von Gesetzen wie der DSGVO oder Finanzrechten zu strukturieren und nachweisbar zu machen.\n* **Frameworks:** Ausgearbeitete Leitliniensammlungen helfen dabei, Standards, Best Practices und Kontrollziele zu bündeln. Ein Framework kann mehrere Standards integrieren und in konkrete Maßnahmen überführen.\n* **Controls:** Technische oder organisatorische Maßnahmen machen schließlich einzelne Anforderungen eines Standards operationalisierbar und überprüfbar. Controls sind dafür die Umsetzungselemente im täglichen Betrieb.\n\nEine klare Definition von Compliance-Standards ist wichtig, weil Unternehmen sonst Gefahr laufen, Anforderungen fragmentiert, reaktiv oder getrennt von ihren operativen Prozessen umzusetzen. Solche Standards funktionieren nur, wenn sie nicht als isolierte Dokumente in Schubladen liegen, sondern in die täglichen Arbeitsabläufe und Verantwortlichkeiten eingebettet sind.\n\n## Warum Standards im Compliance-Management zentral sind\n\n[Compliance-Management](https://about.gitlab.com/de-de/blog/compliance-management/) soll sicherstellen, dass Anforderungen nicht nur definiert, sondern im Alltag auch eingehalten werden. Compliance-Standards sind dafür die zentrale Grundlage. Sie übersetzen rechtliche und regulatorische Vorgaben in klare Erwartungen, an denen sich Organisationen orientieren können. Ohne diesen gemeinsamen Referenzrahmen bleibt Compliance oft reaktiv und wird erst relevant, wenn Prüfungen oder Vorfälle auftreten.\n\nDie wichtigsten Aufgaben von Compliance-Standards sind daher:\n\n* **Stabilität:** In der Softwareentwicklung ändern sich Code, Infrastruktur und Prozesse laufend. Compliance-Standards schaffen hier Verlässlichkeit, weil sie unabhängig von einzelnen Projekten festlegen, welche Mindestanforderungen gelten.\n* **Risikobewertung:** Die Nichteinhaltung von Compliance-Standards kann zu Imageschäden, aber auch zu rechtlichen Sanktionen wie Geldstrafen führen. Eine Standardisierung erleichtert es, [Compliance-Risiken](https://about.gitlab.com/de-de/blog/compliance-risks/) einzuordnen und darauf aufbauend Verantwortlichkeiten festzulegen und konsistente Entscheidungen zu treffen.\n* **Skalierung:** Mit zunehmender Anzahl von Teams und Services lassen sich Compliance-Anforderungen häufig schwerer über Absprachen oder manuelle Kontrollen steuern. Klar definierte Standards machen Anforderungen wiederholbar, indem neue Projekte sich einfach daran orientieren können. So bleibt Compliance auch im Wachstum handhabbar.\n* **Nachvollziehbarkeit:** Compliance-Richtlinien definieren, welche Prozesse dokumentiert, welche Änderungen protokolliert und welche Freigaben nachvollziehbar sein müssen. Das ist nicht nur für Audits relevant, sondern sorgt intern auch für mehr Transparenz und ermöglicht kontinuierliche Verbesserungen.\n\nIhren größten Nutzen entfalten Compliance-Standards, wenn sie direkt in operative Abläufe eingebunden sind. Durch die Integration in Entwicklungs-, Sicherheits- und Deployment-Prozesse sinkt der Abstimmungsaufwand maßgeblich und die Einhaltung wird verlässlicher. Eine integrierte[ DevSecOps-Plattform wie GitLab ermöglicht benutzerdefinierte Compliance-Frameworks](https://about.gitlab.com/de-de/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops/) und bindet die Standards somit als festen Bestandteil in tägliche Workflows ein.\n\n## Die wichtigsten IT-Compliance-Standards im Überblick\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773847401/aubulrjf0az8lmqjjt0g.png \"Was deutsche Compliance-Fachleute uns gesagt haben.\")\n\nWie eine [Studie von GitLab und The Harris Poll zur DevSecOps-Landschaft 2026](https://learn.gitlab.com/de-developer-survey/report-de-de-de-devsecops-report-practitioner) zeigt, gehören Compliance-Standards und deren Einhaltung für Unternehmen zu den größten Herausforderungen in der Softwareentwicklung. Die wichtigsten Standards im europäischen Raum sind dabei folgende:\n\n1. ISO/IEC 27001\n2. DSGVO\n3. NIST CSF\n4. SOC 2\n5. Branchenspezifische und sektorale Standards\n\n### 1. ISO/IEC 27001\n\nDie ISO/IEC 27001 ist eine international weitverbreitete Norm in der Informationstechnik. Als Norm ist sie zwar nicht gesetzlich verpflichtend, gilt allerdings als zentrale Referenz für IT-Compliance – insbesondere dann, wenn Organisationen Sicherheit, Datenschutz und Risikomanagement systematisch und auditierbar aufstellen müssen. Anders als gesetzliche Vorgaben beschreibt sie nicht nur Ziele, sondern auch klare Anforderungen an Prozesse, Verantwortlichkeiten und kontinuierliche Verbesserung.\n\nIm Mittelpunkt dieses Standards steht der Aufbau und Betrieb eines Informationssicherheits-Managementsystems (ISMS). Dieses umfasst unter anderem die systematische Bewertung von Risiken, die Definition von Sicherheitszielen sowie die Auswahl und Umsetzung geeigneter Maßnahmen. Der zugehörige Annex A liefert einen strukturierten Katalog von Controls, etwa für Zugriffskontrollen, Kryptografie, Change Management, Logging oder Lieferantenbeziehungen. Damit bietet ISO 27001 eine Brücke zwischen abstrakten Sicherheitszielen und konkreten organisatorischen und technischen Maßnahmen.\n\nFür Software- und Plattform-Teams ist ISO 27001 besonders relevant, weil viele Anforderungen direkt in Entwicklungs- und Betriebsprozesse hineinwirken. Sichere Code-Änderungen, nachvollziehbare Freigaben, Trennung von Zuständigkeiten oder die lückenlose Protokollierung sicherheitsrelevanter Ereignisse lassen sich nicht losgelöst von Toolchains und Workflows umsetzen. Die Norm verlangt zudem, dass diese Maßnahmen nicht nur definiert, sondern auch regelmäßig überprüft und angepasst werden. [ISO-27001-Compliance](https://about.gitlab.com/de-de/blog/how-gitlab-can-support-your-iso-compliance-journey/) ermöglicht es damit, unterschiedliche regulatorische Anforderungen wie die DSGVO oder branchenspezifische Vorgaben in ein konsistentes Managementsystem zu integrieren.\n\n> **8x schnellere Software-Updates & 40x schnellere Projekteinrichtung: Mit GitLabs Automatisierung revolutioniert Thales das Inflight-Entertainment**\n>\n> Erfahre, wie Thales Sicherheits- und Compliance-Standards in der Luftfahrt etabliert hat und mit GitLab Ultimate für deutlich schnellere und günstigere Builds sorgt.\n>\n> **[Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/thales/)**\n\n### 2. DSGVO\n\nDie Datenschutz-Grundverordnung ist eine verbindliche gesetzliche Grundlage für den Umgang mit personenbezogenen Daten in der Europäischen Union. Sie betrifft nahezu jede Organisation, die Daten von EU-Bürgern verarbeitet – unabhängig davon, ob es sich um ein Softwareunternehmen, einen internen IT-Dienstleister oder einen SaaS-Anbieter handelt. Damit ist die DSGVO einer der wichtigsten Treiber für Compliance-Management im europäischen IT-Umfeld.\n\nIm Gegensatz zu Normen wie ISO 27001 beschreibt die DSGVO vorwiegend Schutzziele und Prinzipien. Dazu gehören unter anderem Rechtmäßigkeit der Verarbeitung, Zweckbindung, Datenminimierung, Integrität, Vertraulichkeit und Rechenschaftspflicht. Wie diese Anforderungen technisch und organisatorisch umzusetzen sind, bleibt bewusst offen. In der Praxis bildet die DSGVO deshalb häufig den Rahmen für Richtlinien und Verfahren. Sie wird somit nicht isoliert umgesetzt, sondern mit auditierbaren Standards wie ISO/IEC 27001 kombiniert, um daraus strukturierte Kontrollziele und Managementprozesse ableiten zu können.\n\nFür die Softwareentwicklung hat die DSGVO besonders relevante Implikationen. Themen wie Zugriffskontrolle, Rollen- und Berechtigungskonzepte, Protokollierung von Änderungen, vor allem aber sichere Deployments oder der kontrollierte Umgang mit Daten sind die zentrale Grundlage, um Datenschutzanforderungen praktisch umsetzen zu können. Hinzu kommt die Pflicht, Nachweise über getroffene Maßnahmen zu erbringen, etwa im Rahmen von behördlichen Prüfungen oder Auskunftsersuchen.\n\n### 3. NIST CSF\n\nDas NIST Cybersecurity Framework ist kein Gesetz oder klassischer Compliance-Standard im engeren Sinn. Es ist also weder regulatorisch verpflichtend, noch gehört es zu den Audit-Standards wie ISO 27001 oder SOC 2. Trotzdem dient es für Unternehmen im IT-Bereich als Orientierung für Sicherheitsmaßnahmen oder als Ergänzung zu ISO-basierten [Compliance-Management-Systemen](https://about.gitlab.com/de-de/blog/compliance-management-system/).\n\nDer Kern des Frameworks besteht aus sechs Funktionen: \n\n* Verwalten *(Govern)*\n* Identifizieren *(Identify)*\n* Schützen *(Protect)*\n* Erkennen *(Detect)*\n* Reagieren *(Respond)*\n* Wiederherstellen *(Recover)*\n\nDiese unterteilen sich in 22 Kategorien, welche wiederum selbst in 106 Subkategorien unterteilt sind. So deckt das NIST-Cybersecurity-Framework ein breites Spektrum an Compliance-Bezügen ab und bietet damit vielfältige Möglichkeiten als Strukturierungs- und Reifegradmodell.\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773847490/gliu4v6txat5vwlarf2g.png \"Das NIST Cybersecurity Framework\")\n\n### 4. SOC 2\n\nSOC 2 ist ein Compliance-Standard, der speziell für serviceorientierte Unternehmen entwickelt wurde, insbesondere für SaaS-, Cloud- und Plattformanbieter. Er wurde in den USA entwickelt und ist rechtlich nicht verpflichtend, spielt aber speziell bei Kund(inn)en mit internationalem Geschäft oder US-Bezug eine wichtige Rolle, wenn es um Vertrauen, Transparenz und Nachweisbarkeit von internen Kontrollen geht.\n\nDer SOC-2-Standard besteht aus fünf sog. Trust Services Criteria: \n\n* Sicherheit *(Security)*\n* Verfügbarkeit *(Availability)*\n* Verarbeitungsintegrität *(Processing Integrity)*\n* Vertraulichkeit *(Confidentiality)*\n* Datenschutz *(Privacy)*. \n\nAllerdings ist nur der Aspekt Sicherheit verpflichtend – die anderen vier Kriterien können je nach Geschäftsmodell ergänzt werden. Um operative Prozesse und deren Anwendung nachvollziehbar darzustellen, unterscheidet SOC 2 zudem zwischen zwei Typen: \n\n* Type I bewertet die Gestaltung von Kontrollen.\n* Type II prüft deren Wirksamkeit über einen festgelegten Zeitraum.\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773847544/xwoqmhpf058xl8vxddoe.png \"SOC 2 Compliance\")\n\n### 5. Branchenspezifische und sektorale Standards\n\nNeben branchenübergreifenden Standards gibt es im Compliance-Management auch Richtlinien, die sich gezielt an bestimmte Branchen richten. Sie spielen primär dann eine Rolle, wenn Software direkt in regulierten Kontexten eingesetzt wird:\n\n* **PCI DSS** betrifft Organisationen, die Kreditkartendaten verarbeiten, speichern oder übertragen. Der Standard definiert konkrete technische und organisatorische Sicherheitsanforderungen zu Belangen rund um Netzwerksegmentierung, Umgang mit Zugangsdaten oder Überwachung von Systemen. PCI DSS ist stark technisch geprägt und auch wenn es kein Gesetz darstellt, ist die Einhaltung meist vertraglich geregelt und beim Umgang mit sensiblen Kreditkartendaten faktisch verpflichtend.\n* **NIS2** ist eine europäische Richtlinie, die von den Mitgliedstaaten in nationales Recht umgesetzt wird und sich hinsichtlich Management‑ und Governance‑Verantwortung ausdrücklich an die Unternehmensführung richtet. Betroffen sind verschiedene Sektoren wie Energie, Verkehr und Gesundheitswesen sowie bestimmte Unternehmen ab einer definierten Größe. Auch wenn sie keinen klassischen Compliance-Standard bilden, ziehen [NIS2-Anforderungen](https://about.gitlab.com/de-de/blog/how-gitlab-helps-meet-nis2-requirements/) in der operativen Umsetzung Implikationen für IT- und Softwareprozesse z. B. in den Bereichen Cybersecurity, Risikomanagement und Meldepflichten nach sich.\n* **HIPAA** (Health Insurance Portability and Accountability Act) ist ein US-Gesetz und richtet sich insbesondere in Form der HIPAA Security und Privacy Rule an Organisationen, die mit Gesundheitsdaten in den USA arbeiten. Sie legt strenge Anforderungen an den Schutz sensibler Informationen fest, vor allem in Bezug auf Zugriffsbeschränkungen, Protokollierung und den sicheren Betrieb von IT‑Systemen. Für europäische Unternehmen ist HIPAA dann relevant, wenn Produkte oder Services für den US‑Gesundheitsmarkt entwickelt oder dort betrieben werden.\n\n## Wie GitLab Compliance-Standards in DevSecOps-Prozesse integriert\n\nCompliance-Standards entfalten ihren Nutzen erst dann vollständig, wenn sie nicht neben der täglichen Arbeit existieren, sondern Teil der Entwicklungs- und Betriebsprozesse sind. Genau hier setzt eine integrierte DevSecOps-Plattform wie GitLab an. Anstatt Compliance als separaten Prüfprozess zu behandeln, kannst du Anforderungen dort abbilden, wo Code entsteht, geprüft und ausgeliefert wird.\n\nDas integrierte [Compliance Center von GitLab](https://about.gitlab.com/de-de/solutions/software-compliance/) bietet eine zentrale Steuerungsebene für Compliance-relevante Informationen. Verantwortliche erhalten einen konsolidierten Überblick darüber, welche Projekte welchen Standards unterliegen, welche Richtlinien aktiv sind und wo Abweichungen auftreten:\n\n* Ordne Standards Projekten und Teams zu und übersetze die Anforderungen aus Standards wie ISO 27001, SOC 2 oder NIS2 in definierte Vorgaben für Projekte. Dadurch wird klar, welche Repositories im Geltungsbereich bestimmter Compliance-Anforderungen liegen und welche zusätzlichen Kontrollen dort greifen müssen.\n* Freigaben, Sicherheitsprüfungen oder verpflichtende Pipeline-Schritte werden nicht manuell eingefordert, sondern einfach technisch hinterlegt. So entsteht eine konsistente Umsetzung von Compliance-Anforderungen, die unabhängig von einzelnen Personen oder Teams funktioniert und direkt mit Entwicklungs- und CI/CD-Prozessen verknüpft ist.\n* Änderungen an Code, Konfigurationen oder Zugriffsrechten werden automatisch protokolliert und sind revisionssicher nachvollziehbar. Auditnachweise entstehen als Nebenprodukt der täglichen Arbeit, sodass du sie nicht nachträglich zusammensuchen musst.\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773847602/jq0trqx4hqkjmtrheex8.png \"Compliance Center in GitLab\")\n\nCompliance-Standards sollten nie als statische Vorgaben behandelt, sondern als lebendiger Bestandteil von DevSecOps-Prozessen verstanden werden. Mit dem notwendigen Verständnis und dem richtigen Tool werden sie hingegen strukturierbar, umsetzbar und überprüfbar – genau dort, wo moderne Software entsteht.\n\n> **Verankere regulatorische Anforderungen direkt im Entwicklungsprozess**\n>\n> Automatisiere dein Compliance-Management, stärke dabei deine Entwicklerteams und skaliere Compliance nachhaltig im Unternehmen!\n>\n> **[Jetzt starten!](https://about.gitlab.com/de-de/free-trial/)**\n\n## Häufig gestellte Fragen zu Compliance-Standards\n\n### Was kann bei Nichteinhaltung von Compliance-Standards passieren?\n\nBei Nichteinhaltung von Compliance-Standards drohen rechtliche, finanzielle und operative Konsequenzen. Dazu zählen hohe Geldstrafen und rechtliche Schritte durch Aufsichtsbehörden, Schadensersatzforderungen, Vertragskündigungen sowie der Verlust von Zertifizierungen. Zusätzlich können Reputationsschäden entstehen, die das Vertrauen von Kundinnen und Kunden bzw. Geschäftspartnerinnen und Geschäftspartnern einträchtigen. Intern führen Verstöße häufig zu Betriebsunterbrechungen, erhöhtem Kontrollaufwand und persönlichen Haftungsrisiken für Verantwortliche.\n\n### Welche Compliance-Standards sind noch wichtig?\n\nWelche Compliance-Standards für ein Unternehmen gelten, hängt von Branche, Markt, Unternehmensgröße und regulatorischem Umfeld ab. So sind im Finanzwesen noch die Standards ISO 22301 (Business Continuity), BAIT und MaRisk wichtig, während für Industrie und Automobil TISAX und IEC 62443 eine Rolle spielen. Im Gesundheitswesen und Life Sciences zählen hingegen ISO 13485 sowie GxP-Richtlinien, und Energie und kritische Infrastruktur müssen ISO 27019 und KRITIS-Anforderungen berücksichtigen.\n\n### Was ist der Unterschied zwischen ISO 27000 und ISO 27001?\n\nISO 27000 ist eine Normenfamilie, die Begriffe, Grundlagen und einen Überblick zum Informationssicherheitsmanagement liefert. ISO 27001 ist Teil dieser Familie und definiert konkrete Anforderungen an ein Informationssicherheits-Managementsystem (ISMS). Während ISO 27000 erklärend und einordnend wirkt, ist ISO 27001 die prüf- und zertifizierbare Norm, nach der Organisationen ihre Informationssicherheit offiziell nachweisen können.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1773845541/kilohgeyn6zih92gpbx9.png",{"featured":13,"template":14,"slug":723},"compliance-standards",{"promotions":725},[726,740,752,763],{"id":727,"categories":728,"header":730,"text":731,"button":732,"image":737},"ai-modernization",[729],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":733,"config":734},"Get your AI maturity score",{"href":735,"dataGaName":736,"dataGaLocation":247},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":738},{"src":739},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":741,"categories":742,"header":744,"text":731,"button":745,"image":749},"devops-modernization",[26,743],"devsecops","Are you just managing tools or shipping innovation?",{"text":746,"config":747},"Get your DevOps maturity score",{"href":748,"dataGaName":736,"dataGaLocation":247},"/assessments/devops-modernization-assessment/",{"config":750},{"src":751},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":753,"categories":754,"header":755,"text":731,"button":756,"image":760},"security-modernization",[10],"Are you trading speed for security?",{"text":757,"config":758},"Get your security maturity score",{"href":759,"dataGaName":736,"dataGaLocation":247},"/assessments/security-modernization-assessment/",{"config":761},{"src":762},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":764,"paths":765,"header":768,"text":769,"button":770,"image":775},"github-azure-migration",[766,767],"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":771,"config":772},"See how GitLab compares to GitHub",{"href":773,"dataGaName":774,"dataGaLocation":247},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":776},{"src":751},{"header":778,"blurb":779,"button":780,"secondaryButton":785},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":781,"config":782},"Kostenlosen Test starten",{"href":783,"dataGaName":53,"dataGaLocation":784},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/de-de/","feature",{"text":55,"config":786},{"href":57,"dataGaName":58,"dataGaLocation":784},1776449917944]