KI erkennt Schwachstellen – aber wer verantwortet das Risiko?

Anthropic hat kürzlich Claude Code Security angekündigt – ein KI-System, das Schwachstellen erkennt und Korrekturen vorschlägt. Die Reaktion der Märkte folgte prompt: Die Aktien von Cybersecurity-Unternehmen gaben nach, als Investoren begannen, die Zukunft klassischer AppSec-Tools in Frage zu stellen. Die Frage, die viele beschäftigt: Wenn KI Code schreiben und absichern kann, wird Anwendungssicherheit dann überflüssig?

Wenn Sicherheit nur das Scannen von Code bedeutete, wäre die Antwort vielleicht ja. Aber Enterprise-Sicherheit war noch nie auf Erkennung allein ausgerichtet.

Unternehmen fragen nicht, ob KI Schwachstellen finden kann. Sie stellen drei weitaus schwieriger zu beantwortende Fragen:

• Ist das, was wir ausliefern wollen, sicher?
• Hat sich unsere Risikolage verändert, während sich Umgebungen, Abhängigkeiten, Drittanbieter-Services, Tools und Infrastruktur kontinuierlich wandeln?
• Wie lässt sich eine Codebasis steuern, die zunehmend von KI und Drittquellen zusammengestellt wird – für die wir aber weiterhin verantwortlich sind?

Diese Fragen erfordern eine Plattformantwort: Erkennung macht Risiken sichtbar, aber Governance bestimmt, was als nächstes passiert.

GitLab ist die Orchestrierungsschicht, die den Software-Lebenszyklus durchgängig steuert und Teams die Durchsetzung, Transparenz und Nachvollziehbarkeit gibt, die sie brauchen, um mit der Geschwindigkeit KI-gestützter Entwicklung Schritt zu halten.

KI vertrauen erfordert Governance

KI-Systeme werden zunehmend besser darin, Schwachstellen zu identifizieren und Korrekturen vorzuschlagen. Das ist ein bedeutender Fortschritt – aber Analyse ist keine Verantwortung.

KI kann Unternehmensrichtlinien nicht eigenständig durchsetzen oder akzeptables Risiko definieren. Menschen müssen die Grenzen, Richtlinien und Leitplanken festlegen, innerhalb derer Agenten operieren: Funktionstrennung sicherstellen, Audit-Trails gewährleisten und konsistente Kontrollen über Tausende von Repositories und Teams hinweg aufrechterhalten. Vertrauen in Agenten entsteht nicht durch Autonomie allein, sondern durch klar definierte Governance durch Menschen.

In einer agentischen Welt, in der Software zunehmend von autonomen Systemen geschrieben und verändert wird, wird Governance wichtiger, nicht unwichtiger. Je mehr Autonomie Unternehmen KI gewähren, desto stärker muss die Governance sein.

Governance ist keine Bremse. Sie ist das Fundament, das KI-gestützte Entwicklung im Unternehmensmaßstab vertrauenswürdig macht.

LLMs sehen Code, Plattformen sehen Kontext

Ein Large Language Model (LLM) bewertet Code isoliert. Eine Enterprise Application Security-Plattform versteht Kontext. Dieser Unterschied ist entscheidend, weil Risikoentscheidungen kontextabhängig sind:

• Wer hat die Änderung vorgenommen?
• Wie kritisch ist die Anwendung für das Unternehmen?
• Wie interagiert sie mit Infrastruktur und Abhängigkeiten?
• Liegt die Schwachstelle in Code, der tatsächlich in der Produktion erreichbar ist, oder in einer Abhängigkeit, die nie ausgeführt wird?
• Ist sie in der Produktion tatsächlich ausnutzbar – angesichts der Art, wie die Anwendung läuft, ihrer APIs und der sie umgebenden Umgebung?

Sicherheitsentscheidungen hängen von diesem Kontext ab. Fehlt er, produziert Erkennung laute Alarme, die die Entwicklung verlangsamen, anstatt Risiken zu reduzieren. Mit ihm können Unternehmen schnell priorisieren und Risiken gezielt managen. Da sich Kontext mit jeder Softwareänderung weiterentwickelt, kann Governance keine einmalige Entscheidung sein.

