Compliance-Frameworks einrichten: Vorlagen für SOC 2, ISO 27001, NIS 2 und TISAX

Compliance gilt in der Softwareentwicklung als wichtig und ist zugleich wenig beliebt. Dokumentiert wird sie meist in Tabellen und Screenshots — und meist erst dann, wenn ein Audit ansteht. Die Custom Compliance Frameworks von GitLab setzen anders an: Statt zu dokumentieren, was auf ein Projekt zutreffen sollte, definierst du die Kontrollen einmal und lässt die Plattform laufend prüfen, was tatsächlich zutrifft.

Dieser Artikel zeigt, warum die Einhaltung von Compliance-Vorgaben wichtig ist, wie sich ein SOC-2-Framework über eine Vorlage einrichten lässt, wie die Einhaltung laufend beobachtet wird, wie Policies Compliance durchsetzen und welche Standards bereits als fertige Vorlagen bereitstehen. Dazu kommt ein Ausblick auf Vorlagen für KI-spezifische Anforderungen. Im folgenden Video ist das Vorgehen zu sehen:

Tier-Hinweis: Compliance Frameworks stehen in Premium und Ultimate zur Verfügung. Framework-Anforderungen und Kontrollen erfordern Ultimate. Das betrifft die Prüfungen, auf denen die Berichte zur Einhaltung und der Compliance-Statusbericht beruhen. Alle Angaben gelten für GitLab.com, GitLab Self-Managed und GitLab Dedicated.

Warum die Einhaltung wichtig ist und was Custom Compliance Frameworks leisten

Regulatorische und vertragliche Anforderungen wie ISO 27001, SOC 2, NIS 2, DORA oder FedRAMP bestehen, weil Kundschaft, Partner und Aufsichtsbehörden die Gewissheit brauchen, dass Software verantwortungsvoll entwickelt und ausgeliefert wird. Werden die Anforderungen nicht erfüllt, bleibt es nicht bei einem Dokumentationsproblem: Abschlüsse können scheitern, Bußgelder anfallen, Produkteinführungen sich verzögern und Vertrauen verloren gehen. Compliance ist zudem kein einmaliges Ereignis. Ein Projekt, das zum Zeitpunkt des Audits alle Anforderungen erfüllt hat, weicht bereits ab, sobald jemand einen Scanner deaktiviert, den Schutz eines Branches aufhebt oder ohne die erforderlichen Freigaben mergt.

Genau diese Lücke schließen Custom Compliance Frameworks. Ein Compliance Framework ist in GitLab ein Label, das auf einer Gruppe der obersten Ebene angelegt wird und Projekte kennzeichnet, für die bestimmte Compliance-Vorgaben gelten oder die zusätzliche Aufsicht brauchen. Für sich genommen sorgt dieses Label für Ordnung und Sichtbarkeit. In Ultimate kann ein Framework zusätzlich Anforderungen tragen, die wiederum aus Kontrollen bestehen. Kontrollen sind automatisierte Prüfungen der Konfiguration und des Verhaltens jedes Projekts, dem das Framework zugewiesen ist.

Statt eine Person aus dem Entwicklungsteam bestätigen zu lassen, dass SAST läuft, dass der Standard-Branch geschützt ist und dass Merge Requests zwei Freigaben benötigen, prüft GitLab diese Bedingungen automatisch — nach Zeitplan und immer dann, wenn sich relevante Projekteinstellungen ändern. Compliance ist damit keine Momentaufnahme mehr, die vor einem Audit zusammengestellt wird, sondern ein Zustand, der sich ganzjährig beobachten lässt. Frameworks werden auf der Gruppe der obersten Ebene angelegt und von allen darunterliegenden Untergruppen und Projekten geerbt. Einem einzelnen Projekt lassen sich bis zu 20 Frameworks zuweisen, wenn es mehrere Standards gleichzeitig erfüllen muss.

Für die tägliche Arbeit ändert sich dadurch mehreres. Compliance rückt nach vorne in den Entwicklungsprozess, die Auditvorbereitung besteht für die abgedeckten Kontrollen im Export eines Berichts statt im Rekonstruieren von Nachweisen, und für Konsistenz sorgt die Plattform statt guter Vorsätze.

Ein SOC-2-Framework über eine Vorlage einrichten

