Mit Claude und GitLab jeden Commit bis zur Produktion absichern

Agentisches Coding zieht davon, während viele Governance-Programme in Unternehmen nicht mithalten können. Coding-Assistenten wie das Claude security guidance plugin und Claude Security markieren und beheben verbreitete Schwachstellen bereits beim Schreiben, in derselben Session. Für sichereren Code ist das wertvoll, doch dort endet Sicherheit nicht. Ein Commit ist eine Etappe auf dem Weg in die Produktion: Merges, Abhängigkeits-Updates, Infrastrukturänderungen und Audits folgen erst, nachdem die Session beendet ist.

GitLab deckt den restlichen Weg in die Produktion ab. Im typischen Sicherheits-Workflow von Anthropics Claude zu GitLab gibt es fünf Übergaben. Dieser Artikel geht jede einzelne davon durch und zeigt, wie sich agentisches Coding im großen Maßstab steuern lässt.

Teams, die Claude security guidance und Claude Security bereits nutzen, können diesen Kontext über den GitLab-MCP-Server direkt in GitLab einspeisen und ihren bestehenden Workflow beibehalten. Claude übernimmt den Moment des Schreibens, GitLab alles von dort bis in die Produktion, auf einer Plattform.

Von markierten Findings zu durchgesetzten Kontrollen

Das Claude security guidance plugin prüft Code innerhalb der Session einer einzelnen entwickelnden Person und erkennt Probleme, während der Agent weiterarbeitet. Sobald dieser Code die Session verlässt, brauchen Security-Teams eine Aufzeichnung dessen, was darin geschah, und Kontrolle darüber, was als Nächstes passiert.

GitLab gibt Teams die Sichtbarkeit und die Kontrolle, um Guardrails für sicheres Coding zu definieren, bevor Code die Produktion erreicht, unabhängig davon, wo er entstanden ist.

• Kontrollen einmal definieren, überall durchsetzen: Security Configuration Profiles wenden die erforderlichen Scans über jedes Projekt und jede Pipeline hinweg an, von außerhalb des Repositorys, sodass die Abdeckung konsistent ist und sich nicht umgehen lässt.
• Funktionstrennung durchsetzen, auch für Agenten: Merge-Request-Approval-Policies stellen sicher, dass der Agent, der eine Änderung geschrieben hat, sie nicht selbst freigeben kann. Weder der Agent noch die Person, die ihn beauftragt hat, kann die eigene Arbeit ohne benannte freigebende Person mergen.
• Kritische Schwachstellen vor dem Ausliefern blockieren: Merge-Request-Approval-Policies halten jeden Merge mit ungelösten kritischen Findings zurück, bis eine benannte Person freigibt, sodass verworfene oder übersehene Schwachstellen nicht unbemerkt in die Produktion gelangen.
• Den Status jedes Findings dauerhaft verfolgen: Vulnerability Report und Security Dashboard zeigen, ob ein Finding erkannt, mit Begründung verworfen oder behoben wurde.

Scanner über jedes Projekt im Geltungsbereich hinweg aktivieren, ohne Möglichkeit sie zu umgehen

Vom Scan in der Session zum Audit-Nachweis

Audit-Anforderungen im Change-Management werden auf Agenten ausgeweitet. Compliance-Frameworks wie SOC 2, PCI DSS und FedRAMP verlangen dokumentierte Nachweise, dass jede Änderung getestet, reviewt und freigegeben wurde, bevor sie ausgeliefert wurde.

GitLab macht Compliance-Kontrollen durchsetzbar und die Sammlung von Nachweisen für Auditoren automatisch.

• Belegen, dass Scan und Review stattgefunden haben: Compliance Controls garantieren, dass bei jedem Merge Request ein Scan läuft und jedes Finding im Merge Request und im Vulnerability Report auftaucht, sichtbar für einen Menschen.
• Auditoren nachvollziehbar antworten: Pipeline-Logs, Freigabe-Nachweise und Audit-Events liefern eine reproduzierbare Historie darüber, was gescannt wurde und wer freigegeben hat, Änderung für Änderung, verknüpft mit den beteiligten Menschen und Agenten.
• Nachweise dem angefragten Framework zuordnen: Compliance Frameworks gruppieren Nachweise in benannte Anforderungen, etwa SOC 2 oder ein eigenes Framework, jeweils aus konkreten Kontrollen aufgebaut, und der Compliance-Status-Report zeigt pro Framework, welche Kontrollen bestanden haben, ausstehen oder fehlgeschlagen sind.

Audit-Log der Agenten-Aktivität mit Ereignissen auf Session-Ebene und Startzeiten

Steuern, welche sensiblen Daten gesendet werden

An ein Modell geht zur Prüfung vermutlich mehr Code samt dem Geschäftskontext darum herum als an einen Menschen. Regulierte Branchen, Behörden und Teams mit sensiblem geistigem Eigentum müssen entscheiden, was ihre Umgebung verlässt, etwa Zugangsdaten, proprietäre Logik und regulierte Daten. Diese Entscheidung muss fallen, bevor irgendein Scan läuft, und für jedes Werkzeug gelten, das den Code berührt.

Mit GitLab lässt sich festlegen, welche Daten ein Modell erreichen, noch bevor sie die eigene Umgebung verlassen.

