Als GLM-5.2 Hugging Face dabei half, einen Vorfall zu untersuchen, bei dem eine KI eigenständig ihre eigenen Schutzmechanismen umging, wurde ein größerer Wandel deutlich. KI wird zunehmend Teil der Cyber-Offensive und der Cyber-Verteidigung.
Je zugänglicher leistungsfähige Cyber-Fähigkeiten werden, desto weniger dürfen starke Verteidigungsfähigkeiten auf eine kleine Zahl gut ausgestatteter Organisationen beschränkt bleiben. Open-Source-Maintainer, unabhängige Forscher, Entwickler und kleinere Sicherheitsteams benötigen ebenfalls Werkzeuge, die ihnen helfen, Schwachstellen zu finden und zu beheben, bevor sie ausgenutzt werden.
Eine offene Welt darf nicht nur offene Angriffsflächen haben. Sie braucht auch einen offenen Schutzschild.
GLM-5.3 ist unser bisher leistungsfähigstes Modell für Cybersicherheitsaufgaben. Es bietet erhebliche Verbesserungen bei der Erkennung von Schwachstellen, der Exploit-Analyse und komplexen mehrstufigen Sicherheitsaufgaben. Diese Fähigkeiten können Verteidigern helfen, Schwachstellen früher zu identifizieren, Risiken zu validieren und die Behebung zu beschleunigen.
Sie bergen jedoch auch klare Dual-Use-Risiken. Deshalb verfolgen wir einen gestaffelten Ansatz bei der Veröffentlichung. Ausgewählte Sicherheitspartner werden GLM-5.3 zunächst in kontrollierten Umgebungen evaluieren. Danach folgen ein breiterer Zugang und die Verfügbarkeit über die API. Sobald die erforderlichen Sicherheitsbewertungen und Release-Vorbereitungen abgeschlossen sind, werden wir die vollständigen Modellgewichte von GLM-5.3 veröffentlichen.
Verantwortungsvolle Offenheit bedeutet nicht, jede Fähigkeit als harmlos zu behandeln. Sie bedeutet, Risiken transparent zu bewerten, Schutzmaßnahmen vor der Veröffentlichung zu stärken, die Offenlegung bestätigter Schwachstellen zu koordinieren und den Zugang zu fortgeschrittenen Verteidigungsfähigkeiten in angemessenem Verhältnis zu den Risiken zu erweitern.
Von der Schwachstellenerkennung zur mehrstufigen Sicherheitsanalyse
Im Rahmen des Post-Trainings haben wir Daten zur Schwachstellenerkennung und autorisierte Sicherheitsumgebungen in den Trainingsmix aufgenommen. Wir erwarteten, dass dies die Fähigkeit des Modells verbessern würde, Schwachstellen zu finden und zu analysieren.
Mit zunehmendem Trainingsumfang gingen die Verbesserungen über einzelne Fehler hinaus. GLM-5.3 wurde effektiver darin, Schwachstellenbedingungen, Programmverhalten, Validierungspfade und potenzielle Auswirkungen über mehrere Analysestufen hinweg miteinander zu verknüpfen.
Wir bewerten diese Fähigkeiten anhand von drei Benchmarks:
- CyberGym geht von White-Box-Quellcode aus und testet, ob ein Modell Schwachstellen identifizieren und validieren kann, indem es Fehler auslöst. GLM-5.3 erreicht 84,5 %, gegenüber 77,2 % bei GLM-5.2.
- ExploitBench erfordert ein tieferes Verständnis realer Schwachstellen und ihrer Ausnutzung. GLM-5.3 erreicht 54,4 % – mehr als doppelt so viel wie GLM-5.2 mit 24,4 %.
- ExploitGym misst abgeschlossene Exploit-Aufgaben unter normalisierten Bewertungsbudgets. GLM-5.3 schließt 105 Aufgaben innerhalb von zwei Stunden und 130 innerhalb von sechs Stunden ab, gegenüber 29 und 39 bei GLM-5.2.
Das Muster ist konsistent. GLM-5.3 verbessert sich gegenüber GLM-5.2 am stärksten, wenn die Aufgaben von der isolierten Schwachstellenerkennung hin zur mehrstufigen Ausnutzung fortschreiten. Die Ergebnisse zeigen auch, wo weitere Fortschritte nötig sind, insbesondere bei den komplexesten End-to-End-Aufgaben.
Von Benchmarks zu realer Software
Wir haben außerdem mit Universitäten und professionellen Sicherheitsteams zusammengearbeitet, um GLM-Modelle in autorisierten Umgebungen an realen Codebasen zu evaluieren.
Im Rahmen dieser Arbeit hat die GLM-Serie in 269 Projekten 2.436 Schwachstellenbefunde erzielt, darunter 1.097, die als mittlere bis hohe Schweregrade eingestuft wurden. Die Befunde erstrecken sich über Systemsoftware, Betriebssysteme, Browser-Engines, Open-Source-Infrastruktur, Webanwendungen, Netzwerkprotokolle und intelligente Geräte. Einige der zugrunde liegenden Probleme waren jahrzehntelang unbemerkt geblieben.
Bei diesen Evaluierungen legen Sicherheitsexperten den autorisierten Umfang fest, prüfen die Modellausgaben, untersuchen potenzielle Risiken und koordinieren sich mit den relevanten Parteien. GLM-Modelle können Forschern helfen, komplexe Programmlogik zu rekonstruieren, eine große Zahl von Kandidatenpfaden einzugrenzen und Beweise über mehrere Komponenten hinweg zu verknüpfen.
Der Zweck besteht nicht einfach darin, mehr Befunde zu erzeugen. Es geht darum, Verteidigern zu helfen, relevante Risiken früher zu erkennen und die Zeit zwischen Entdeckung und Behebung zu verkürzen.
Auf die Entdeckung muss eine verantwortungsvolle Offenlegung folgen
Eine Schwachstelle ist nicht in dem Moment sicher behandelt, in dem sie entdeckt wird. Sie muss überprüft, gegebenenfalls reproduziert, über die richtigen Kanäle gemeldet und mit den betroffenen Maintainern koordiniert werden.
Befunde aus unserer Sicherheitsarbeit werden über etablierte Offenlegungsprozesse eingereicht. Technische Details veröffentlichen wir nur dann, wenn dies mit dem jeweiligen Offenlegungs- und Behebungsprozess vereinbar ist. Bei Problemen, die sich noch in Koordination befinden, veröffentlichen wir keine Informationen, die das Risiko unnötig erhöhen oder betroffene Projekte identifizieren könnten.
Um diese Arbeit transparenter zu gestalten, haben wir das Z.ai Security Disclosure Ledger erstellt.
Das Ledger dokumentiert Befunde, während sie den Offenlegungsprozess durchlaufen. Bei öffentlich offengelegten Problemen kann es das betroffene Projekt, den Schweregrad, eine CVE- oder andere Kennung, sofern verfügbar, sowie Informationen darüber enthalten, wie lange das Problem in der Codebasis bestand.
Für Schwachstellen, die sich noch in koordinierter Offenlegung befinden, kann das Ledger einen kryptografischen Hash veröffentlichen. Dadurch kann ein Befund später verifiziert werden, ohne vorzeitig operative Details preiszugeben.
Ein Modell zu öffnen und eine Schwachstelle offenzulegen, sind getrennte Entscheidungen. Ein Modell breiter verfügbar zu machen, erfordert nicht, Schwachstellendetails zu veröffentlichen, bevor die Maintainer eine angemessene Gelegenheit zur Untersuchung und Reaktion hatten.
Sicherheit und gestaffelte Veröffentlichung
Cybersicherheit ist ein besonders schwieriges Gebiet für KI-Sicherheit. Offensive und defensive Aufgaben verwenden oft dieselbe Terminologie, denselben Code und dieselben technischen Methoden.
Eine Anfrage zur Analyse einer Schwachstelle kann von einem Maintainer stammen, der einen Patch vorbereitet, von einem Studierenden, der eine CTF-Challenge löst, von einem Forscher, der eine autorisierte Bewertung durchführt, oder von einem Angreifer, der ein reales System ins Visier nimmt. Schlüsselwörter allein können diese Fälle nicht zuverlässig unterscheiden. Absicht, Autorisierung, Kontext, Ziel und potenzielle Auswirkungen – all das ist entscheidend.
Für GLM-5.3 verwenden wir einen Defense-in-Depth-Ansatz mit drei sich ergänzenden Ebenen.
Externer Klassifikator
In unseren gehosteten Diensten identifiziert ein externer Klassifikator risikoreiche Anfragen und hilft, eindeutig schädliche Aktivitäten zu verhindern.
Reasoning-Monitor
Ein Reasoning-Monitor bewertet Risiken während der Aufgabenausführung. Er ist darauf ausgelegt, schädliche Absichten zu erkennen, die über mehrere Schritte hinweg entstehen können, anstatt sich nur auf den Wortlaut der ursprünglichen Anfrage zu verlassen.
Deep-Safety-Alignment
Das Modell selbst wird darauf trainiert, legitime Sicherheitsarbeit von hochriskanten offensiven Aktivitäten zu unterscheiden und Anfragen abzulehnen, die diese Grenze überschreiten.
Deep-Safety-Alignment ist besonders wichtig für eine Open-Weight-Veröffentlichung. Gehostete Klassifikatoren und Monitore gelten für unsere Dienste, begleiten das Modell aber nicht automatisch in jede lokale Bereitstellung. Das Alignment auf Modellebene ist die Sicherheitsebene, die im veröffentlichten Checkpoint enthalten ist.
Für die Entwicklung dieser Systeme haben wir differenzielle Trainingsdaten erstellt, die sowohl die Gemeinsamkeiten als auch die Unterschiede zwischen autorisierter Sicherheitsforschung und bösartigen Aktivitäten abbilden. Darüber hinaus haben wir adversariale Daten konstruiert, die Jailbreak-Varianten, verschleierte Absichten und andere Versuche abdecken, Sicherheitsprüfungen zu umgehen.
Unsere Evaluierungen decken eine Reihe von Cybersicherheitsaufgaben ab, darunter:
- Sicherheitsausbildung und -wissen;
- Blue-Team-Verteidigung;
- CTF-Challenges;
- Schwachstellenerkennung und -behebung;
- autorisierte Penetrationstests;
- Exploit-Entwicklung;
- unbefugtes Eindringen und andere eindeutig schädliche Aktivitäten.
Das Ziel ist es, hochriskanten Missbrauch zu reduzieren, ohne legitime defensive, bildungsbezogene und Forschungsaufgaben pauschal abzulehnen.
Vor der breiteren Veröffentlichung werden professionelle Sicherheitsteams Sicherheitsbewertungen und Red-Team-Tests durchführen. Diese Evaluierungen prüfen sowohl, ob das Modell dazu manipuliert werden kann, schädliche Aktivitäten zu unterstützen, als auch, ob seine Schutzmechanismen legitime Sicherheitsarbeit beeinträchtigen.
Kein Sicherheitssystem kann jedes Dual-Use-Risiko eliminieren. Sobald Modellgewichte öffentlich sind, kann kein Entwickler die Kontrolle über jede nachgelagerte Modifikation oder Nutzung garantieren. Schutzmechanismen auf Modellebene können die Hürde für Missbrauch erhöhen, aber keine absolute Kontrolle bieten.
Unser Veröffentlichungsprozess konzentriert sich daher auf die Phasen, in denen eine sinnvolle Risikoreduzierung möglich ist: Training, Bewertung vor der Veröffentlichung, kontrollierte Partnertests, Schutzmaßnahmen für gehostete Dienste, verantwortungsvolle Offenlegung und fortlaufende adversariale Tests.
Start der OpenVuln-Initiative
Ein großer Teil der digitalen Infrastruktur der Welt hängt von Open-Source-Software ab. Viele kritische Projekte werden von kleinen Teams oder einzelnen Mitwirkenden gepflegt, die keine eigenen Sicherheitsressourcen haben.
Gleichzeitig macht KI komplexe Cyber-Aufgaben leichter automatisierbar. Wenn fortgeschrittene Verteidigungsfähigkeiten auf eine kleine Zahl von Organisationen konzentriert bleiben, könnten die Projekte mit den wenigsten Ressourcen allein dafür verantwortlich sein, einige der wichtigsten Teile der Software-Lieferkette zu schützen.
Um dieses Ungleichgewicht anzugehen, starten wir die OpenVuln-Initiative parallel zu GLM-5.3.
Kontinuierliche Unterstützung für Open-Source-Sicherheit
Wir werden mit Maintainern zusammenarbeiten, um wichtige Open-Source-Projekte zu prüfen, potenzielle Schwachstellen zu identifizieren und eine verantwortungsvolle Offenlegung und Behebung zu unterstützen.
Maintainer können OpenVuln nutzen, um Projekte zur Sicherheitsprüfung einzureichen und mehr über den Prozess zu erfahren.
Ein Schutzschild für die offene Welt
GLM-5.3 zeigt, dass offene Modelle bei der Schwachstellenerkennung, der Exploit-Analyse und komplexem Sicherheits-Reasoning deutlich leistungsfähiger werden können. Dieser Fortschritt bringt echten defensiven Nutzen und echte Dual-Use-Risiken mit sich.
Unsere Verantwortung besteht darin, diese Fähigkeiten darauf auszurichten, Schwachstellen früher zu finden, eine verantwortungsvolle Behebung zu unterstützen und die Open-Source-Systeme zu stärken, von denen alle abhängen.
Nach der gestaffelten Evaluierung und dem breiteren API-Zugang beabsichtigen wir, GLM-5.3 als Open-Weight-Modell zu veröffentlichen. Wir werden während dieses Prozesses weiterhin die Schutzmechanismen auf Modellebene verbessern, adversariale Nutzung testen und die koordinierte Offenlegung unterstützen.
Die offene Welt braucht einen eigenen Schutzschild. Mit GLM-5.3 und der OpenVuln-Initiative beabsichtigen wir, diesen Schutzschild breiter verfügbar zu machen und ihn mit Bedacht zu veröffentlichen.