Ein Framework von Hand aufzubauen bedeutet, jede Anforderung und jede Kontrolle einzeln zu definieren. Bei einem Standard wie SOC 2, der auf viele Kontrollen abbildet, ist das repetitiv und fehleranfällig. Vorlagen lösen das. Eine Vorlage liefert ein vollständiges, vordefiniertes Framework, in dem Name, Beschreibung, Farbe, Anforderungen und Kontrollen bereits konfiguriert sind und das sich in einem Schritt übernehmen lässt.

Das Projekt Compliance Adherence Templates enthält eine Bibliothek solcher Frameworks als JSON-Dateien, darunter soc2.json.

Es gibt zwei Wege, eine Vorlage in die eigene Gruppe zu übernehmen.

Option A: Framework aus einer Vorlage im Compliance center erstellen

Ein Framework lässt sich direkt aus einer integrierten Vorlage erstellen, ohne die Oberfläche zu verlassen:

1. Zur eigenen Gruppe der obersten Ebene wechseln.
2. In der Seitenleiste Secure > Compliance center auswählen.
3. Auf die Schaltfläche New framework klicken.
4. Create from template wählen.
5. Zur Vorlage SOC 2 scrollen und View details auswählen, um die enthaltenen Kontrollen zu sehen.
6. Mit Use template die SOC-2-Vorlage übernehmen. Name, Beschreibung und Farbe lassen sich dabei anpassen. Anschließend Next auswählen.
7. Die enthaltenen Anforderungen und Kontrollen prüfen.
8. Das Framework den Gruppen bzw. Projekten zuweisen, die es benötigen.
9. Auf Create framework klicken.

Das Framework ist damit angelegt und wird auf die ausgewählten Gruppen bzw. Projekte angewendet.

Option B: Die SOC-2-Vorlage als JSON importieren

Wenn die eingesetzte GitLab-Version die Vorlagenauswahl im Produkt noch nicht enthält oder die Vorlage zunächst versioniert und angepasst werden soll, lässt sich das JSON direkt importieren:

1. Im Projekt Compliance Adherence Templates die Datei soc2.json herunterladen.
2. Zur eigenen Gruppe der obersten Ebene wechseln.
3. Secure > Compliance center auswählen.
4. Im Tab Frameworks zuerst New framework und dann Import framework auswählen.
5. Die Datei soc2.json vom lokalen System auswählen.
6. Nach erfolgreichem Import erscheint das SOC-2-Framework in der Framework-Liste.

Ein Framework wird erst wirksam, sobald es Projekten zugewiesen ist. Deshalb sollte es den Gruppen bzw. Projekten zugewiesen werden, in denen es gelten soll.

Hinweis: Der Import schlägt mit der Fehlermeldung Unable to determine the correct upload URL fehl, wenn bereits ein Framework mit demselben Namen existiert. Das vorhandene Framework muss zuvor umbenannt oder entfernt werden.

Das Framework bearbeiten und weiteren Projekten zuweisen

Das neu erstellte Framework lässt sich anschließend bearbeiten und weiteren Gruppen bzw. Projekten zuweisen:

1. In Secure > Compliance center den Tab Frameworks öffnen.
2. Mit dem Mauszeiger über das SOC-2-Framework fahren und Edit Framework auswählen.
3. Im Abschnitt Requirements & Controls unter Action über ... den Eintrag Edit auswählen.
4. Die gewünschten Änderungen an den Anforderungen oder Kontrollen vornehmen.
5. Im Abschnitt Scoping die Gruppen bzw. Projekte auswählen, die unter SOC 2 fallen.
6. Update Framework auswählen.

Soll jedes neue Projekt der Gruppe SOC 2 automatisch erben, lässt sich das Framework im Abschnitt Basic information als default der Gruppe festlegen. Es wird dann auf alle künftig erstellten und importierten Projekte angewendet.

Was die SOC-2-Vorlage tatsächlich prüft

Einmal zugewiesen, ordnet das SOC-2-Framework GitLab-Kontrollen den jeweiligen Trust Services Criteria zu. Einige Beispiele:

Sobald das Framework einem Projekt zugewiesen ist, führt GitLab einen Compliance-Scan aus und berichtet fortlaufend, ob die einzelnen Kontrollen erfüllt sind. Für die abgedeckten Kontrollen entfällt damit die manuelle Zusammenstellung von Nachweisen.

