Die Software Factory maschinenschnell sichern

Ich bin zu GitLab in einem Moment rasanten Wandels gestoßen: Teams verändern gerade grundlegend, wie sie Software bauen und absichern. GitLab-CEO Bill Staples hat diesen Wandel kürzlich in Wenn Code im Überfluss vorhanden ist eingeordnet. Wenn Code nicht mehr der Engpass ist, wird Vertrauen zur Mangelware, und diese Einschränkung zeigt sich zuerst in dem, was tatsächlich in Produktion geht.

Als CISO trage ich dieselbe Verantwortung wie meine Kolleginnen und Kollegen, und meine Grundüberzeugung ist einfach: Agentische Softwareentwicklung bleibt nur vertrauenswürdig, wenn Sicherheit, Governance und Leitplanken den ganzen Weg von der Planung bis zur Produktion begleiten. Führungskräfte müssen die Angriffsfläche kontinuierlich kennen, die Ausführung einschränken und die Schleife von der Entdeckung bis zur verifizierten Behebung maschinenschnell schließen. Nicht die Zahl der Scans, Tickets oder Reviews ist die entscheidende Kennzahl, sondern die Zeit von der Erkennung zur verifizierten Behebung.

Diese Kennzahl gewinnt an Bedeutung, weil sich die Ökonomie eines Angriffs verändert. Die Risiken selbst sind bekannt: ein offener Server, eine zu weit gefasste Zugangsberechtigung oder ein exponierter Deployment-Pfad. KI-Modelle machen es schneller und günstiger, solche Bedingungen zu finden, zu verknüpfen und auszunutzen. Das beunruhigt mich mehr als ein neuartiger Zero-Day: Die Schwachstelle war längst in unserer Umgebung – geschützt hat uns bisher vor allem, wie aufwendig sie zu finden war.

Anthropic und OpenAI haben diesen Wandel beide öffentlich beschrieben, ebenso jedes Sicherheitsteam, mit dem ich dieses Jahr gesprochen habe, unabhängig von der Branche: Fortgeschrittene Modelle und agentische Systeme verkürzen Zeit und Kosten, die nötig sind, um Schwachstellen zu finden und auszunutzen. Open-Weight-Modelle holen gegenüber den leistungsfähigsten Sicherheitssystemen von heute rasch auf, was bedeutet, dass Fähigkeiten, die bis vor kurzem nur einer Handvoll Labore zur Verfügung standen, für einen deutlich größeren Kreis von Angreifern verfügbar werden.

Diese Beschleunigung sehe ich auch innerhalb von GitLab. Wir haben 2026 bereits 317 CVEs veröffentlicht, gegenüber 181 im gesamten Jahr 2025 und 170 im Jahr 2024. Unser Bug-Bounty-Programm erhielt in den letzten 90 Tagen knapp über 3.600 Meldungen, gegenüber 1.440 im gesamten Jahr 2024.

Derselbe Wandel, branchenweit

Wir sind kein Einzelfall. Im April hat das National Institute of Standards and Technology (NIST) aufgehört, die meisten CVEs anzureichern, und damit eingestanden, dass selbst ein Rekordjahr an Output nicht ausreichte. Der diesjährige Verizon Data Breach Investigations Report stufte die Ausnutzung von Schwachstellen erstmals in 19 Ausgaben vor Zugangsdatenmissbrauch als führenden Erstzugriffsvektor ein, bei einer mittleren Behebungsdauer, die von 32 auf 43 Tage gestiegen ist. Das Forum of Incident Response and Security Teams (FIRST) kam diesen Sommer zum selben Schluss.

Veröffentlichte Advisories und eingehende Meldungen messen unterschiedliche Dinge, erzeugen aber denselben operativen Druck: Das Entdeckungsvolumen wächst schneller, als Teams das Relevante prüfen, priorisieren und beheben können.

Schweregrad-Modelle gehen weiterhin davon aus, dass ein Fund isoliert steht, doch Agenten können eine geringschwere Schwachstelle, eine zu weit gefasste Berechtigung und einen exponierten Pfad zu einem materiellen Angriff verketten. Eine nach CVSS sortierte Warteschlange übersieht diesen Zusammenhang zunehmend, während der Rückstau schneller wächst, als Teams ihn mit klassischen Tools und Prozessen abbauen können.

