[{"data":1,"prerenderedAt":758},["ShallowReactive",2],{"/de-de/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab":3,"navigation-de-de":39,"banner-de-de":443,"footer-de-de":453,"blog-post-authors-de-de-Fernando Diaz":658,"blog-related-posts-de-de-guide-to-fulfilling-soc-2-security-requirements-with-gitlab":672,"assessment-promotions-de-de":709,"next-steps-de-de":748},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":27,"isFeatured":12,"meta":28,"navigation":12,"path":29,"publishedDate":20,"seo":30,"stem":35,"tagSlugs":36,"__hash__":38},"blogPosts/de-de/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab.yml","Guide To Fulfilling Soc 2 Security Requirements With Gitlab",[7],"fernando-diaz",null,"security",{"slug":11,"featured":12,"template":13},"guide-to-fulfilling-soc-2-security-requirements-with-gitlab",true,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"body":21,"category":9,"tags":22},"GitLab-Leitfaden: SOC-2-Sicherheitsanforderungen erfüllen","Verstehe die Anwendungssicherheitsfunktionen der DevSecOps-Plattform von GitLab, die den Anforderungen von System and Organization Controls 2 entsprechen.",[18],"Fernando Diaz","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099576/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1172300481_IGPi3TS4VzFgcqhvEdBlR_1750099575518.jpg","2025-01-22","Für Unternehmen, die mit vertraulichen Kundendaten arbeiten, ist es nicht nur ein bewährtes Vorgehen, die SOC 2 (System and Organization Controls 2) einzuhalten, sondern ist oft sogar eine Notwendigkeit. SOC 2 ist ein strenger Prüfungsstandard, der vom American Institute of Certified Public Accountants entwickelt wurde, mit dem Serviceunternehmen hinsichtlich ihrer Sicherheit, Verfügbarkeit, Prozessintegrität, Vertraulichkeit und ihres Datenschutzes bewertet werden.\n\n  SOC 2 ist zwar rechtlich nicht bindend, wird aber zunehmend wichtig, unter anderem deswegen, weil Verstöße gegen den Standard immer wieder in den Nachrichten zu finden sind. Durch die Einhaltung der SOC-2-Vorgaben können Kund(inn)en Vertrauen zu Serviceunternehmen aufbauen, da sie sich sicher sein können, dass ihre Daten entsprechend sicher gespeichert werden und die Sicherheitsmaßnahmen von einer externen Stelle geprüft wurden.\n\nIn diesem Leitfaden sehen wir uns die Voraussetzungen für eine SOC-2-Compliance an und erläutern, wie GitLab deinem Unternehmen dabei hilft, die höchsten Standards für Anwendungssicherheit einzuhalten.\n\n## Welche Anforderungen werden von SOC 2 festgelegt?\n\nDer Compliance-Prozess umfasst ein Audit durch unabhängige Auditor(inn)en, die die Konzeption und betriebliche Effektivität der Sicherheitsmaßnahmen eines Unternehmens bewerten. Dieser Prozess kann sehr kostspielig sein, und viele Unternehmen sind nicht ausreichend auf ein Audit vorbereitet. Da der SOC-2-Auditprozess normalerweise rund ein Jahr dauert, ist es wichtig, bereits vor dem Audit effiziente Prozesse einzuführen.\n\nUm SOC-2-Compliance zu erreichen, muss ein Unternehmen die Anforderungen der Trust Services Criteria erfüllen:\n\n| Kriterium | Anforderungen |\n| :---- | :---- |\n| Sicherheit | - Implementierung von Kontrollen gegen unautorisierten Zugriff \u003Cbr> - Einführung von Vorgehensweisen zum Erkennen und Mindern von Risiken\u003Cbr> - Einrichtung von Systemen, um Sicherheitsvorfälle zu erkennen und zu beheben |\n| Verfügbarkeit | - Sicherstellung, dass Systeme wie vereinbart für den Betrieb zugänglich sind\u003Cbr> - Überwachung der aktuellen Nutzung und Kapazität \u003Cbr> - Identifizierung und Behebung von Umgebungsbedrohungen, die sich auf die Systemverfügbarkeit auswirken können |\n| Prozessintegrität | - Erfassung genauer Angaben zu Systemeingaben und -ausgaben \u003Cbr> - Implementierung von Verfahren, um Systemfehler schnell zu identifizieren und zu korrigieren \u003Cbr> - Festlegung von Prozessaktivitäten, um sicherzustellen, dass die Produkte und Dienstleistungen den Spezifikationen entsprechen |\n| Vertraulichkeit | - Identifizierung und Schutz vertraulicher Informationen \u003Cbr> - Einführung von Richtlinien für Datenaufbewahrungszeiträume \u003Cbr> - Implementierung von Sicherheitsmaßnahmen zur Zerstörung vertraulicher Daten nach Ablauf der Aufbewahrungsfrist |\n| Datenschutz | - Einholen von Zustimmung vor der Erfassung vertraulicher personenbezogener Daten \u003Cbr> - Offenlegung der Datenschutzrichtlinien in klarer, einfacher Sprache \u003Cbr> - Erfassung der Daten nur für rechtmäßige Zwecke und aus vertrauenswürdigen Quellen |\n\n\nBeachte, dass diese Anforderungen nicht einmalig zu erfüllen sind, sondern eher ein kontinuierlicher Prozess sind. Die Auditor(inn)en kontrollieren die Effektivität im Laufe der Zeit.\n\n## So erreichst du die Sicherheitsanforderungen und behältst sie bei\n\nGitLab bietet mehrere standardmäßige Funktionen, mit denen du sicherstellen kannst, dass deine SOC-2-Sicherheitsanforderungen erfüllt werden:\n\n| Sicherheitsanforderung | Relevante Funktion |\n| :---- | :--- |\n| Implementierung von Kontrollen gegen unautorisierten Zugriff | - Vertrauliche Tickets und Merge Requests \u003Cbr> - Benutzerdefinierte Rollen und granulare Berechtigungen \u003Cbr> - Sicherheitsrichtlinien \u003Cbr> - Verifizierte Commits \u003Cbr> - Signierte Container-Images \u003Cbr> - Code-Eigentümer(innen) \u003Cbr> - Geschützte Branches |\n| Einrichten von Systemen, um Sicherheitsvorfälle zu erkennen und zu beheben | - Sicherheitslücken-Scans \u003Cbr> - Merge-Request-Sicherheitswidget \u003Cbr> - Compliance-Center für Sicherheitslücken-Einblicke \u003Cbr> - Audit-Events \u003Cbr> - Abhängigkeitsliste für Sicherheitslückenbericht \u003Cbr> - KI: GitLab Duo Vulnerability Explanation \u003Cbr> - KI: GitLab Duo Vulnerability Resolution |\n| Einführung von Vorgehensweisen zum Erkennen und Mindern von Risiken | Alle oben genannten Tools können von Sicherheitsteams verwendet werden, um Prozesse dafür zu entwickeln, wie vorzugehen ist, wenn Sicherheitslücken erkannt werden und wie sie zu beheben sind. |\n\n\u003Cbr>\n\nSehen wir uns diese Abschnitte und die dazugehörigen Sicherheitsfunktionen für diese Anforderungen nun genauer an. Beachte, dass ein [GitLab-Ultimate-Abonnement](https://about.gitlab.com/de-de/free-trial/) und die richtigen Rollen und Berechtigungen nötig sind, um viele der aufgelisteten Funktionen nutzen zu können. Weitere Informationen findest du in der entsprechenden Dokumentation.\n\n## Implementiere Kontrollen zum Schutz vor unbefugtem Zugriff\n\nEs ist wichtig, robuste Zugriffskontrollen zu implementieren, um die Assets eines Unternehmens zu schützen, die rechtliche Compliance sicherzustellen, die betriebliche Kontinuität zu gewährleisten und das Vertrauen zu fördern. Mit GitLab kannst du Kontrollen implementieren, um das [Prinzip der geringsten Privilegien (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/) zu befolgen und vor unbefugtem Zugriff zu schützen. Wir werden uns kurz folgende Themen ansehen:\n\n* [Sicherheitsrichtlinien](#security-policies)\n\n* [Benutzerdefinierte Rollen und granulare Berechtigungen](#custom-roles-and-granular-permissions)\n\n* [Schutz von Branches und Code-Eigentümer(innen)](#branch-protections-and-codeowners)\n\n* [Verifizierte Commits](#verified-commits)\n\n### Sicherheitsrichtlinien\n\nDie Sicherheitsrichtlinien von GitLab werden auch als Leitlinien bezeichnet und ermöglichen es Sicherheits- und Compliance-Teams, im gesamten Unternehmen konsistente Kontrollen einzuführen. Dies trägt dazu bei, Sicherheitsvorfälle zu vermeiden, die Compliance-Standards einzuhalten und Risiken zu reduzieren, indem bewährte Vorgehensweisen hinsichtlich der Sicherheit automatisch und im großen Maßstab erzwungen werden.\n\n![Merge-Request-Approvalrichtlinien in Aktion](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/merge_request_approval_policy_aHR0cHM6_1750099596925.png)\n\n\u003Ccenter>\u003Ci>Merge-Request-Approvalrichtlinien in Aktion\u003C/i>\u003C/center>\u003Cbr>\n\nDie folgenden Arten von Richtlinien sind verfügbar:\n\n* Scan-Ausführungsrichtlinie: Erzwinge Sicherheitsscans als Teil einer Pipeline oder nach einem festgelegten Zeitplan\n\n* Merge-Request-Approvalrichtlinie: Erzwinge Einstellungen und Approvalregeln auf Projektebene basierend auf den Scanergebnissen\n\n* Pipeline-Ausführungsrichtlinie: Erzwinge CI/CD-Jobs als Teil von Projekt-Pipelines\n\n* Sicherheitslücken-Managementrichtlinie: Automatisiere Workflows für das Sicherheitslücken-Management\n\nHier ist ein Beispiel, wie die Compliance mit einer Pipeline-Ausführungsrichtlinie sichergestellt werden kann:\n\n1. Erstelle ein Projekt, das mehrere Compliance-Jobs enthält. Ein Beispiel für einen Job kann die Überprüfung der Berechtigungen von bereitgestellten Dateien sein. Diese Jobs sollten so allgemein gehalten sein, dass sie auf mehrere Anwendungen angewendet werden können.\n\n2. Beschränke die Berechtigungen des Projekts auf Sicherheits-/Compliance-Beauftragte. Erlaube Entwickler(inne)n nicht, Jobs zu entfernen. Dies ermöglicht eine Aufgabentrennung.\n\n3. Füge die Compliance-Jobs gesammelt in die Projekte ein, in denen sie benötigt werden. Erzwinge, dass sie immer ausgeführt werden, aber erlaube Approvals durch die Teamleitung, um die Entwicklung nicht zu blockieren. Dadurch wird sichergestellt, dass Compliance-Jobs immer ausgeführt werden und nicht von Entwickler(inne)n entfernt werden können. So bleibt deine Umgebung konform.\n\n> ##### Erfahre in unserer [Dokumentation zu Sicherheitsrichtlinien (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/policies/), wie du Sicherheitsrichtlinien erstellen kannst.\n\n### Benutzerdefinierte Rollen und granulare Berechtigungen\n\nMit benutzerdefinierten Berechtigungen in GitLab können Unternehmen verfeinerte Zugriffskontrollen entwickeln, die über die standardmäßigen, rollenbasierten Berechtigungen hinausgehen. Das hat unter anderem folgende Vorteile:\n\n* Genauere Zugriffskontrolle\n\n* Bessere Sicherheits-Compliance\n\n* Reduziertes Risiko für versehentlichen Zugriff\n\n* Optimierte Benutzerverwaltung\n\n* Support für komplexe Unternehmensstrukturen\n\n![Benutzerdefinierte Rollen in GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/custom_roles_aHR0cHM6_1750099596926.png)\n\n\u003Ccenter>\u003Ci>Rollen- und Berechtigungseinstellungen, einschließlich benutzerdefinierter Rollen\u003C/i>\u003C/center>\n\n> ##### Erfahre in unserer [Dokumentation zu benutzerdefinierten Rollen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/custom_roles.html), wie du benutzerdefinierte Rollen mit granularen Berechtigungen erstellst.\n\n### Schutz von Branches und Code-Eigentümer(innen)\n\nGitLab hilft dir mit zwei wichtigen Funktionen, noch besser zu kontrollieren, wer deinen Code ändern kann:\n\n* Mit Branch Protection kannst du Regeln festlegen, wer bestimmte Branches aktualisieren darf, z. B. dass Approvals vor dem Zusammenführen von Änderungen nötig sind.\n\n* Mit Code Ownership werden automatisch die richtigen Personen gefunden, die Codeänderungen überprüfen dürfen, indem Dateien mit ihren zugewiesenen Eigentümer(inne)n abgeglichen werden.\n\nZusammen tragen diese Funktionen dazu bei, dass dein Code sicher und hochwertig ist, indem garantiert wird, dass die richtigen Personen Änderungen überprüfen und genehmigen.\n\n![Geschützte Branches](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/protected_branches_aHR0cHM6_1750099596928.png)\n\n\u003Ccenter>\u003Ci>Einstellungen für geschützte Branches\u003C/i>\u003C/center>\n\n> ##### Erfahre in der Dokumentation (nur in englischer Sprache verfügbar) zu [geschützten Branches](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html) und [Code-Eigentümer(inne)n](https://docs.gitlab.com/ee/user/project/codeowners/), wie du geschützte Branches sowie mit Code-Eigentümer(inne)n erstellst.\n\n### Verifizierte Commits\n\nWenn du deine Commits digital signierst, beweist du, dass sie wirklich von dir stammen und nicht von jemandem, der sich als dich ausgibt. Stell dir eine digitale Signatur wie einen einzigartigen Stempel vor, den nur du erstellen kannst. Wenn du deinen öffentlichen GPG-Schlüssel in GitLab hochlädst, kann dieser Stempel überprüft werden. Wenn der Stempel übereinstimmt, markiert GitLab deinen Commit als `Verified`. Du kannst dann Regeln einrichten, um nicht signierte Commits abzulehnen oder alle Commits von Benutzer(innen) zu blockieren, die ihre Identität nicht verifiziert haben.\n\n![Commit mit verifizierter Signatur](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/signed_commit_aHR0cHM6_1750099596929.png)\n\n\u003Ccenter>\u003Ci>Commit mit verifizierter Signatur\u003C/i>\u003C/center>\u003Cbr>\n\nCommits können mit folgenden Signaturen versehen werden:\n\n* SSH-Schlüssel\n\n* GPG-Schlüssel\n\n* Persönliches x.509-Zertifikat\n\n> ##### Weitere Informationen zu verifizierten Commits findest du in unserer [Dokumentation zu signierten Commits (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/repository/signed_commits/).\n\n## Einrichtung von Systemen zur Erkennung und Behebung von Sicherheitsvorfällen\n\nUm eine robuste Sicherheitslage beizubehalten, ist es unerlässlich, Systeme einzurichten, die Sicherheitsvorfälle erkennen und beheben. So stellst du die Einhaltung von Vorschriften sicher, minimierst potenzielle Schäden und ermöglichst es deinem Unternehmen, effektiv auf die kontinuierliche Weiterentwicklung der Bedrohungslandschaft zu reagieren.\n\nGitLab bietet Sicherheitsscans und Sicherheitslückenverwaltung für den gesamten Anwendungslebenszyklus. Wir werden uns kurz folgende Aspekte ansehen:\n\n* [Sicherheitsscans und Sicherheitslückenverwaltung](#security-scanning-and-vulnerability-management)\n\n* [Software-Stückliste](#software-bill-of-materials)\n\n* [System-Audits und Reviews der Sicherheitslage](#system-auditing-and-security-posture-review)\n\n* [Übersicht über Compliance und Sicherheitslage](#compliance-and-security-posture-oversight)\n\n### Sicherheitsscans und Verwaltung von Sicherheitslücken\n\nGitLab bietet zahlreiche verschiedene Sicherheitsscanner für den gesamten Lebenszyklus deiner Anwendung:\n\n* Statische Anwendungssicherheitstests (SAST)\n\n* Dynamische Anwendungssicherheitstests (DAST)\n\n* Container-Scans\n\n* Abhängigkeitssuche\n\n* IaC-Scans (Infrastructure as Code)\n\n* Abdeckungsgesteuertes Fuzzing\n\n* Web-API-Fuzzing\n\n  Diese Scanner können über Vorlagen zu deiner Pipeline hinzugefügt werden. Um beispielsweise SAST- und Abhängigkeitssuche-Jobs in der Testphase auszuführen, kannst du einfach den folgenden Code in deine .gitlab-ci.yml-Datei einfügen:\n\n```yaml\nstages:   - test\n\ninclude:   \n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml   \n  - template: Jobs/SAST.gitlab-ci.yml   \n```\n\nDiese Jobs können über Umgegungsvariablen und mit der GitLab-Job-Syntax vollständig angepasst werden. Sobald eine Pipeline gestartet wird, werden die Sicherheitsscanner ausgeführt und erkennen Sicherheitslücken im Diff zwischen dem aktuellen Branch und dem Zielbranch. Die Sicherheitslücke kann in einem Merge Request (MR) angezeigt werden, der eine detaillierte Übersicht bietet, bevor der Code mit dem Zielbranch zusammengeführt wird. Der MR zeigt die folgenden Informationen zur Sicherheitslücke an:\n\n* Beschreibung\n\n* Status\n\n* Schweregrad\n\n* Evidenz\n\n* Identifikatoren\n\n* URL (falls zutreffend)\n\n* Anfrage/Antwort (falls zutreffend)\n\n* Reproduktions-Asset (falls zutreffend)\n\n* Schulung (falls zutreffend)\n\n* Code-Flow (bei erweiterten SAST)\n\n![MR-Ansicht der eingeführten Sicherheitslücke](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750099596931.png)\n\n\u003Ccenter>\u003Ci>MR-Ansicht der eingeführten Sicherheitslücke\u003C/i>\u003C/center>\u003Cbr>\n\nEntwickler(innen) können diese Daten verwenden, um Sicherheitslücken zu beheben, ohne die Workflows des Sicherheitsteams zu verlangsamen. Sie können Sicherheitslücken mit einer Begründung auch verwerfen, um den Überprüfungsprozess zu beschleunigen, oder ein vertrauliches Ticket erstellen, um die Sicherheitslücke zu verfolgen.\n\nWenn der Code in einem MR mit dem Standard-Branch (normalerweise auf Produktionsebene) zusammengeführt wird, wird der Sicherheitslückenbericht mit den Ergebnissen des Sicherheitsscans gefüllt. Diese Ergebnisse können von Sicherheitsteams verwendet werden, um die in der Produktion gefundenen Sicherheitslücken zu verwalten und zu kategorisieren.\n\n![Sicherheitslückenbericht mit Batch-Status-Einstellung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/vulnerability_report_aHR0cHM6_1750099596936.png)\n\n\u003Ccenter>\u003Ci>Sicherheitslückenbericht mit Batch-Status-Einstellung\u003C/i>\u003C/center>\u003Cbr>\n\nWenn du im Sicherheitslückenbericht auf eine Sicherheitslückenbeschreibung klickst, wird dir die Sicherheitslückenseite angezeigt, die die gleichen Sicherheitslückendaten wie der MR enthält, sodass bei der Bewertung der Auswirkungen und der Behebung der Sicherheitslücke nur eine einzige Quelle der Wahrheit gilt. Auf der Seite der Sicherheitslücke kannst du die KI-Funktionen von [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) nutzen, um dir die Sicherheitslücke erklären zu lassen und einen MR zur Behebung zu erstellen, wodurch die Zeit bis zur Lösung verkürzt wird.\n\n> ##### Weitere Informationen zu den in GitLab enthaltenen Sicherheitsscans und zum Umgang mit Sicherheitslücken findest du in unserer [Dokumentation zur Anwendungssicherheit (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/).\n\n### Software-Stückliste\n\nGitLab kann eine detaillierte Liste von allen Komponenten erstellen, die deine Software verwendet – sozusagen eine „Zutatenliste“ für deinen Code. Diese Liste, die als Software-Stückliste ([SBOM](https://about.gitlab.com/de-de/blog/the-ultimate-guide-to-sboms/)) bezeichnet wird, zeigt dir den gesamten externen Code, von dem dein Projekt abhängig ist, einschließlich der Teile, die du direkt verwendest, und deren eigener Abhängigkeiten. Für jedes Element kannst du sehen, welche Version du verwendest, welche Lizenz es hat und ob es bekannte Sicherheitsprobleme gibt. So kannst du den Überblick über den Inhalt deiner Software behalten und potenzielle Risiken erkennen.\n\n![Liste der Abhängigkeiten auf Gruppenebene (SBOM)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/sbom_aHR0cHM6_1750099596937.png)\n\n\u003Ccenter>\u003Ci>Liste der Abhängigkeiten auf Gruppenebene (SBOM)\u003C/i>\u003C/center>\n\n> ##### Erfahre in unserer [Dokumentation zur Liste der Abhängigkeiten (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/dependency_list/), wie du auf die Liste der Abhängigkeiten zugreifen und sie verwenden kannst.\n\n### System-Audits und Überprüfung der Sicherheitslage\n\nGitLab verfolgt alles, was in deinem System passiert, z. B. wer wann welche Änderungen vorgenommen hat. Stell dir das wie eine Überwachungskamera für deinen Code vor. Diese Aufzeichnungen helfen dir:\n\n* verdächtige Aktivitäten zu erkennen\n\n* den regulatorischen Behörden zu zeigen, dass du die Regeln befolgst\n\n* zu erkennen, was passiert ist, wenn etwas schiefgelaufen ist\n\n* zu sehen, wie deine Teams GitLab verwenden\n\nAll diese Informationen werden an einem Ort gespeichert und können dadurch bei Bedarf einfach überprüft und angesehen werden. Du kannst zum Beispiel Audit Events verwenden, um Folgendes zu verfolgen:\n\n* Wer hat die Berechtigungsstufe bestimmter Benutzer(innen) für ein GitLab-Projekt geändert und wann?\n\n* Wer hat neue Benutzer(innen) hinzugefügt oder Benutzer(innen) entfernt und wann?\n\n![Audit Events auf Projektebene](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/audit_events_aHR0cHM6_1750099596938.png)\n\n\u003Ccenter>\u003Ci>Audit Events auf Projektebene\u003C/i>\u003C/center>\n\n> ##### Weitere Informationen zu Audit Events findest du in der [Dokumentation zu Audit Events (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/compliance/audit_events.html).\n\n## Compliance und Überwachung der Sicherheitslage\n\nDas Sicherheits-Dashboard von GitLab fungiert als Kontrollraum, an dem alle deine Sicherheitsrisiken an einem Ort anzeigt werden. Anstatt verschiedene Sicherheitstools einzeln zu überprüfen, kannst du alle Ergebnisse zusammen auf einem Bildschirm sehen. So kannst du Sicherheitsprobleme in all deinen Projekten leicht erkennen und beheben.\n\n![Sicherheits-Dashboard auf Gruppenebene](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/security_dashboard_aHR0cHM6_1750099596939.png)\n\n\u003Ccenter>\u003Ci>Sicherheits-Dashboard auf Gruppenebene\u003C/i>\u003C/center>\n\n> ##### Weitere Informationen zu Sicherheits-Dashboards findest du in unserer [Dokumentation zum Sicherheits-Dashboard (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/security_dashboard/).\n\n## Einführung von Verfahren zur Identifizierung und Minderung von Risiken\n\nSicherheitslücken durchlaufen einen bestimmten Lebenszyklus. Ein Teil des Prozesses kann beispielsweise darin bestehen, dass für jeden anfälligen Code, der mit geschützten Branches zusammengeführt werden soll, mittels der Sicherheitsrichtlinien festgelegt wird, dass ein Approval erforderlich ist. Dann kann festgelegt werden, dass in der Produktion entdeckter anfälliger Code priorisiert, bewertet, behoben und anschließend validiert werden muss:\n\n* Die Kriterien für die Priorisierung können sich nach dem Schweregrad der Sicherheitslücke richten, der von den GitLab-Scannern erkannt wird.\n\n* Die Bewertung kann anhand der von GitLab Duo Vulnerability Explanation bereitgestellten Details zur Ausnutzung erfolgen.\n\n* Sobald die Sicherheitslücke behoben ist, kann sie mit den integrierten Regressionstests und Scannern von GitLab validiert werden.\n\nAuch wenn die Anforderungen jedes Unternehmens unterschiedlich sind, können mit GitLab als Plattform Risiken schnell identifiziert und mit geringerem Risiko behoben werden, als bei der Nutzung unterschiedlicher Tools der Fall wäre.\n\n### Best Practices für die SOC-2-Compliance\n\n* Etabliere eine starke Sicherheitskultur: Fördere Sicherheitsbewusstsein und Verantwortlichkeit in deinem gesamten Unternehmen.\n\n* Dokumentiere alles: Führe eine gründliche Dokumentation der Richtlinien, Verfahren und Kontrollen.\n\n* Automatisiere, wo möglich: Verwende Automatisierungstools, um Compliance-Prozesse zu optimieren und Fehler zu reduzieren.\n\n* Kommuniziere effektiv: Halte die Stakeholder(innen) über deine Compliance-Bemühungen auf dem Laufenden.\n\n* Hol dir fachkundige Beratung: Überlege, mit qualifizierten Berater(inne)n zusammenzuarbeiten, die dich auf deinem Weg zur SOC-2-Konformität unterstützen.\n\nEs ist ein bedeutendes Vorhaben, SOC-2-Compliance zu erreichen, aber die Vorteile sind unbestreitbar. Indem du dein Engagement für Anwendungssicherheit und betriebliche Exzellenz zeigst, fassen deine Kund(inn)en Vertrauen zu dir, verbesserst du deinen Ruf und behältst einen Wettbewerbsvorteil auf dem Markt.\n\n## Weiterlesen\n\nSieh dir die folgenden Ressourcen an, um mehr über GitLab und darüber zu erfahren, wie wir dich auf deinem Weg zur SOCv2-Compliance unterstützen:\n\n* [GitLab Ultimate](https://about.gitlab.com/de-de/pricing/ultimate/)\n\n* [Sicherheits- und Compliance-Lösungen von GitLab](https://about.gitlab.com/de-de/solutions/application-security-testing/)\n\n* [Dokumentation zur Anwendungssicherheit mit GitLab](https://docs.gitlab.com/ee/user/application_security/)\n\n* [Tutorial-Projekt für DevSecOps mit GitLab (nur in englischer Sprache verfügbar)](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)",[23,9,24,25,26],"tutorial","DevSecOps platform","features","product","yml",{},"/de-de/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab",{"ogTitle":15,"ogImage":19,"ogDescription":16,"ogSiteName":31,"noIndex":32,"ogType":33,"ogUrl":34,"title":15,"canonicalUrls":34,"description":16},"https://about.gitlab.com",false,"Artikel","https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab","de-de/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab",[23,9,37,25,26],"devsecops-platform","o-rQ2yDompDg5tzT9Z6yYe-72tf3E6xbqPDfLiKoHA4",{"data":40},{"logo":41,"freeTrial":46,"sales":51,"login":56,"items":61,"search":370,"minimal":405,"duo":423,"pricingDeployment":433},{"config":42},{"href":43,"dataGaName":44,"dataGaLocation":45},"/de-de/","gitlab logo","header",{"text":47,"config":48},"Kostenlose Testversion anfordern",{"href":49,"dataGaName":50,"dataGaLocation":45},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":52,"config":53},"Vertrieb kontaktieren",{"href":54,"dataGaName":55,"dataGaLocation":45},"/de-de/sales/","sales",{"text":57,"config":58},"Anmelden",{"href":59,"dataGaName":60,"dataGaLocation":45},"https://gitlab.com/users/sign_in/","sign in",[62,89,185,190,291,351],{"text":63,"config":64,"cards":66},"Plattform",{"dataNavLevelOne":65},"platform",[67,73,81],{"title":63,"description":68,"link":69},"Die intelligente Orchestrierungsplattform für DevSecOps",{"text":70,"config":71},"Erkunde unsere Plattform",{"href":72,"dataGaName":65,"dataGaLocation":45},"/de-de/platform/",{"title":74,"description":75,"link":76},"GitLab Duo Agent Platform","Agentische KI für den gesamten Softwareentwicklungszyklus",{"text":77,"config":78},"Lerne GitLab Duo kennen",{"href":79,"dataGaName":80,"dataGaLocation":45},"/de-de/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":82,"description":83,"link":84},"Gründe, die für GitLab sprechen","Erfahre, warum Unternehmen auf GitLab setzen",{"text":85,"config":86},"Mehr erfahren",{"href":87,"dataGaName":88,"dataGaLocation":45},"/de-de/why-gitlab/","why gitlab",{"text":90,"left":12,"config":91,"link":93,"lists":97,"footer":167},"Produkt",{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"Alle Lösungen anzeigen",{"href":96,"dataGaName":92,"dataGaLocation":45},"/de-de/solutions/",[98,123,145],{"title":99,"description":100,"link":101,"items":106},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":45},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[107,111,114,119],{"text":108,"config":109},"CI/CD",{"href":110,"dataGaLocation":45,"dataGaName":108},"/de-de/solutions/continuous-integration/",{"text":74,"config":112},{"href":79,"dataGaLocation":45,"dataGaName":113},"gitlab duo agent platform - product menu",{"text":115,"config":116},"Quellcodeverwaltung",{"href":117,"dataGaLocation":45,"dataGaName":118},"/de-de/solutions/source-code-management/","Source Code Management",{"text":120,"config":121},"Automatisierte Softwarebereitstellung",{"href":104,"dataGaLocation":45,"dataGaName":122},"Automated software delivery",{"title":124,"description":125,"link":126,"items":131},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":127},{"href":128,"dataGaName":129,"dataGaLocation":45,"icon":130},"/de-de/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[132,136,141],{"text":133,"config":134},"Application Security Testing",{"href":128,"dataGaName":135,"dataGaLocation":45},"Application security testing",{"text":137,"config":138},"Schutz der Software-Lieferkette",{"href":139,"dataGaLocation":45,"dataGaName":140},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":142,"config":143},"Software Compliance",{"href":144,"dataGaName":142,"dataGaLocation":45},"/de-de/solutions/software-compliance/",{"title":146,"link":147,"items":152},"Bewertung",{"config":148},{"icon":149,"href":150,"dataGaName":151,"dataGaLocation":45},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[153,157,162],{"text":154,"config":155},"Sichtbarkeit und Bewertung",{"href":150,"dataGaLocation":45,"dataGaName":156},"Visibility and Measurement",{"text":158,"config":159},"Wertstrommanagement",{"href":160,"dataGaLocation":45,"dataGaName":161},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":163,"config":164},"Analysen und Einblicke",{"href":165,"dataGaLocation":45,"dataGaName":166},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":168,"items":169},"GitLab für",[170,175,180],{"text":171,"config":172},"Enterprise",{"href":173,"dataGaLocation":45,"dataGaName":174},"/de-de/enterprise/","enterprise",{"text":176,"config":177},"Kleinunternehmen",{"href":178,"dataGaLocation":45,"dataGaName":179},"/de-de/small-business/","small business",{"text":181,"config":182},"den öffentlichen Sektor",{"href":183,"dataGaLocation":45,"dataGaName":184},"/de-de/solutions/public-sector/","public sector",{"text":186,"config":187},"Preise",{"href":188,"dataGaName":189,"dataGaLocation":45,"dataNavLevelOne":189},"/de-de/pricing/","pricing",{"text":191,"config":192,"link":194,"lists":198,"feature":278},"Ressourcen",{"dataNavLevelOne":193},"resources",{"text":195,"config":196},"Alle Ressourcen anzeigen",{"href":197,"dataGaName":193,"dataGaLocation":45},"/de-de/resources/",[199,232,250],{"title":200,"items":201},"Erste Schritte",[202,207,212,217,222,227],{"text":203,"config":204},"Installieren",{"href":205,"dataGaName":206,"dataGaLocation":45},"/de-de/install/","install",{"text":208,"config":209},"Kurzanleitungen",{"href":210,"dataGaName":211,"dataGaLocation":45},"/de-de/get-started/","quick setup checklists",{"text":213,"config":214},"Lernen",{"href":215,"dataGaLocation":45,"dataGaName":216},"https://university.gitlab.com/","learn",{"text":218,"config":219},"Produktdokumentation",{"href":220,"dataGaName":221,"dataGaLocation":45},"https://docs.gitlab.com/","product documentation",{"text":223,"config":224},"Best-Practice-Videos",{"href":225,"dataGaName":226,"dataGaLocation":45},"/de-de/getting-started-videos/","best practice videos",{"text":228,"config":229},"Integrationen",{"href":230,"dataGaName":231,"dataGaLocation":45},"/de-de/integrations/","integrations",{"title":233,"items":234},"Entdecken",[235,240,245],{"text":236,"config":237},"Kundenerfolge",{"href":238,"dataGaName":239,"dataGaLocation":45},"/de-de/customers/","customer success stories",{"text":241,"config":242},"Blog",{"href":243,"dataGaName":244,"dataGaLocation":45},"/de-de/blog/","blog",{"text":246,"config":247},"Remote",{"href":248,"dataGaName":249,"dataGaLocation":45},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":251,"items":252},"Vernetzen",[253,258,263,268,273],{"text":254,"config":255},"GitLab-Services",{"href":256,"dataGaName":257,"dataGaLocation":45},"/de-de/services/","services",{"text":259,"config":260},"Community",{"href":261,"dataGaName":262,"dataGaLocation":45},"/community/","community",{"text":264,"config":265},"Forum",{"href":266,"dataGaName":267,"dataGaLocation":45},"https://forum.gitlab.com/","forum",{"text":269,"config":270},"Veranstaltungen",{"href":271,"dataGaName":272,"dataGaLocation":45},"/events/","events",{"text":274,"config":275},"Partner",{"href":276,"dataGaName":277,"dataGaLocation":45},"/de-de/partners/","partners",{"backgroundColor":279,"textColor":280,"text":281,"image":282,"link":286},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":283,"config":284},"the source promo card",{"src":285},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":287,"config":288},"Lies die News",{"href":289,"dataGaName":290,"dataGaLocation":45},"/de-de/the-source/","the source",{"text":292,"config":293,"lists":295},"Unternehmen",{"dataNavLevelOne":294},"company",[296],{"items":297},[298,303,309,311,316,321,326,331,336,341,346],{"text":299,"config":300},"Über",{"href":301,"dataGaName":302,"dataGaLocation":45},"/de-de/company/","about",{"text":304,"config":305,"footerGa":308},"Karriere",{"href":306,"dataGaName":307,"dataGaLocation":45},"/jobs/","jobs",{"dataGaName":307},{"text":269,"config":310},{"href":271,"dataGaName":272,"dataGaLocation":45},{"text":312,"config":313},"Geschäftsführung",{"href":314,"dataGaName":315,"dataGaLocation":45},"/company/team/e-group/","leadership",{"text":317,"config":318},"Team",{"href":319,"dataGaName":320,"dataGaLocation":45},"/company/team/","team",{"text":322,"config":323},"Handbuch",{"href":324,"dataGaName":325,"dataGaLocation":45},"https://handbook.gitlab.com/","handbook",{"text":327,"config":328},"Investor Relations",{"href":329,"dataGaName":330,"dataGaLocation":45},"https://ir.gitlab.com/","investor relations",{"text":332,"config":333},"Trust Center",{"href":334,"dataGaName":335,"dataGaLocation":45},"/de-de/security/","trust center",{"text":337,"config":338},"AI Transparency Center",{"href":339,"dataGaName":340,"dataGaLocation":45},"/de-de/ai-transparency-center/","ai transparency center",{"text":342,"config":343},"Newsletter",{"href":344,"dataGaName":345,"dataGaLocation":45},"/company/contact/#contact-forms","newsletter",{"text":347,"config":348},"Presse",{"href":349,"dataGaName":350,"dataGaLocation":45},"/press/","press",{"text":352,"config":353,"lists":354},"Kontakt",{"dataNavLevelOne":294},[355],{"items":356},[357,360,365],{"text":52,"config":358},{"href":54,"dataGaName":359,"dataGaLocation":45},"talk to sales",{"text":361,"config":362},"Support-Portal",{"href":363,"dataGaName":364,"dataGaLocation":45},"https://support.gitlab.com","support portal",{"text":366,"config":367},"Kundenportal",{"href":368,"dataGaName":369,"dataGaLocation":45},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":371,"login":372,"suggestions":379},"Schließen",{"text":373,"link":374},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":375,"config":376},"gitlab.com",{"href":59,"dataGaName":377,"dataGaLocation":378},"search login","search",{"text":380,"default":381},"Vorschläge",[382,384,389,391,396,401],{"text":74,"config":383},{"href":79,"dataGaName":74,"dataGaLocation":378},{"text":385,"config":386},"Code Suggestions (KI)",{"href":387,"dataGaName":388,"dataGaLocation":378},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":108,"config":390},{"href":110,"dataGaName":108,"dataGaLocation":378},{"text":392,"config":393},"GitLab auf AWS",{"href":394,"dataGaName":395,"dataGaLocation":378},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":397,"config":398},"GitLab auf Google Cloud",{"href":399,"dataGaName":400,"dataGaLocation":378},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":402,"config":403},"Warum GitLab?",{"href":87,"dataGaName":404,"dataGaLocation":378},"Why GitLab?",{"freeTrial":406,"mobileIcon":411,"desktopIcon":416,"secondaryButton":419},{"text":407,"config":408},"Kostenlos testen",{"href":409,"dataGaName":50,"dataGaLocation":410},"https://gitlab.com/-/trials/new/","nav",{"altText":412,"config":413},"GitLab-Symbol",{"src":414,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":412,"config":417},{"src":418,"dataGaName":415,"dataGaLocation":410},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":200,"config":420},{"href":421,"dataGaName":422,"dataGaLocation":410},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/compare/gitlab-vs-github/","get started",{"freeTrial":424,"mobileIcon":429,"desktopIcon":431},{"text":425,"config":426},"Erfahre mehr über GitLab Duo",{"href":427,"dataGaName":428,"dataGaLocation":410},"/de-de/gitlab-duo/","gitlab duo",{"altText":412,"config":430},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":432},{"src":418,"dataGaName":415,"dataGaLocation":410},{"freeTrial":434,"mobileIcon":439,"desktopIcon":441},{"text":435,"config":436},"Zurück zur Preisübersicht",{"href":188,"dataGaName":437,"dataGaLocation":410,"icon":438},"back to pricing","GoBack",{"altText":412,"config":440},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":442},{"src":418,"dataGaName":415,"dataGaLocation":410},{"title":444,"button":445,"config":450},"Sieh dir an, wie agentische KI die Softwarebereitstellung transformiert",{"text":446,"config":447},"GitLab Transcend jetzt ansehen",{"href":448,"dataGaName":449,"dataGaLocation":45},"/de-de/events/transcend/virtual/","transcend event",{"layout":451,"icon":452},"release","AiStar",{"data":454},{"text":455,"source":456,"edit":462,"contribute":467,"config":472,"items":477,"minimal":650},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":457,"config":458},"Quelltext der Seite anzeigen",{"href":459,"dataGaName":460,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":463,"config":464},"Diese Seite bearbeiten",{"href":465,"dataGaName":466,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":468,"config":469},"Beteilige dich",{"href":470,"dataGaName":471,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":473,"facebook":474,"youtube":475,"linkedin":476},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[478,501,556,583,617],{"title":63,"links":479,"subMenu":484},[480],{"text":481,"config":482},"DevSecOps-Plattform",{"href":72,"dataGaName":483,"dataGaLocation":461},"devsecops platform",[485],{"title":186,"links":486},[487,491,496],{"text":488,"config":489},"Tarife anzeigen",{"href":188,"dataGaName":490,"dataGaLocation":461},"view plans",{"text":492,"config":493},"Vorteile von Premium",{"href":494,"dataGaName":495,"dataGaLocation":461},"/de-de/pricing/premium/","why premium",{"text":497,"config":498},"Vorteile von Ultimate",{"href":499,"dataGaName":500,"dataGaLocation":461},"/de-de/pricing/ultimate/","why ultimate",{"title":502,"links":503},"Lösungen",[504,509,512,514,519,524,528,531,534,539,541,543,546,551],{"text":505,"config":506},"Digitale Transformation",{"href":507,"dataGaName":508,"dataGaLocation":461},"/de-de/topics/digital-transformation/","digital transformation",{"text":510,"config":511},"Sicherheit und Compliance",{"href":128,"dataGaName":135,"dataGaLocation":461},{"text":120,"config":513},{"href":104,"dataGaName":105,"dataGaLocation":461},{"text":515,"config":516},"Agile Entwicklung",{"href":517,"dataGaName":518,"dataGaLocation":461},"/de-de/solutions/agile-delivery/","agile delivery",{"text":520,"config":521},"Cloud-Transformation",{"href":522,"dataGaName":523,"dataGaLocation":461},"/de-de/topics/cloud-native/","cloud transformation",{"text":525,"config":526},"SCM",{"href":117,"dataGaName":527,"dataGaLocation":461},"source code management",{"text":108,"config":529},{"href":110,"dataGaName":530,"dataGaLocation":461},"continuous integration & delivery",{"text":158,"config":532},{"href":160,"dataGaName":533,"dataGaLocation":461},"value stream management",{"text":535,"config":536},"GitOps",{"href":537,"dataGaName":538,"dataGaLocation":461},"/de-de/solutions/gitops/","gitops",{"text":171,"config":540},{"href":173,"dataGaName":174,"dataGaLocation":461},{"text":176,"config":542},{"href":178,"dataGaName":179,"dataGaLocation":461},{"text":544,"config":545},"Öffentlicher Sektor",{"href":183,"dataGaName":184,"dataGaLocation":461},{"text":547,"config":548},"Bildungswesen",{"href":549,"dataGaName":550,"dataGaLocation":461},"/de-de/solutions/education/","education",{"text":552,"config":553},"Finanzdienstleistungen",{"href":554,"dataGaName":555,"dataGaLocation":461},"/de-de/solutions/finance/","financial services",{"title":191,"links":557},[558,560,562,564,567,569,571,573,575,577,579,581],{"text":203,"config":559},{"href":205,"dataGaName":206,"dataGaLocation":461},{"text":208,"config":561},{"href":210,"dataGaName":211,"dataGaLocation":461},{"text":213,"config":563},{"href":215,"dataGaName":216,"dataGaLocation":461},{"text":218,"config":565},{"href":220,"dataGaName":566,"dataGaLocation":461},"docs",{"text":241,"config":568},{"href":243,"dataGaName":244,"dataGaLocation":461},{"text":236,"config":570},{"href":238,"dataGaName":239,"dataGaLocation":461},{"text":246,"config":572},{"href":248,"dataGaName":249,"dataGaLocation":461},{"text":254,"config":574},{"href":256,"dataGaName":257,"dataGaLocation":461},{"text":259,"config":576},{"href":261,"dataGaName":262,"dataGaLocation":461},{"text":264,"config":578},{"href":266,"dataGaName":267,"dataGaLocation":461},{"text":269,"config":580},{"href":271,"dataGaName":272,"dataGaLocation":461},{"text":274,"config":582},{"href":276,"dataGaName":277,"dataGaLocation":461},{"title":292,"links":584},[585,587,589,591,593,595,597,601,606,608,610,612],{"text":299,"config":586},{"href":301,"dataGaName":294,"dataGaLocation":461},{"text":304,"config":588},{"href":306,"dataGaName":307,"dataGaLocation":461},{"text":312,"config":590},{"href":314,"dataGaName":315,"dataGaLocation":461},{"text":317,"config":592},{"href":319,"dataGaName":320,"dataGaLocation":461},{"text":322,"config":594},{"href":324,"dataGaName":325,"dataGaLocation":461},{"text":327,"config":596},{"href":329,"dataGaName":330,"dataGaLocation":461},{"text":598,"config":599},"Sustainability",{"href":600,"dataGaName":598,"dataGaLocation":461},"/sustainability/",{"text":602,"config":603},"Vielfalt, Inklusion und Zugehörigkeit",{"href":604,"dataGaName":605,"dataGaLocation":461},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":332,"config":607},{"href":334,"dataGaName":335,"dataGaLocation":461},{"text":342,"config":609},{"href":344,"dataGaName":345,"dataGaLocation":461},{"text":347,"config":611},{"href":349,"dataGaName":350,"dataGaLocation":461},{"text":613,"config":614},"Transparenzerklärung zu moderner Sklaverei",{"href":615,"dataGaName":616,"dataGaLocation":461},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":618,"links":619},"Nimm Kontakt auf",[620,623,628,630,635,640,645],{"text":621,"config":622},"Sprich mit einem Experten/einer Expertin",{"href":54,"dataGaName":55,"dataGaLocation":461},{"text":624,"config":625},"Support",{"href":626,"dataGaName":627,"dataGaLocation":461},"/support/","get help",{"text":366,"config":629},{"href":368,"dataGaName":369,"dataGaLocation":461},{"text":631,"config":632},"Status",{"href":633,"dataGaName":634,"dataGaLocation":461},"https://status.gitlab.com/","status",{"text":636,"config":637},"Nutzungsbedingungen",{"href":638,"dataGaName":639,"dataGaLocation":461},"/terms/","terms of use",{"text":641,"config":642},"Datenschutzerklärung",{"href":643,"dataGaName":644,"dataGaLocation":461},"/de-de/privacy/","privacy statement",{"text":646,"config":647},"Cookie-Einstellungen",{"dataGaName":648,"dataGaLocation":461,"id":649,"isOneTrustButton":12},"cookie preferences","ot-sdk-btn",{"items":651},[652,654,656],{"text":636,"config":653},{"href":638,"dataGaName":639,"dataGaLocation":461},{"text":641,"config":655},{"href":643,"dataGaName":644,"dataGaLocation":461},{"text":646,"config":657},{"dataGaName":648,"dataGaLocation":461,"id":649,"isOneTrustButton":12},[659],{"id":660,"title":18,"body":8,"config":661,"content":663,"description":8,"extension":27,"meta":667,"navigation":12,"path":668,"seo":669,"stem":670,"__hash__":671},"blogAuthors/en-us/blog/authors/fernando-diaz.yml",{"template":662},"BlogAuthor",{"name":18,"config":664},{"headshot":665,"ctfId":666},"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",[673,686,698],{"content":674,"config":684},{"title":675,"description":676,"authors":677,"heroImage":680,"date":681,"body":682,"category":9,"tags":683},"Schwachstellen-Behebung mit dem aktualisierten GitLab Security Dashboard verfolgen","Behebungsmaßnahmen in risikoreichen Projekten priorisieren und Fortschritte mit Schwachstellen-Insights messen.",[678,679],"Alisa Ho","Mike Clausen","https://res.cloudinary.com/about-gitlab-com/image/upload/v1771438388/t6sts5qw4z8561gtlxiq.png","2026-02-19","Security-Teams und Entwicklungsteams kennen das Problem: Tausende von Schwachstellen, die Aufmerksamkeit erfordern – ohne die nötigen Informationen zur Priorisierung der Behebung. Wo konzentriert sich das Risiko, und wie schnell wird es behoben? Wo hat die Behebung die größte Wirkung? Das aktualisierte GitLab Security Dashboard beantwortet diese Fragen mit Trend-Tracking, Altersverteilung von Schwachstellen und projektbezogenem Risiko-Scoring.\n\n## Behebung messen, nicht nur Erkennung\nApplication-Security-Teams haben selten Schwierigkeiten, Schwachstellen zu finden – die Herausforderung liegt im Einordnen. Die meisten Dashboards zeigen rohe Zählwerte ohne Kontext und zwingen Teams dazu, stundenlang Behebungsmaßnahmen nachzuverfolgen, ohne zu verstehen, welche Schwachstellen das größte Risiko darstellen.\n\nDas [GitLab Security Dashboard](https://docs.gitlab.com/user/application_security/security_dashboard/#new-security-dashboards) fasst alle Schwachstellendaten in einer Ansicht zusammen, die Projekte, Gruppen und Geschäftsbereiche übergreift.\n\nIn Version 18.6 wurde die erste Version des aktualisierten Security Dashboards eingeführt, mit der Teams Schwachstellen im Zeitverlauf anzeigen und nach Projekt oder Berichtstyp filtern können. Mit dem [18.9-Release](https://about.gitlab.com/releases/2026/02/19/gitlab-18-9-released/) stehen neue Filter und Diagramme zur Verfügung, die es erleichtern, Daten nach Schweregrad, Status, Scanner oder Projekt aufzuschlüsseln und Trends wie offene Schwachstellen, Behebungsgeschwindigkeit, Altersverteilung von Schwachstellen und Risiko-Score im Zeitverlauf zu visualisieren.\n\nRisiko-Scores helfen dabei, die kritischsten Schwachstellen vorrangig zu beheben. Der Risiko-Score wird anhand von Faktoren wie dem Alter der Schwachstelle, dem Exploit Prediction Scoring System (EPSS) und Known Exploited Vulnerability (KEV)-Scores für die betreffenden Repositories und deren Sicherheitsstatus berechnet. Auf dieser Grundlage lassen sich die Bereiche identifizieren, die am dringendsten Aufmerksamkeit benötigen.\n\nDas GitLab Security Dashboard unterstützt Application-Security- und Entwicklungsteams dabei:\n* **Programm-Effektivität verfolgen**: Behebungsgeschwindigkeit, Scanner-Nutzung und Risikostatus überwachen, um messbare Verbesserungen nachzuweisen.\n* **Gezielte Behebung priorisieren**: Schwachstellen beheben, die das größte Risiko für Produktionssysteme darstellen.\n* **Schulungsbedarf identifizieren**: Teams erkennen, die bei der Behebung von Schwachstellen gemäß unternehmensinterner Richtlinien Schwierigkeiten haben, und gezielt in Weiterbildung investieren.\n* **Manuelles Reporting reduzieren**: Externe Dashboards und Tabellen ersetzen, indem alles direkt in GitLab nachverfolgt wird.\n\nDieses Update unterstreicht GitLabs Ansatz, Sicherheit messbar, kontextbezogen und in die täglichen Entwicklungsabläufe integriert zu gestalten. Das GitLab Security Dashboard verwandelt rohe Befunde in handlungsrelevante Erkenntnisse und gibt Security- und Entwicklungsteams die Grundlage, um zu priorisieren, Risiken zu reduzieren und den Fortschritt zu belegen.\n\n## Das Security Dashboard in der Praxis\nEine Application-Security-Führungskraft, die ein Executive Briefing vorbereitet, kann nun anhand klarer Trendlinien zeigen, ob Investitionen die Risikolage verbessern: sinkende Anzahl offener Schwachstellen, abnehmendes Schwachstellenalter, rückläufige ehemals häufige CWE-Typen und ein stabiler Risiko-Score. Statt roher Zählwerte lässt sich demonstrieren, wie der Rückstand abgebaut wird und wie sich die Sicherheitslage Quartal für Quartal verbessert.\n\nGleichzeitig sehen Entwicklungsteams im selben Dashboard die kritischen Schwachstellen in ihren aktiven Projekten – und können Behebungsmaßnahmen priorisieren, ohne Daten zu exportieren oder zwischen mehreren Tools zu wechseln.\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1166108924?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=\"Security-Dashboard-Demo-Final\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> Weitere Informationen zum Einstieg in das GitLab Security Dashboard in der [Dokumentation](https://docs.gitlab.com/user/application_security/security_dashboard/).",[9,26,25],{"featured":32,"template":13,"slug":685},"track-vulnerability-remediation-with-the-updated-gitlab-security-dashboard",{"content":687,"config":696},{"title":688,"description":689,"authors":690,"heroImage":691,"date":692,"category":9,"tags":693,"body":695},"OWASP Top 10 2025: Was sich geändert hat und warum es wichtig ist","Neue Supply-Chain- und Error-Handling-Risiken, Ranking-Verschiebungen und Remediation-Strategien für alle 10 Kategorien.",[18],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1759320418/xjmqcozxzt4frx0hori3.png","2026-02-17",[9,694],"open source","Die OWASP Foundation hat die [achte Edition ihrer einflussreichen „Top 10 Security Risks\"-Liste für 2025](https://owasp.org/Top10/2025/0x00_2025-Introduction/) veröffentlicht und führt bedeutende Änderungen ein, die die sich entwickelnde Landschaft der Applikationssicherheit widerspiegeln. Basierend auf der Analyse von mehr als 175.000 Common Vulnerabilities and Exposures (CVEs) und Feedback von Security-Praktikern weltweit adressiert dieses Update moderne Angriffsvektoren. Im Folgenden wird erläutert, was sich geändert hat, warum diese Änderungen wichtig sind und wie Systeme geschützt werden können.\n\n\n> :bulb: Am 10. Februar hat GitLab auf der Transcend gezeigt, wie Agentic AI Software Delivery transformiert – mit Kunden-Einblicken und Impulsen zur Modernisierung. [Mehr erfahren.](https://about.gitlab.com/de-de/events/transcend/virtual/)\n\n\n## Was ist neu in 2025?\n\nDie Verschiebung von 2021 (als die Liste zuletzt erschien) zu 2025 stellt mehr als kleine Anpassungen dar – es ist ein fundamentaler Wandel in der Applikationssicherheit. Zwei vollständig neue Kategorien wurden in die Liste aufgenommen und eine Kategorie in eine andere konsolidiert, was aufkommende Risiken hervorhebt, die traditionelle Tests oft übersehen.\n\nDiese Ergänzungen und Verschiebungen sind in der folgenden Grafik zu sehen:\n\n![OWASP Top 10 - Changes from 2021 to 2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639428/tbekzibeqylorwqrkdau.png)\n\n\n### Zwei neue Kategorien\n\n- **A03: Software Supply Chain Failures**: Erweitert die 2021-Kategorie „Vulnerable and Outdated Components\" um die gesamte Software-Supply-Chain, einschließlich Dependencies, Build-Systeme und Distributions-Infrastruktur. Trotz der geringsten Vorkommen in Testdaten hat diese Kategorie die höchsten durchschnittlichen Exploit- und Impact-Scores aus CVEs.\n\n- **A10: Mishandling of Exceptional Conditions**: Fokussiert auf fehlerhafte Error-Behandlung, logische Fehler und Failing-Open-Szenarien. Diese Kategorie adressiert, wie Systeme auf abnormale Bedingungen reagieren.\n\n### Wesentliche Ranking-Änderungen\n\n- Security Misconfiguration stieg von #5 (2021) auf #2 (2025) und betrifft nun 3 % der getesteten Applikationen.\n- Server-Side Request Forgery (SSRF) wurde in A01: Broken Access Control konsolidiert.\n- Cryptographic Failures fielen von #2 auf #4.\n- Injection fiel von #3 auf #5.\n- Insecure Design verschob sich von #4 auf #6.\n\n## Warum diese Änderungen vorgenommen wurden\n\nDie OWASP-Methodik kombiniert datengetriebene Analyse mit Community-Einblicken. Die 2025-Edition analysierte 589 Common Weakness Enumerations (CWEs) – eine substanzielle Steigerung gegenüber den etwa 400 CWEs in 2021. Diese Erweiterung reflektiert die wachsende Komplexität moderner Software-Systeme und die Notwendigkeit, aufkommende Bedrohungen zu erfassen.\n\nDie Community-Survey-Komponente adressiert eine fundamentale Einschränkung: Testdaten schauen im Wesentlichen in die Vergangenheit. Bis Security-Forschende Testmethoden entwickeln und in automatisierte Tools integrieren, können Jahre vergangen sein. Die beiden community-voted Kategorien stellen sicher, dass aufkommende Risiken, die von Praktikern an vorderster Front identifiziert wurden, eingeschlossen werden – selbst wenn sie noch nicht in automatisierten Testdaten verbreitet sind.\n\nDer Anstieg von Security Misconfiguration hebt einen Branchentrend zur konfigurationsbasierten Sicherheit hervor, während Software Supply Chain Failures den Anstieg ausgefeilter Angriffe auf kompromittierte Packages widerspiegelt.\n\n## GitLab Ultimate für Vulnerability-Detection und -Management nutzen\n\nGitLab Ultimate bietet umfassendes [Security-Scanning](https://docs.gitlab.com/user/application_security/detect/) zur Erkennung von Risiken über alle OWASP-Top-10-2025-Kategorien hinweg. Die End-to-End-Plattform analysiert Quellcode, Dependencies und Infrastrukturdefinitionen von Projekten. [Advanced Static Application Security Testing (SAST)](https://docs.gitlab.com/user/application_security/sast/gitlab_advanced_sast/) erkennt Injection-Schwachstellen, Cryptographic Failures und unsichere Design-Patterns im Quellcode. [Infrastructure as Code (IaC) Scanning](https://docs.gitlab.com/user/application_security/iac_scanning/) findet Security-Fehlkonfigurationen in Deployment-Definitionen. [Secret Detection](https://docs.gitlab.com/user/application_security/secret_detection/) verhindert das Leaken von Credentials, und [Dependency Scanning](https://docs.gitlab.com/user/application_security/dependency_scanning/) deckt Bibliotheken mit bekannten Schwachstellen in der Software-Supply-Chain auf – und adressiert damit direkt die neue A03-Kategorie für Software Supply Chain Failures.\n\nDarüber hinaus:\n\n* [Dynamic Application Security Testing (DAST)](https://docs.gitlab.com/user/application_security/dast/) testet die deployten Applikationen auf Broken Access Control, Authentication Failures und Injection-Schwachstellen durch Simulation von Angriffsvektoren.\n* [API Security Testing](https://docs.gitlab.com/user/application_security/api_security/) prüft API-Endpoints auf Input-Validation-Schwächen und Authentication-Bypasses.\n* [Web API Fuzz Testing](https://docs.gitlab.com/user/application_security/api_fuzzing/) deckt auf, wie Applikationen mit Ausnahmebedingungen umgehen, indem unerwartete Inputs generiert werden – und adressiert damit direkt die neue A10-Kategorie für Mishandling of Exceptional Conditions.\n\nSecurity-Scanning integriert sich nahtlos in die [CI/CD-Pipeline](https://about.gitlab.com/de-de/topics/ci-cd/) und läuft beim Push von einem Feature-Branch, sodass Entwicklungsteams Schwachstellen beheben können, bevor sie Production erreichen. Security-Ergebnisse werden im [Vulnerability Report](https://docs.gitlab.com/user/application_security/vulnerability_report/) konsolidiert, wo Security-Teams triagieren, analysieren und die Behebung nachverfolgen können. GitLab ermöglicht außerdem den Einsatz von KI-Agents wie dem [Security Analyst Agent](https://about.gitlab.com/de-de/blog/vulnerability-triage-made-simple-with-gitlab-security-analyst-agent/) in der GitLab Duo Agent Platform, um die kritischsten Schwachstellen und die erforderlichen Maßnahmen schnell zu identifizieren.\n\nZusätzliche Kontrollen lassen sich über [Merge-Request-Approval-Policies](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/) und [Pipeline-Execution-Policies](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/) durchsetzen, um sicherzustellen, dass Security-Scanning konsistent in der gesamten Organisation ausgeführt wird. Customer-Success- und Professional-Services-Teams bei GitLab unterstützen dabei, den Wert einer GitLab-Investition zeitnah zu realisieren.\n\nSichere Software mit Security-Testing in derselben Plattform bereitstellen, die Entwicklungsteams bereits nutzen. Mehr dazu auf der [Application Security Testing Solutions-Seite](https://about.gitlab.com/de-de/solutions/application-security-testing/).\n\n## Die OWASP Top 10 2025: Vollständige Aufschlüsselung\n\n### A01: Broken Access Control\n\n##### Was es ist\n\nFehler bei der Durchsetzung von Richtlinien, die verhindern, dass Nutzende außerhalb ihrer vorgesehenen Berechtigungen handeln – was zu unbefugtem Zugriff führt.\n\n##### Auswirkungen auf das System\n\n- Unbefugte Informationsoffenlegung\n- Vollständige Datenzerstörung oder -modifikation\n- Privilege Escalation (Nutzende erlangen Admin-Rechte)\n- Einsehen oder Bearbeiten der Accounts anderer Nutzender\n- API-Zugriff von nicht autorisierten oder nicht vertrauenswürdigen Quellen\n\n##### Relevante CWEs\n\n- [CWE-22: Path Traversal](https://cwe.mitre.org/data/definitions/22.html)\n- [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor](https://cwe.mitre.org/data/definitions/200.html)\n- [CWE-352: Cross-Site Request Forgery (CSRF)](https://cwe.mitre.org/data/definitions/352.html)\n\n### A02: Security Misconfiguration\n\n##### Was es ist\n\nSysteme, Applikationen oder Cloud-Services, die aus Security-Perspektive fehlerhaft konfiguriert sind.\n\n##### Auswirkungen auf das System\n\n- Offenlegung sensibler Informationen durch Fehlermeldungen\n- Unbefugter Zugriff über Default-Accounts\n- Unnötige Services oder Features aktiviert\n- Veraltete Security-Patches\n- Server sendet keine Security-Header oder -Direktiven\n\n##### Relevante CWEs\n\n- [CWE-16: Configuration](https://cwe.mitre.org/data/definitions/16.html)\n- [CWE-521: Weak Password Requirements](https://cwe.mitre.org/data/definitions/521.html)\n- [CWE-798: Use of Hard-coded Credentials](https://cwe.mitre.org/data/definitions/798.html)\n\n### A03: Software Supply Chain Failures\n\n##### Was es ist\n\nAusfälle oder Kompromittierungen beim Erstellen, Verteilen oder Aktualisieren von Software – durch Schwachstellen oder böswillige Änderungen in Dependencies, Tools oder Build-Prozessen.\n\n##### Auswirkungen auf das System\n\n- Kompromittierte Packages, die Backdoors einschleusen\n- Schädlicher Code, der während Build-Prozessen injiziert wird\n- Verwundbare Dependencies, die sich durch die Applikation kaskadieren\n- Nutzung von Komponenten aus nicht vertrauenswürdigen Quellen in Production\n- Änderungen in der Supply Chain werden nicht nachverfolgt\n\n##### Relevante CWEs\n\n- [CWE-1395: Dependency on Vulnerable Third-Party Component](https://cwe.mitre.org/data/definitions/1395.html)\n- [CWE-1104: Use of Unmaintained Third Party Components](https://cwe.mitre.org/data/definitions/1104.html)\n\n### A04: Cryptographic Failures\n\n##### Was es ist\n\nFehler im Zusammenhang mit fehlender Kryptographie, unzureichend starker Kryptographie, Leaking von kryptographischen Schlüsseln und verwandten Fehlern.\n\n##### Auswirkungen auf das System\n\n- Offenlegung sensibler Daten (Passwörter, Kreditkarten, Gesundheitsdaten)\n- Man-in-the-Middle-Angriffe\n- Datenpanne durch schwache Verschlüsselung\n- Schlüssel-Kompromittierung mit systemweiter Exposition\n- Verstoß gegen regulatorische Compliance-Anforderungen (DSGVO, PCI DSS)\n\n##### Relevante CWEs\n\n- [CWE-327: Use of a Broken or Risky Cryptographic Algorithm](https://cwe.mitre.org/data/definitions/327.html)\n- [CWE-330: Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330.html)\n\n### A05: Injection\n\n##### Was es ist\n\nSystemschwachstellen, die es Angreifenden ermöglichen, Schadcode oder -befehle (SQL, NoSQL, OS-Befehle, LDAP usw.) in Programme einzuschleusen.\n\n##### Auswirkungen auf das System\n\n- Datenverlust oder -korruption durch SQL-Injection\n- Vollständige Datenbank-Kompromittierung\n- Server-Übernahme durch Command-Injection\n- Cross-Site-Scripting-(XSS)-Angriffe\n- Informationsoffenlegung\n- Denial of Service\n\n##### Relevante CWEs\n\n- [CWE-89: SQL Injection](https://cwe.mitre.org/data/definitions/89.html)\n- [CWE-78: OS Command Injection](https://cwe.mitre.org/data/definitions/78.html)\n\n### A06: Insecure Design\n\n##### Was es ist\n\nSchwächen im Design, die verschiedene Fehler repräsentieren – ausgedrückt als fehlendes oder unwirksames Kontrolldesign. Architekturelle Mängel statt Implementierungs-Bugs.\n\n##### Auswirkungen auf das System\n\n- Schwache Passwort-Reset-Flows\n- Fehlende Autorisierungsschritte\n- Fehlerhafte Business-Logik, die Umgehungen ermöglicht\n- Unzureichendes Threat Modeling, das blinde Flecken erzeugt\n- Design-Patterns, die unter Angriffsszenarien versagen\n\n##### Relevante CWEs\n\n- [CWE-209: Generation of Error Messages Containing Sensitive Information](https://cwe.mitre.org/data/definitions/209.html)\n- [CWE-522: Insufficiently Protected Credentials](https://cwe.mitre.org/data/definitions/522.html)\n- [CWE-656: Reliance on Security Through Obscurity](https://cwe.mitre.org/data/definitions/656.html)\n\n### A07: Authentication Failures\n\n##### Was es ist\n\nSchwachstellen, die es Angreifenden ermöglichen, Systeme dazu zu bringen, ungültige oder fehlerhafte Identitäten als legitim zu erkennen.\n\n##### Auswirkungen auf das System\n\n- Account-Übernahme und Credential Stuffing\n- Session Hijacking\n- Erfolgreiche Brute-Force-Angriffe\n- Ausnutzung schwacher Passwort-Recovery-Mechanismen\n- Multi-Faktor-Authentifizierungs-Bypass\n\n##### Relevante CWEs\n\n- [CWE-287: Improper Authentication](https://cwe.mitre.org/data/definitions/287.html)\n- [CWE-306: Missing Authentication for Critical Function](https://cwe.mitre.org/data/definitions/306.html)\n- [CWE-521: Weak Password Requirements](https://cwe.mitre.org/data/definitions/521.html)\n\n### A08: Software or Data Integrity Failures\n\n##### Was es ist\n\nCode und Infrastruktur, die nicht verhindern, dass ungültiger oder nicht vertrauenswürdiger Code/Daten als vertrauenswürdig und valide behandelt werden.\n\n##### Auswirkungen auf das System\n\n- Unsignierte Updates, die Schadcode-Injection ermöglichen\n- Insecure Deserialization, die zu Remote Code Execution führt\n- CI/CD-Pipeline-Kompromittierung\n- Ausnutzung von Auto-Update-Mechanismen\n- Manipulierte Software-Artefakte\n\n##### Relevante CWEs\n\n- [CWE-345: Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html)\n- [CWE-346: Origin Validation Error](https://cwe.mitre.org/data/definitions/346.html)\n- [CWE-347: Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html)\n\n### A09: Security Logging & Alerting Failures\n\n##### Was es ist\n\nUnzureichendes Logging und Monitoring mit inadäquatem Alerting, was schnelle Reaktion erschwert.\n\n##### Auswirkungen auf das System\n\n- Angriffe bleiben über längere Zeiträume unentdeckt\n- Breach-Investigation wird unmöglich\n- Compliance-Verstöße durch fehlende Audit-Trails\n- Verzögerte Incident-Response\n- Unfähigkeit, das Ausmaß einer Kompromittierung zu bestimmen\n\n##### Relevante CWEs\n\n- [CWE-117: Improper Output Neutralization for Logs](https://cwe.mitre.org/data/definitions/117.html)\n- [CWE-532: Insertion of Sensitive Information into Log File](https://cwe.mitre.org/data/definitions/532.html)\n- [CWE-778: Insufficient Logging](https://cwe.mitre.org/data/definitions/778.html)\n\n### A10: Mishandling of Exceptional Conditions\n\n##### Was es ist\n\nProgramme, die ungewöhnliche und unvorhersehbare Situationen nicht verhindern, erkennen und darauf reagieren – was zu Abstürzen, unerwartetem Verhalten oder Schwachstellen führt.\n\n##### Auswirkungen auf das System\n\n- Informationsoffenlegung durch zu detaillierte Fehlermeldungen\n- Denial of Service durch unbehandelte Exceptions\n- Zustandskorruption durch fehlerhafte Error-Behandlung\n- Ausnutzung von Race Conditions\n- Systeme, die bei Fehlern offen statt geschlossen schalten\n- Applikationsabstürze, die sensible Daten exponieren\n\n##### Relevante CWEs\n\n- [CWE-248: Uncaught Exception](https://cwe.mitre.org/data/definitions/248.html)\n- [CWE-390: Detection of Error Condition Without Action](https://cwe.mitre.org/data/definitions/390.html)\n- [CWE-391: Unchecked Error Condition](https://cwe.mitre.org/data/definitions/391.html)\n\n## Best Practices für Prävention und Remediation\n\nGitLab bietet Tools, die nicht nur das schnelle Finden und Beheben von Schwachstellen innerhalb der OWASP Top 10 ermöglichen, sondern auch deren Eintritt in das Production-System verhindern. Durch Befolgen dieser Best Practices lässt sich die Security-Posture verbessern und aufrechterhalten:\n\n#### Automatisiertes Security-Scanning für alle Repositories\n\n- [SAST-Scanning](https://docs.gitlab.com/user/application_security/sast/) durchführen, um unsichere Design-Patterns wie Klartext-Passwortspeicherung, inadäquates Error-Handling und fehlende Verschlüsselung während Code-Reviews zu erkennen – Design-Fehler werden früh im Entwicklungszyklus aufgefangen.\n- [Secret Detection](https://docs.gitlab.com/user/application_security/secret_detection/) durchführen, um Credentials in Konfigurationsdateien, Umgebungsvariablen und Code zu identifizieren – dies verhindert Klartext-Passwortspeicherung und stellt sicher, dass Secrets ordnungsgemäß über GitLab-CI/CD-Variablen mit Masking und Verschlüsselung verwaltet werden.\n- [DAST-Scanning](https://docs.gitlab.com/user/application_security/dast/) durchführen, um Broken-Access-Control-Schwachstellen zu erkennen.\n- [Dependency Scanning](https://docs.gitlab.com/user/application_security/dependency_scanning/) durchführen, um Projekt-Dependencies gegen Schwachstellen-Datenbanken zu scannen und bekannte CVEs in direkten und transitiven Dependencies über mehrere Package-Manager (npm, pip, Maven usw.) zu identifizieren.\n- [Container Scanning](https://docs.gitlab.com/user/application_security/container_scanning/) durchführen, um Docker-Images auf verwundbare Base-Layer und Packages zu analysieren und die Container-Supply-Chain-Sicherheit vor dem Deployment sicherzustellen.\n- [IaC-Scanning](https://docs.gitlab.com/user/application_security/iac_scanning/) durchführen, um Infrastruktur-Definitionsdateien auf bekannte Schwachstellen zu prüfen.\n- [API-Security-Tools](https://docs.gitlab.com/user/application_security/api_security/) nutzen, um Web-APIs vor unbefugtem Zugriff, Missbrauch und Angriffen zu schützen.\n- [Web API Fuzz Testing](https://docs.gitlab.com/user/application_security/api_fuzzing/) durchführen, um Bugs und potenzielle Schwachstellen zu entdecken, die andere QA-Prozesse übersehen könnten.\n\n![Security Results in MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639431/zs6xh8hz6mud3vuig3dy.png)\n\u003Cp>\u003C/p>\n\u003Ccenter>\u003Ci>Erkannte Schwachstellen im MR mit Diff von Feature-Branch zu Main-Branch anzeigen.\u003C/i>\u003C/center>\n\n#### Die Security-Posture verstehen\n\n- Eine [Software Bill of Materials (SBOM)](https://docs.gitlab.com/user/application_security/dependency_list/) generieren für vollständige Dependency-Transparenz und Compliance-Anforderungen.\n- Den [Vulnerability Report](https://docs.gitlab.com/user/application_security/vulnerability_report/) nutzen, um Schwachstellen über eine konsolidierte Ansicht der im Codebase gefundenen Security-Vulnerabilities zu triagieren.\n- Mit [detaillierter Remediation-Anleitung](https://docs.gitlab.com/user/application_security/vulnerabilities/) und [Risk-Assessment-Daten](https://docs.gitlab.com/user/application_security/vulnerabilities/risk_assessment_data/) schnell auf Schwachstellen reagieren.\n- [Security Inventory](https://docs.gitlab.com/user/application_security/security_inventory/) nutzen, um zu visualisieren, welche Assets geschützt werden müssen und welche Maßnahmen zur Verbesserung der Sicherheit erforderlich sind.\n- [Compliance Center](https://docs.gitlab.com/user/compliance/compliance_center/) nutzen, um Compliance-Standards-Adherence-Reporting, Violations-Reporting und Compliance-Frameworks zu verwalten.\n\n![Security Inventory](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639429/e9vnakc8yiyjbjm8aj7s.png)\n\u003Cp>\u003C/p>\n\u003Ccenter>\u003Ci>Security Inventory nutzen, um aktivierte Security-Scanner und Schwachstellen einzusehen.\u003C/i>\u003C/center>\n\n#### Prävention einrichten und Dokumentation pflegen\n\n- [Security Policies](https://docs.gitlab.com/user/application_security/policies/) konfigurieren, um Merges oder Deployments zu blockieren, wenn hochgradig kritische Schwachstellen in Dependencies erkannt werden – Security-Standards werden automatisch durchgesetzt.\n- [Compliance Frameworks](https://docs.gitlab.com/user/compliance/compliance_frameworks/) nutzen, um organisationsweite Security-Standards durch automatisierte Policy-Checks durchzusetzen, die Verschlüsselungsanforderungen, Credential-Management-Praktiken und sichere Workflow-Implementierungen verifizieren.\n- GitLab Wiki und Repository-Dokumentation nutzen, um Security-Design-Prinzipien, genehmigte Patterns und Architectural Decision Records zu pflegen, die Entwicklungsteams zu [Secure-by-Design-Implementierungen](https://about.gitlab.com/de-de/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/) anleiten.\n- Merge-Request-Approval-Rules implementieren, die ein Security-Architect-Review für Features erfordern, die Authentication, Authorization, Verschlüsselung oder sensible Datenverarbeitung betreffen – so wird Security-Validierung auf Design-Ebene sichergestellt.\n- Tests erstellen, um Input-Validation und Allowlist-Ansätze für Dateipfade zu verifizieren.\n- GitLab Issues und Epics nutzen, um Security-Anforderungen und Threat Models in der Design-Phase zu dokumentieren – dies schafft eine nachvollziehbare Aufzeichnung von Security-Entscheidungen und stellt sicher, dass Security-Überlegungen vor Implementierungsbeginn adressiert werden.\n\n![Security Policy Dashboard](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639429/q4eelq3rqt0oonzhwoyb.png)\n\u003Ccenter>\u003Ci>Security Policies auf Instanz-, Gruppen- oder Projektebene anzeigen und festlegen.\u003C/i>\u003C/center>\n\n#### KI nutzen\n\n- [Code Suggestions](https://docs.gitlab.com/user/project/repository/code_suggestions/) für proaktive Guidance während der Entwicklung nutzen – mit Vorschlägen für sichere Design-Patterns wie korrektes Password-Hashing (bcrypt, Argon2), verschlüsselte Speichermechanismen und angemessenes Error-Handling, das keine sensiblen Informationen preisgibt.\n- [Security Analyst Agent](https://docs.gitlab.com/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/) nutzen, um erkannte Insecure-Design-Schwachstellen im Kontext zu bewerten – mit Erklärung der architekturellen Implikationen, Risikobewertung basierend auf dem Threat Model der Applikation und Remediation-Strategien, die grundlegende Design-Fehler statt nur Symptome adressieren.\n- [Code mit KI reviewen lassen](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code), um konsistente Code-Review-Standards im Projekt sicherzustellen.\n\n![GitLab Security Analyst Agent](https://res.cloudinary.com/about-gitlab-com/image/upload/v1767639430/kqvgagepwleabt5zdkco.png)\n\u003Cp>\u003C/p>\n\u003Ccenter>\u003Ci>Security Analyst Agent nutzen, um Security-Schwachstellen schnell zu triagieren und zu bewerten.\u003C/i>\u003C/center>\n\n## Kernaussagen für Entwicklungsteams\n\n- **Supply-Chain-Sicherheit ist entscheidend**: Mit der Aufnahme von A03 und den hohen Impact-Scores ist die Absicherung der Software-Supply-Chain keine Option mehr. SBOM-Tracking, Dependency-Scanning und Integritätsprüfung sollten durchgängig in der Pipeline implementiert werden.\n- **Konfiguration ist wichtiger denn je**: Der Aufstieg auf #2 zeigt, dass konfigurationsbasierte Sicherheit nun ein primärer Angriffsvektor ist. Konfigurationsverifizierung automatisieren und IaC mit integrierter Security implementieren.\n- **Traditionelle Bedrohungen bestehen fort**: Obwohl Injection und Cryptographic Failures im Ranking gefallen sind, bleiben sie kritisch. Die Priorisierung nicht reduzieren, nur weil sie in der Liste gefallen sind.\n- **Error-Handling ist Security**: Die neue A10-Kategorie unterstreicht, dass der Umgang der Applikation mit Fehlern ein Security-Thema ist. Sicheres Error-Handling von Beginn an implementieren.\n- **Testing muss sich weiterentwickeln**: Die erweiterte CWE-Abdeckung (589 vs. 400 in 2021) bedeutet, dass Testing-Strategien umfassend sein müssen. SAST, DAST, Quellcode-Analyse und manuelles Penetration-Testing für effektive Abdeckung kombinieren.\n\n> Die [GitLab Security and Governance Solutions](https://about.gitlab.com/de-de/solutions/application-security-testing/) und die [Security-Scanning-Dokumentation](https://docs.gitlab.com/ee/user/application_security/) bieten weitere Informationen zur Stärkung der Security-Posture.\n",{"slug":697,"featured":32,"template":13},"2025-owasp-top-10-whats-changed-and-why-it-matters",{"content":699,"config":707},{"title":700,"description":701,"authors":702,"heroImage":704,"date":705,"body":706,"category":9},"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.",[703],"Rob Jackson","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098047/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1097303277_6gTk7M1DNx0tFuovupVFB1_1750098046895.jpg","2026-01-12","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**Compliance:** Zentralisiertes Identity-Management mit SSO und SCIM unterstützt Zugriffskontroll-Anforderungen aus Frameworks wie NIS2 (Artikel 21.2(i,j) Zugriffskontrolle und Multi-Faktor-Authentifizierung), ISO 27001 (A.5.15-17 Identitätsverwaltung) und BSI IT-Grundschutz (ORP.4). SSO-Authentifizierungs-Logs bieten zentralisierte Aufzeichnungen für GDPR-Artikel-30-Verarbeitungsdokumentation und Incident-Response.\n\n\n## Implementierung\n\n\nDie Konfiguration von GitLab Single Sign-On mit SAML und SCIM erfordert:\n\n\n- Azure Entra ID Tenant mit Administrator-Zugriff\n\n- GitLab Premium oder Ultimate mit Top-Level-Gruppe\n\n- Konfiguration auf beiden Plattformen (Parameter-Austausch, Attribut-Mappings, SCIM-Token)\n\n\n**Vollständige Schritt-für-Schritt-Anleitung:**\n\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\n- 15 detaillierte UI-Screenshots für Azure Entra ID und GitLab\n\n- Vollständige Attribut-Mapping-Tabellen (SAML Claims, SCIM Provisioning)\n\n- Parameter-Austausch zwischen Plattformen (Identifier, Reply URL, Certificate, SCIM Token)\n\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\n- [The ultimate guide to enabling SAML and SSO on GitLab.com](https://about.gitlab.com/blog/the-ultimate-guide-to-enabling-saml/)\n\n- [SAML SSO for GitLab.com groups documentation](https://docs.gitlab.com/ee/user/group/saml_sso/)\n",{"slug":708,"featured":32,"template":13},"how-to-gitlab-single-sign-on-with-saml-scim-and-azures-entra-id",{"promotions":710},[711,725,737],{"id":712,"categories":713,"header":715,"text":716,"button":717,"image":722},"ai-modernization",[714],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":718,"config":719},"Get your AI maturity score",{"href":720,"dataGaName":721,"dataGaLocation":244},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":723},{"src":724},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":726,"categories":727,"header":729,"text":716,"button":730,"image":734},"devops-modernization",[26,728],"devsecops","Are you just managing tools or shipping innovation?",{"text":731,"config":732},"Get your DevOps maturity score",{"href":733,"dataGaName":721,"dataGaLocation":244},"/assessments/devops-modernization-assessment/",{"config":735},{"src":736},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":738,"categories":739,"header":740,"text":716,"button":741,"image":745},"security-modernization",[9],"Are you trading speed for security?",{"text":742,"config":743},"Get your security maturity score",{"href":744,"dataGaName":721,"dataGaLocation":244},"/assessments/security-modernization-assessment/",{"config":746},{"src":747},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":749,"blurb":750,"button":751,"secondaryButton":756},"Beginne noch heute, schneller zu entwickeln","Entdecke, was dein Team mit der intelligenten Orchestrierungsplattform für DevSecOps erreichen kann.\n",{"text":752,"config":753},"Kostenlosen Test starten",{"href":754,"dataGaName":50,"dataGaLocation":755},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":52,"config":757},{"href":54,"dataGaName":55,"dataGaLocation":755},1772652053394]