• Secrets und sensiblen Code von Modellen fernhalten: Kontext-Ausschlüsse halten Secrets und sensible Dateien aus allem zurück, was ein Agent an Modelle sendet.
• Code und Inferenz innerhalb der eigenen Grenze halten, auf freigegebenen Modellen: Eine self-managed Umgebung mit self-hosted Modellen betreiben, damit nichts die eigene Umgebung verlässt. Das Modell pro Flow auswählen, einschränken, welche Modelle zulässig sind, und den eigenen Code aus dem Training halten.
• Filtern, was gesendet wird: Die Prompt-Guardrails von GitLab Duo prüfen Code-Vorschläge auf Secrets, bevor sie ein Modell erreichen, und isolieren die Inhalte, auf die ein Prompt wirken kann, um das Risiko von Prompt Injection zu senken, zusätzlich zu allem, was ohnehin schon ausgeschlossen ist.

Festlegen, welche Dateien oder Verzeichnisse nicht an KI-Modelle gesendet werden

Von einem Scan zu vollständiger Scan-Abdeckung über den Entwicklungszyklus

Anthropics Dokumentation stellt ausdrücklich klar, dass das Claude security guidance plugin ein unterstützendes Werkzeug nach dem Best-Effort-Prinzip ist, gedacht neben menschlichem Code-Review und verschiedenen Security-Scannern, nicht als Ersatz dafür. Diese Einordnung verdient Aufmerksamkeit, denn manche Schwachstellen existieren zum Zeitpunkt des Auslieferns noch nicht. Eine Abhängigkeit, die heute ausgeliefert wird, kann im nächsten Jahr eine kritische Schwachstelle gemeldet bekommen, ohne jede Änderung am eigenen Code. Log4Shell ist das deutlichste Beispiel: Anwendungen, die Jahre früher ausgeliefert worden waren, wurden in dem Moment angreifbar, in dem die Schwachstelle im Dezember 2021 öffentlich bekannt wurde.

Abhängigkeiten, Container-Images, Infrastrukturkonfiguration und Secrets, die längst in der Commit-Historie liegen, brauchen Scans, die unabhängig von einer einzelnen Session laufen.

GitLab sichert den gesamten Software-Delivery-Lebenszyklus ab.

• Die gesamte Angriffsfläche abdecken: Scans für Abhängigkeiten, Container, Infrastructure as Code, Secrets und dynamische Anwendungssicherheitstests (DAST) prüfen die Teile einer Anwendung, die ein sessionbasiertes Review nie erreicht: die eingebundenen Abhängigkeiten, die ausgelieferten Images, die bereitgestellte Infrastruktur, die in Commits geratenen Secrets und die laufende Anwendung.
• Die Fehler finden, die Scannern entgehen können: Deterministische Scanner können Fehler in der Geschäftslogik, fehlerhafte Autorisierung oder Race Conditions nicht erkennen. Security Review Flow schließt aus der Absicht auf genau diese Kategorie und hinterlässt Kommentare am betroffenen Code, auf die ein Mensch reagieren kann.
• Einen deterministischen Scan haben, dessen Ergebnisse nicht driften: Ein LLM-basiertes Review kann bei identischem Code von Durchlauf zu Durchlauf unterschiedliche Findings liefern. Ein deterministischer Scan wie advanced SAST verfolgt verunreinigte Daten mit einem festen Algorithmus über Funktionsgrenzen hinweg und liefert reproduzierbare, CWE-zugeordnete Ergebnisse, also die konsistenten Nachweise, die ein Compliance-Audit braucht.

SAST, DAST sowie Abhängigkeits-, Container- und Secret-Scans verpflichtend in der Pipeline

Ein Satz Guardrails für jeden Agenten und jede entwickelnde Person

Das Claude security guidance plugin prüft den Code, den Claude innerhalb einer Session schreibt und committet. Commits aus der eigenen Shell, einschließlich des Shell-Escapes "!" innerhalb einer Session, liegen außerhalb dessen, was das Plugin prüft. Claude Security erweitert das auf Anfrage auf eine vollständige Codebasis oder auf von Menschen geschriebenen Code, wenn eine entwickelnde oder administrierende Person es ausführt.

GitLabs Scan-Execution- und Merge-Request-Approval-Policies laufen in der Pipeline für jede Änderung. Die Abdeckung hängt damit nicht davon ab, ob ein Mensch oder ein Agent den Code geschrieben hat oder ob daran gedacht wurde, einen Scan zu starten.

Sicherheits-Scans so konfigurieren, dass sie auf jedem Standard-Branch laufen

Steuern, was ausgeliefert wird

Claude security guidance und Claude Security helfen Entwickelnden, Probleme im Moment des Schreibens zu erkennen und zu beheben. Sobald dieser Code die Session verlässt, sind Security- und Platform-Teams im Unternehmen dafür verantwortlich, ihn sicher in die Produktion zu bringen. Sie brauchen Sichtbarkeit darüber, was ein Agent getan hat, Nachweise, dass Sicherheitsverfahren eingehalten wurden, und die Möglichkeit, eine problematische Änderung vor dem Ausliefern zu stoppen.

GitLab schlägt die Brücke zum Claude-Workflow. Guardrails werden einmal in GitLab gesetzt, und jeder Agent und jede entwickelnde Person liefert innerhalb dieser Guardrails sicherer aus. Claude hilft dabei, sicheren Code zu schreiben. GitLab steuert alles von dort bis in die Produktion.

Jetzt eine kostenlose Testversion von GitLab Ultimate starten

Ultimate bereits im Einsatz? Scan-Execution- und Merge-Request-Approval-Policies einrichten und Guardrails ab heute durchsetzen.