Das Betriebsmodell muss sich mit der Ökonomie des Angriffs mitverändern. Sicherheitskontrollen müssen im Ausführungspfad selbst sitzen, mit einer geschlossenen Behebungsschleife hinter jedem materiellen Fund. Dieser geregelte Pfad über den gesamten Software Development Lifecycle (SDLC) hinweg ist das Fundament einer Software Factory im Unternehmensmaßstab – er verläuft unter den Leitplanken, im Kontext und in den Workflows des eigenen Unternehmens.

Agentische Fähigkeiten spielen den Verteidigern in die Hände

Sicherheitsteams waren schon immer in der Unterzahl, und unser eigener Zulauf läuft derzeit etwa sechsmal so hoch wie 2025. Aber leistungsfähige Modelle verändern die Rechnung zuerst zugunsten der Verteidigung.

Verteidiger haben Zugriff auf Code, Infrastruktur, Deployment-Pfade, Konfiguration, Identitätssysteme und den operativen Kontext. Richtet man dieselbe Fähigkeit auf dasselbe Ziel, zeigt sich deutlich mehr – vorausgesetzt, sie wird zuerst gegen die eigene Angriffsfläche eingesetzt. Modelle können diesen breiteren Kontext in maschinenschnelle Entdeckung, Priorisierung und Behebung verwandeln. Das war so noch nie zuvor möglich.

Auch der Build-Prozess selbst wird beobachtbar. Jahrelang war ein Großteil der Arbeit an einem Vorgang in keinem System erfasst, das Sicherheitsteams einsehen konnten. Sicherheitsteams prüften, was übrig blieb: den Diff, den Build und die laufende Anwendung.

Baut ein Agent Software, kann die Entstehung selbst zu einem Ereignisstrom werden: Dateizugriffe, Tool-Aufrufe, Befehle, ausgestellte Zugangsdaten, angesprochene Systeme und erteilte Freigaben. Diese Aufzeichnung macht es möglich, zu steuern, wie Software entsteht.

Dieser architektonische Vorteil besteht dort, wo Agenten in einer Umgebung laufen, in der sich ihre Aktionen identifizieren, einschränken und aufzeichnen lassen. Sobald diese Infrastruktur vorhanden ist, stärkt jede Verbesserung der Modellfähigkeiten das Verteidigungssystem.

Meines Erachtens braucht maschinenschnelle Verteidigung drei Ebenen, die mit steigender Modellfähigkeit und wachsendem Commit-Volumen über den gesamten SDLC hinweg stärker werden.

Ebene 1. Den eigenen Stand feststellen

Das ist der Entdeckungsdurchlauf für alles Weitere. Unter der Annahme, dass ein fähiger Angreifer bereits dieselben Modelle nutzt, sollten diese Modelle proaktiv gegen die eigene Angriffsfläche eingesetzt werden, über Code, Infrastruktur und Deployment-Pfade hinweg. Das Ziel ist ein verifiziertes Bild des aktuellen Stands.

Frontier-Labs sitzen der Fähigkeitskurve am nächsten, dort, wo neue KI-Modellfähigkeiten zuerst auftauchen, sowohl offensiv als auch defensiv. Ihr Beitrag hebt das Verteidigungsniveau an, auf dem der Rest der Branche aufbauen kann: modellgestützte Entdeckung, gerichtet auf reale Systeme, und Fixes, die von Agenten entworfen und vom eigenen Team freigegeben werden. Mit Anthropic betreiben wir das im Rahmen von Project Glasswing – wir setzen deren Modelle über unsere kritischen Systeme und Produkte hinweg ein und wiederholen den Durchlauf, sobald ein stärkeres Modell erscheint.

Anschließend nutzen wir GitLab Duo Agent Platform, um diese Funde kontinuierlich zu triagieren und zu beheben, die Entstehung neuer Probleme zu reduzieren und Software auszuliefern, die bereits vor der Produktion verifiziert wurde. Wir sind Kunde null für genau den Maßstab, den wir an die Softwarebranche anlegen – denn daraus soll Vertrauen in das erwachsen, was auf unserer Plattform entsteht.

Ebene 2. Das eigene Fundament stärken

Eine Baseline zeigt, wo man steht. Die schwierigere Aufgabe ist, sie zu halten, während Codevolumen, Agentenfähigkeit und Angreiferfähigkeit weiter zunehmen.

Dieses Fundament muss sechs Anforderungen erfüllen.