Statische Scans halten mit dynamischem Risiko nicht Schritt

Software-Risiko ist dynamisch. Abhängigkeiten ändern sich, Umgebungen entwickeln sich, und Systeme interagieren auf Weisen, die keine einzelne Analyse vollständig vorhersehen kann. Ein sauberer Scan zu einem Zeitpunkt garantiert keine Sicherheit beim Release.

Enterprise-Sicherheit setzt auf kontinuierliche Absicherung: Kontrollen, die direkt in Entwicklungs-Workflows eingebettet sind und Risiken bewerten, während Software entwickelt, getestet und bereitgestellt wird.

Erkennung liefert Erkenntnisse. Governance schafft Vertrauen. Kontinuierliche Governance ermöglicht es Unternehmen, im Unternehmensmaßstab sicher auszuliefern.

Die agentische Zukunft steuern

KI verändert, wie Software entsteht. Die Frage lautet nicht mehr, ob Teams KI einsetzen werden, sondern wie sicher sie dabei skalieren können.

Software wird heute ebenso zusammengestellt wie geschrieben – aus KI-generiertem Code, Open-Source-Bibliotheken und Drittanbieter-Abhängigkeiten, die sich über Tausende von Projekten erstrecken. Zu steuern, was über all diese Quellen hinweg ausgeliefert wird, ist der anspruchsvollste Teil der Anwendungssicherheit – und jener, für den kein entwicklerseitiges Tool ausgelegt ist.

Als intelligente Orchestrierungsplattform ist GitLab darauf ausgerichtet, dieses Problem zu lösen. GitLab Ultimate bettet Governance, Richtliniendurchsetzung, Security Scanning und Nachvollziehbarkeit direkt in die Workflows ein, in denen Software geplant, entwickelt und ausgeliefert wird – damit Security-Teams im Tempo von KI steuern können.

KI wird die Entwicklung erheblich beschleunigen. Den größten Nutzen werden nicht die Unternehmen ziehen, die die leistungsfähigsten KI-Assistenten einsetzen, sondern jene, die Vertrauen durch starke Governance aufbauen.

Wie GitLab Unternehmen dabei hilft, KI-generierten Code zu steuern und sicher auszuliefern: Jetzt mit unserem Team sprechen.

Weiterführende Beiträge

• KI und DevOps für verbesserte Sicherheit integrieren
• Das GitLab KI-Sicherheits-Framework für Security-Verantwortliche
• KI-Sicherheit in GitLab mit Composite Identities verbessern

Für deutsche Unternehmen: Governance als regulatorische Anforderung

Die in diesem Beitrag beschriebenen Governance-Prinzipien adressieren Anforderungen, die regulierte Unternehmen in Deutschland unmittelbar betreffen könnten.

Die NIS-2-Richtlinie (umgesetzt durch das NIS2UmsuCG) verpflichtet betroffene Unternehmen zu Maßnahmen im Bereich Risikoanalyse und Informationssicherheit (Artikel 21 Abs. 2 lit. a), Incident-Handling (Artikel 21 Abs. 2 lit. b) sowie zur Sicherheit in der Software-Lieferkette (Artikel 21 Abs. 2 lit. d) und bei der sicheren Entwicklung (Artikel 21 Abs. 2 lit. e). Die hier beschriebene Unterscheidung zwischen Erkennung und Governance spiegelt genau diese regulatorische Logik wider: Schwachstellen zu finden reicht nicht – entscheidend ist, wer die Reaktion darauf steuert, dokumentiert und verantwortet.

ISO 27001 adressiert ähnliche Anforderungen: Zugriffskontrolle (A.5.15–18), Logging und Monitoring (A.8.15–16), Schwachstellenmanagement (A.8.8) sowie Änderungsmanagement (A.8.32) setzen voraus, dass Governance-Prozesse in Entwicklungs-Workflows eingebettet sind – nicht nachgelagert.

Für Unternehmen in regulierten Branchen wie Finanzdienstleistungen (BaFin BAIT §6–7), Automotive (TISAX) oder kritischer Infrastruktur (BSI KRITIS) könnten diese Anforderungen besonders relevant sein. Für konkrete Compliance-Anforderungen empfiehlt sich Rücksprache mit entsprechender Fachberatung.