Den Compliance-Status laufend im Blick behalten

Ein Framework zuzuweisen ist nur die halbe Arbeit. Die andere Hälfte besteht darin, jederzeit zu wissen, wo das Unternehmen steht. Dafür gibt es den Compliance-Statusbericht (Ultimate), zu finden in der Gruppe der obersten Ebene unter Secure > Compliance center > Status.

Der Bericht zeigt die jüngsten Fälle, in denen Projekte die Kontrollen eines Frameworks erfüllen oder nicht erfüllen. Lücken lassen sich so schnell erkennen und schließen. Jede Zeile enthält:

• Status: ob eine Anforderung erfüllt ist oder nicht
• Requirement: die konkreten Kontrollen einer Anforderung, die fehlgeschlagen sind (zum Beispiel „At least two approvals“)
• Framework: zu welchem Framework die Kontrolle gehört (zum Beispiel SOC 2)
• Project: wo die Abweichung gefunden wurde
• Last Scanned: wann die Lücke erstmals erfasst wurde
• Fix Suggestions: Hinweise zur Behebung

Der Bericht lässt sich nach Projekt, Framework oder Anforderung filtern. Von dort führt der Weg direkt in die Compliance-Detailansicht eines Projekts. Der gesamte Bericht lässt sich exportieren und wird als Anhang per E-Mail zugestellt, wenn Prüfende Nachweise anfordern.

Im Hintergrund starten die Scans, die den Bericht aktualisieren, automatisch: wenn einem Projekt ein Framework zugewiesen wird, wenn sich die Anforderungen eines zugewiesenen Frameworks ändern und zusätzlich in einem festen 12-Stunden-Takt. Ergebnisse liegen in der Regel fünf bis zehn Minuten nach einem Scan vor. Abweichungen werden dadurch innerhalb weniger Stunden sichtbar und nicht erst beim nächsten jährlichen Audit. Für den Zugriff auf den Bericht ist die Administratorrolle oder die Rolle Security Manager oder Owner für die Gruppe erforderlich.

Compliance über Policies durchsetzen

Berichte zeigen, wenn etwas nicht stimmt. Policies verhindern, dass es überhaupt dazu kommt. An dieser Stelle gehen Compliance Frameworks von der Beobachtung in die Durchsetzung über. Diese Funktion gehört zu Ultimate und ist an das Framework-Label gebunden.

Ein Compliance Framework kann als Geltungsbereich für Security Policies dienen. Scan Execution Policies, Pipeline Execution Policies und Merge Request Approval Policies lassen sich auf ein Compliance Framework beziehen. Jedes Projekt mit diesem Label erbt sie dann automatisch. So lässt sich beispielsweise festlegen, dass SAST, Secret Detection und Dependency Scanning auf dem Standard-Branch laufen und dass ein benanntes Sicherheitsteam zustimmen muss, bevor ein Merge Request mit neuen kritischen Schwachstellen gemergt werden darf. Da die Policy am Framework hängt und nicht an einzelnen Projekten, gelten für ein neu hinzugefügtes Projekt sofort dieselben Leitplanken.

Die Teile greifen ineinander. Das Framework definiert die Verpflichtung, Kontrollen und der Statusbericht messen die Einhaltung, Policies und Compliance-Pipelines setzen das Verhalten durch. Dokumentiert wird damit nicht nur, dass SOC 2 zwei Freigaben und laufende Scanner verlangt. Es wird zugleich schwer, etwas auszuliefern, das diese Anforderungen verletzt. Schlägt eine Kontrolle fehl, weist der Statusbericht darauf hin. Greift eine Policy, wird die abweichende Änderung blockiert, bevor sie gemergt wird.

Verfügbare Vorlagen

GitLab pflegt im Projekt Compliance Adherence Templates eine wachsende Bibliothek vordefinierter Framework-Vorlagen. Jede bildet einen anerkannten Standard auf GitLab-Kontrollen ab. Zum Zeitpunkt der Veröffentlichung sind das:

Welche Anforderung auf welche Kontrolle abgebildet wird, ist in der Referenz Compliance-Standards dokumentiert. Jede Vorlage lässt sich unverändert importieren oder als Ausgangspunkt nutzen: das Framework als JSON exportieren, Anforderungen und Kontrollen an die eigene Auslegung des Standards anpassen und wieder importieren. Das JSON-Schema ist überschaubar. Ein Framework hat name, description, color und ein Array requirements, das jeweils eigene controls und einen Ausdruck expression zur Auswertung enthält. Vorlagen lassen sich dadurch versionieren und gruppenübergreifend teilen.

Ausblick: Compliance-Vorlagen für KI

Die heute abgedeckten Compliance-Standards wurden überwiegend für klassische Software geschrieben. Da Unternehmen KI in ihre Produkte und in die eigene Entwicklung einbinden, entsteht eine neue Klasse von Anforderungen daran, wie KI-Systeme entwickelt, freigegeben und überwacht werden. Beispiele sind der EU AI Act, ISO/IEC 42001 und das NIST AI Risk Management Framework.

GitLab prüft derzeit Compliance-Vorlagen für KI-Governance (Epic #16808, Planung in Work item #22336), um dasselbe auf Vorlagen gestützte Modell auf diesen Bereich auszuweiten. Die Absicht dahinter: Ein KI-Governance-Framework soll sich ebenso einfach übernehmen lassen wie heute SOC 2 — mit vordefinierten Anforderungen und Kontrollen für KI-spezifische Vorgaben, angewendet auf die Projekte, die KI-Funktionen entwickeln oder bereitstellen, und sichtbar im selben Compliance-Statusbericht.

Eine Unterscheidung lohnt sich dabei. Compliance ist der Zustand, in dem ein definierter Satz von Anforderungen erfüllt ist. Governance ist die dauerhafte Fähigkeit, KI-Systeme auch dann konform zu halten, wenn sich sowohl die Systeme als auch die Regeln weiterentwickeln. GitLab verbindet dabei KI-gestützte Erkennung mit menschlicher Freigabe und mit einer nachvollziehbaren, richtlinienbasierten Durchsetzung. KI-Ergebnisse fließen in Entscheidungen ein, doch die Freigabepunkte vor der Auslieferung bleiben bei verantwortlichen Personen und messbaren Kontrollen. KI-spezifische Vorlagen wären der Einstieg dazu: Neue KI-Anforderungen ließen sich damit in denselben Apparat aus Framework, Kontrollen, Statusbericht und Policies überführen, der bereits für alles andere genutzt wird.

Fazit

Mit Custom Compliance Frameworks werden die eigenen Verpflichtungen einmal definiert und anschließend laufend von GitLab geprüft. Vorlagen nehmen die manuelle Einrichtung ab: Ein SOC-2-Framework entsteht über wenige Schritte in der Oberfläche oder über einen einzigen JSON-Import. Der Compliance-Statusbericht hält die Einhaltung im 12-Stunden-Takt sichtbar, Security Policies und Compliance-Pipelines machen aus dieser Sichtbarkeit eine Durchsetzung. Mit der vorhandenen Bibliothek an Standards und dem Ausblick auf KI-spezifische Vorlagen ist der Weg von „wir sollten konform sein“ zu „wir können die Einhaltung laufend nachweisen“ kürzer geworden.

Mehr dazu in der Dokumentation zu Compliance Frameworks sowie in der interaktiven Demo zu Custom Compliance Frameworks.

Dieser Blogbeitrag enthält „zukunftsgerichtete Aussagen“ im Sinne von Section 27A des Securities Act von 1933 in der jeweils geltenden Fassung sowie von Section 21E des Securities Exchange Act von 1934. Auch wenn wir die darin zum Ausdruck gebrachten Erwartungen für angemessen halten, unterliegen diese bekannten und unbekannten Risiken, Unsicherheiten, Annahmen und weiteren Faktoren, die dazu führen können, dass die tatsächlichen Ergebnisse wesentlich abweichen. Weitere Informationen zu diesen Risiken und anderen Faktoren finden sich unter der Überschrift „Risk Factors“ in unseren Einreichungen bei der SEC. Wir übernehmen keine Verpflichtung, diese Aussagen nach dem Datum dieses Blogbeitrags zu aktualisieren oder zu korrigieren, sofern dies nicht gesetzlich vorgeschrieben ist.