1. Die gesamte Angriffsfläche kennen und kontinuierlich scannen. Static Application Security Testing (SAST), Dependency-, Container-, Secret-, API- und Dynamic Application Security Testing (DAST) müssen als ein einziges Abdeckungsmodell laufen. Scanner von Drittanbietern müssen in ein gemeinsames Schwachstellenmanagement einspeisen. Eine Organisation kann Risiko nicht aus Teilinventaren mit unterschiedlichen Identitäten, Schweregraden, Angriffspfaden, Verantwortlichen und Behebungsständen bewerten.
2. Exponierte und langlebige Secrets eliminieren. Zentralisiertes Secrets-Management, minimale Berechtigungen, Rotation, Widerruf und Secret Detection müssen in den Pfaden, die Software erzeugen und bereitstellen, zum Standard gehören. Jedes Credential muss eine definierte Identität, einen Geltungsbereich, eine Lebensdauer und einen Widerrufspfad haben.
3. Aus Schwachstellenerkennung kontinuierliche Behebung machen. False Positives eliminieren, reale Schwachstellen im Kontext priorisieren und Agenten Fixes erzeugen, testen und validieren lassen. Ein Fund bleibt offen, bis die vorgeschlagene Änderung gegen den betroffenen Code, die Konfiguration und den Deployment-Pfad geprüft wurde.
4. Policy in den Ausführungspfad legen. Scans, Freigaben, Aufgabentrennung und Deployment-Kontrollen müssen zentral dort durchgesetzt werden, wo die Arbeit läuft. Entwickler(innen) und Agenten dürfen nicht dafür verantwortlich sein, sich zu merken, welche Policy gilt, oder die richtige Übergabe selbst zu finden.
5. Agenten als privilegierte Akteure behandeln. Jeder Agent braucht eine explizite Identität, minimale Berechtigungen, eingeschränkte Tools und Zugangsdaten, sanktionierte Zugriffspfade und auditierbare Aktionen. Risikoreiche Vorgänge brauchen eine zurechenbare Freigabegrenze, gerade weil Agenten zunehmend nicht nur Code vorschlagen, sondern über Repositories, CI/CD-Systeme, Cloud-Infrastruktur und Produktion hinweg handeln.
6. Die Zeit von der Erkennung zur verifizierten Behebung messen. Verfolgen, wie lange eine reale Schwachstelle von der Erkennung bis zu einem im relevanten Umfeld nachgewiesenen Fix exponiert bleibt. Nach Schweregrad und Angriffspfad segmentieren, dann kontinuierlich senken. Für maschinenschnelle Angriffe wird das zur zentralen operativen Kennzahl.

Diese Anforderungen greifen ineinander: durchgängige Abdeckung, damit Funde einen Weg haben, Fixes, die auf dem Pfad getestet werden, auf dem sie ausgeliefert werden, Policy dort, wo die Arbeit läuft, und Agenten mit eigener Identität statt des Zugriffstokens einer Entwicklerin oder eines Entwicklers.

Ebene 3. Bereits Ausgeliefertes schützen

Software und ihre Umgebung verändern sich auch nach der Produktion weiter. Das im letzten Monat ausgelieferte Artefakt kann durch eine Offenlegung im nächsten Monat verwundbar werden, wobei die Ausnutzung binnen Tagen folgt und mitunter sogar einem verfügbaren Patch vorausgeht.

Deshalb reicht es nicht, einmal aufzuholen: weiter scannen nach dem Merge, die Produktion neu bewerten, sobald stärkere Modelle erscheinen, und Fixes in demselben Entwicklerworkflow platzieren, der die Änderung erzeugt hat. Jeden Merge kontrollieren und jede Behebung zum Abschluss bringen, damit kein neuer Fund offen liegen bleibt.

Das Betriebsmodell besteht darin, die bereits vorhandene Sicherheit konsequent durchzusetzen, die Zeit von der Erkennung zur verifizierten Behebung zu messen und Prüfungen der Kundenerfahrung im selben Build-Pfad zu halten wie die Sicherheit.

WAS MEINE KOLLEG(INN)EN SAGEN

Cybersicherheitsexpert(inn)en und CISO-Kolleg(inn)en beschreiben einen ähnlichen operativen Ansatz, um Governance und Behebung im Tempo der Entwicklung zu ermöglichen.

"Entdeckung in maschinellem Maßstab ohne einen ebenso schnellen Weg zu geregelter Behebung ist kein Fortschritt. Es ist ein Inventarproblem im Sicherheits-Gewand. Die Organisationen, die der agentischen Entwicklung standhalten, sind die, die Erkennung als Anfang einer geschlossenen Schleife behandeln: Policy bei jeder Änderung, Behebung im Build-Pfad und eine Baseline, die sie erneut prüfen können, sobald Modelle besser werden." Gadi Evron, CISO-in-Residence for AI, Cloud Security Alliance

"Ein tragfähiges Sicherheitsprogramm für agentische Softwareentwicklung hält jeden Agenten auf geregelten Gleisen: eine klare Identität, eingeschränkte Berechtigungen und einen genehmigten Weg von der Planung bis zur Produktion. Ein Agent, der außerhalb dieser Gleise arbeitet, ist ungebunden: keine Identität, keine Aufzeichnung, keine Möglichkeit zu steuern, was er berührt hat. Diese Disziplin muss halten, während Modelle besser werden und das Agentenvolumen steigt." Bill Shields, CISO, Workday

"Vertrauen in das, was ausgeliefert wird, hängt von der kontinuierlichen Absicherung der Modelle und Entwicklungsplattformen ab, auf denen aufgebaut wird, und von der Governance jeder Änderung im Softwarelebenszyklus. Diese Ebenen verstärken sich gegenseitig, und keine ersetzt die andere." Sam Curry, Chief Security Officer, Zscaler

Die Software Factory im Schattenbetrieb ist ein architektonisches Problem

Während Agenten einen wachsenden Anteil des Codes erzeugen, teilt sich der SDLC in zwei Pfade. Ein Pfad läuft durch geregelte Repositories, CI/CD-Systeme, Identitätskontrollen, Freigaben und Sicherheitstools. Der Schattenpfad läuft über private Laptops, lokale Zugangsdaten, unverwaltete Tools und Agenten-Sessions außerhalb dieser Kontrollen. Er kann gültigen Code erzeugen, aber ohne verlässliche Aufzeichnung, wie dieser Code und die zugehörigen Infrastrukturänderungen entstanden sind.

Ein Commit zeigt, wessen Zugangsdaten verwendet wurden, verrät aber wenig über Agent, Tools, Berechtigungen, Befehle und externe Systeme hinter der Änderung. Diesen Nachweis zu erfassen, braucht eine geregelte Ausführungsumgebung, die Identität, Berechtigungen, Tools, Policy und Freigaben verbindet. Ohne sie prüfen Sicherheitsteams Artefakte erst, nachdem die entscheidenden Aktionen bereits geschehen sind.

Ereignisse zu erfassen ist erst der Anfang. Bei agentischem Volumen wird ein vollständiges Transkript selbst zu einem Rückstau. Sicherheitssysteme müssen diese Ereignisse in durchsetzbare Policy, zurechenbare Entscheidungen und verifizierte Ergebnisse verwandeln. Tool-Aufrufe sind Nachweise, die Erklärung eines Agenten für sein eigenes Vorgehen ist zweitrangig.

Wie das in der Praxis aussieht

Bei GitLab wird diese Architektur konkret. Policy sitzt im Ausführungspfad. Scanning läuft dort, wo Entwickler(innen) und Agenten bereits arbeiten, früh genug, dass der Fix günstig bleibt. Funde von Drittanbietern laufen in einem einzigen Schwachstellensystem zusammen, und Agenten verwandeln validierte Funde in geprüfte Merge Requests, die den nötigen Anwendungskontext für die Behebung mitbringen. Secrets sind standardmäßig kurzlebig, eingeschränkt und widerrufbar. Risikoreiche Agentenaktionen halten an einer zurechenbaren Freigabegrenze. Kann die Pipeline es nicht belegen, liefert die Pipeline es nicht aus.

Die Kapazität für Autorenschaft wird elastisch, während die Kapazität für menschliches Review begrenzt bleibt. Vor der Automatisierung erreichte menschliches Application-Security-Review etwa 1 % unserer Merge Requests. Bei einem aktuellen Release liefen agentische Sicherheitsreviews über 969 von 997 dafür infrage kommenden Merge Requests, beziehungsweise 97 %. Vor einem Jahr war eine solche Abdeckung unvorstellbar. Heute ist sie für mich der Maßstab.

GitLab bringt diese Kontrollen plattformweit zusammen. GitLab Duo Agent Platform schließt agentische Triage- und Behebungsschleifen auf demselben geregelten Pfad wie Quellcode, Sicherheit, CI/CD und Merge. GitLab-Kund(inn)en können diese Kontrollen in den Ausführungspfad legen und messen, ob sie die eigene Expositionszeit von der Erkennung zur verifizierten Behebung verkürzen.

Die tiefere architektonische Frage ist, ob agentische Arbeit über dasselbe geregelte Fundament der eigenen Software Factory läuft. Wenn ja, teilen sich Teams und Agenten eine gemeinsame Kontrollebene. Wenn nicht, besteht die Software Factory im Schattenbetrieb weiter, unabhängig davon, wie viel Sicherheitstooling die nachgelagerte Pipeline umgibt.

Das Betriebsmodell konkret machen

Ein glaubwürdiges Programm kann diese Fragen aus seinen eigenen Betriebsdaten beantworten:

• Wie sieht die vollständige Angriffsfläche aus, und wann wurde jede Fläche zuletzt gescannt?
• Welche Funde sind real, welche sind False Positives, und wer oder was hat das festgestellt?
• Wie lange blieb jeder reale Fund exponiert, bevor ein Fix im relevanten Umfeld verifiziert wurde?
• Welche Secrets wurden ausgestellt, an wen oder was, mit welchem Geltungsbereich, für wie lange, und wie wurden sie widerrufen?
• Welcher Agent hat welche Aktion ausgeführt, über welchen sanktionierten Pfad, mit welchen Tools und Berechtigungen?
• Welche Policy, welche Freigabe, welche Kontrolle zur Aufgabentrennung oder welche Deployment-Kontrolle hat die Aktion gestoppt oder erlaubt?
• Kann eine unabhängige Prüferin oder ein unabhängiger Prüfer die Nachweise nachvollziehen und zum gleichen Ergebnis kommen?

Diese Antworten sollten zunehmend automatisch vorliegen. Ein funktionierendes Programm hält die Abdeckung über die gesamte Angriffsfläche durchgängig, stellt hinter jeden materiellen Fund eine zurechenbare Eigentümerin oder einen zurechenbaren Eigentümer und einen geprüften Behebungspfad, und eliminiert exponierte, langlebige Secrets oder befristet sie mit vertretbaren kompensierenden Kontrollen. Agenten laufen über sanktionierte Identitäten und eingeschränkte Berechtigungen, mit einer erfassten Freigabe für risikoreiche Vorgänge, und die Zeit von der Erkennung zur verifizierten Behebung wird kontinuierlich gemessen, nach Schweregrad und Angriffspfad, um sie kontinuierlich maschinenschnell zu machen.

Wir lernen das, indem wir das Modell selbst betreiben. In den kommenden Monaten veröffentlicht GitLab einen Blueprint, der diese Prinzipien in operative Anleitung übersetzt: die Kontrollen, die Architektur, die Kennzahlen und die Praktiken, um eine Baseline zu etablieren. Der Blueprint soll dabei helfen, agentische Softwareentwicklung auf einem geregelten Pfad zu halten, Schatten-Produktionsarbeit zu eliminieren und Funde kontinuierlich in verifizierte Behebung zu überführen.

Das Ziel ist praktisch: Sicherheits- und Engineering-Verantwortlichen etwas geben, das sie umsetzen und messen können, unabhängig davon, wo sie gerade stehen.

Der Maßstab hat sich verändert

Ich schreibe das als jemand, der für dieselbe Klasse von Entscheidungen verantwortlich ist wie meine Leserinnen und Leser. Wenn Codegenerierung im Überfluss vorhanden und Vertrauen knapp ist, braucht agentische Softwareentwicklung maschinenschnelle Verifizierung und Behebung. Sicherheit, Governance und Leitplanken müssen Teil des Fundaments sein, nicht ein Kranz von Toren darum.

Die Gelegenheit gerade jetzt ist ungewöhnlich. Dieselben Modelle, die die Offensivfähigkeit steigern, können auch die Defensivfähigkeit erweitern. Als Sicherheitsfachleute haben wir mehr Kontext als der Angreifer, größeren Zugriff auf die eigenen Systeme und die Chance, die Entstehung von Software selbst beobachtbar und steuerbar zu machen. Diesen Vorteil müssen wir nutzen.

Erwartet kontinuierliche Absicherung von den Plattformen, auf denen gebaut wird. Verlangt Nachweise dafür, was sie finden, wie schnell sie es beheben und ob die Kontrollen den nächsten Sprung der Modellfähigkeiten überstehen. Wendet denselben Maßstab auf die eigene Softwareentwicklung an. GitLab-Kund(inn)en können Duo Agent Platform nutzen, um agentische Triage und Behebung auf denselben geregelten Pfad wie Quellcode-Management, CI/CD und den Rest des SDLC zu bringen.

Der neue Maßstab lautet jetzt, sich maschinenschnell "von der Erkennung zur verifizierten Behebung" zu bewegen.

Bei Transcend dabei sein, unserem Livestream-Event am 6. Oktober, bei dem wir tiefer in das Thema einsteigen und unsere neuesten Innovationen teilen, um bei der Absicherung agentischer Softwareentwicklung zu helfen.