Ein Jahresabonnement zur kontinuierlichen Suche und Validierung von Schwachstellen
Palo Alto Networks kündigte am 22. September 2026 Unit 42 Continuous Frontier AI Defense an. Der jährliche Abonnementdienst kombiniert laut Unternehmen Sicherheitsexperten mit künstlicher Intelligenz, um kontinuierlich nach Schwachstellen zu suchen, deren Ausnutzbarkeit zu prüfen und ihre Behebung zu beschleunigen. Die Ankündigung beschreibt ein KI-gestütztes Angebot für offensive Sicherheitstests, aber keine unabhängige Bewertung seiner Wirksamkeit.
Im Datenblatt des Anbieters werden kontinuierliche Schwachstellensuche, die Validierung der Ausnutzbarkeit und Empfehlungen zur Behebung von Problemen aufgeführt. Genannt werden außerdem virtuelle Patches und Codeänderungen. Dass der Dienst eine Maßnahme erstellen oder empfehlen kann, bedeutet für sich genommen nicht, dass er sie in einer Produktivumgebung auch anwendet: Aus den verfügbaren Unterlagen geht nicht ausreichend hervor, welche Änderungen automatisch umgesetzt werden und für welche eine Validierung oder Freigabe durch den Kunden erforderlich ist.
Das Konzept kann für Teams interessant sein, die exponierte oder komplexe Systeme regelmäßig überprüfen müssen. Eine Kaufentscheidung sollte sich jedoch nicht allein darauf stützen, dass die Suche „kontinuierlich“ erfolgt oder von fortschrittlichen Modellen unterstützt wird. Ebenso wichtig sind die einbezogenen Assets, die Testbedingungen, die Qualität der vorgelegten Nachweise und die Kontrolle über alle Maßnahmen, die ein System verändern oder beeinträchtigen könnten.
Ein Multi-Modell-Harness und die Beteiligung von Menschen
Das Unternehmen nennt Claude Mythos 5, GPT-5.6-Cyber und Open-Weight-Modelle als Systeme, die zum Einsatz kommen können. Laut Ankündigung verteilt ein eigenes Harness Aufgaben auf verschiedene Modelle; außerdem sind Sicherheitsexperten von Unit 42 an der Leistungserbringung beteiligt. Die Idee dahinter ist, die Arbeit aufzuteilen, statt die gesamte Suche einem einzigen Modell anzuvertrauen.
Der Begriff „Multi-Modell-Harness“ bezeichnet eine Schicht, die den Einsatz unterschiedlicher Modelle koordiniert. Er erklärt aber noch nicht, wie Entscheidungen zustande kommen. Um den Ablauf bewerten zu können, müsste ein potenzieller Kunde wissen, welche Aufgaben welchem Modell zugewiesen werden, wie doppelte Ergebnisse zusammengeführt werden, wer fragwürdige Funde überprüft und welche Nachweise der Dienst dafür sichert, dass eine Schwachstelle tatsächlich besteht und ausnutzbar ist.
Auch die Beteiligung von Menschen ist nicht automatisch gleichbedeutend mit wirksamer Aufsicht. Dass Sicherheitsexperten eingebunden sind, sagt noch nicht, an welchem Punkt sie Ergebnisse prüfen, ob sie jeden aktiven Test genehmigen oder ob ihr Beitrag auf bestimmte Phasen beschränkt ist. Dieser Unterschied kann sowohl das Betriebsrisiko als auch die Verantwortung für Entscheidungen beeinflussen.
Ablauf, den Sie mit dem Anbieter klären sollten
- 01Legen Sie schriftlich fest, welche Systeme einbezogen sind, welche ausgeschlossen werden und welche Maßnahmen erlaubt sind.
- 02Klären Sie, welche Aufgaben den Modellen zugewiesen werden und wie ihre Ergebnisse zusammengeführt werden.
- 03Fordern Sie reproduzierbare Nachweise an, mit denen sich jeder Fund und seine möglichen Auswirkungen überprüfen lassen.
- 04Klären Sie, welche Tests eine gesonderte Genehmigung erfordern und welche Maßnahmen ohne zusätzliche Freigabe ausgeführt werden können.
- 05Trennen Sie die Empfehlung einer Korrektur von ihrer Validierung und tatsächlichen Umsetzung.
Zwei auffällige Zahlen, die weiterhin dem Anbieter zuzurechnen sind
Palo Alto Networks zufolge hat in den eigenen Tests mit komplexen Umgebungen kein einzelnes Modell mehr als 40 % der Schwachstellen erkannt. Das Unternehmen behauptet außerdem, dass Claude Mythos 5 und GPT-5.6-Cyber bei weniger als 10 % der von ihnen identifizierten Exposures übereinstimmten. Diese Zahlen könnten auf eine mögliche Ergänzung der Modelle untereinander hindeuten. Es handelt sich jedoch um vom Unternehmen mitgeteilte Ergebnisse und nicht um eine unabhängige Messung des Dienstes.
Die Angabe von weniger als 40 % lässt sich ohne weitere Informationen zur Abdeckung nicht einordnen: Es ist unklar, was als Schwachstelle gezählt wurde, wie viele Schwachstellen es insgesamt gab und nach welchen Kriterien die Umgebungen ausgewählt wurden. Die Zahl sagt auch für sich genommen nichts über Fehlalarme aus. Ein Modell könnte nur wenige Probleme melden und damit richtigliegen – oder zahlreiche Funde produzieren, die sich später nicht bestätigen. Ohne Nenner und Validierungskriterien reicht die Angabe weder für einen Modellvergleich noch für eine Einschätzung der Leistung in der Infrastruktur einer bestimmten Organisation aus.
Auch eine Überschneidung von weniger als 10 % bedeutet nicht automatisch, dass die Modelle in diesem Umfang einzigartige und korrekte Schwachstellen entdeckt haben. Dafür müsste bekannt sein, wie eine Übereinstimmung definiert wurde, ob Duplikate entfernt wurden, wie Funde gruppiert wurden, die denselben Fehler beschreiben, und ob beide Modelle dieselben Aufgaben unter denselben Bedingungen erhielten. Relevant ist zudem der Unterschied zwischen „identifizierten Exposures“ und bestätigten Schwachstellen.
Axios schreibt die Abdeckungsangabe von weniger als 40 % Tests von Palo Alto Networks selbst zu; in der Ankündigung des Unternehmens werden die Angaben zu Abdeckung und Überschneidung aufgeführt. Die geprüften veröffentlichten Materialien enthalten jedoch kein reproduzierbares Testprotokoll, keine vollständigen Testdatensätze und keine detaillierten Ergebnisse, anhand derer sich die Prozentsätze extern überprüfen ließen. Sie sind daher als Angaben des Anbieters zu verstehen.
Was die Zahlen aussagen – und welche Informationen fehlen
| Veröffentlichte Aussage | Vorsichtige Einordnung | Benötigte Informationen |
|---|---|---|
| Kein einzelnes Modell erkannte in komplexen Umgebungen mehr als 40 % der Schwachstellen. | Das Unternehmen berichtet von einer begrenzten Abdeckung in eigenen Tests. Daraus lässt sich die Leistung in anderen Systemen nicht ableiten. | Referenzbestand der Schwachstellen, Auswahl der Umgebungen, Nenner, Erkennungskriterien und Fehlalarme. |
| Mythos 5 und GPT-5.6-Cyber stimmten bei weniger als 10 % der identifizierten Exposures überein. | Der Anbieter meldet eine geringe Überschneidung. Das belegt nicht, dass unterschiedliche Funde korrekt oder komplementär sind. | Definition der Übereinstimmung, Umgang mit Duplikaten, bestätigte Ergebnisse und vergleichbare Bedingungen für beide Modelle. |
Aufdecken, Ausnutzen, Priorisieren und Beheben sind unterschiedliche Schritte
Bei einem offensiven Sicherheitstest sind die Suche nach einem Hinweis auf eine Schwachstelle und die Prüfung ihrer Ausnutzbarkeit zwei verschiedene Schritte. Ein Scanner kann auf eine verdächtige Konfiguration oder Komponente hinweisen; eine aktive Validierung versucht festzustellen, ob die Schwäche praktische Folgen hat. Diese zweite Phase kann konkretere Nachweise liefern, erfordert aber klare Grenzen: Manche Tests können Daten verändern, einen Dienst beeinträchtigen oder mit Systemen Dritter interagieren, wenn der Umfang nicht eindeutig festgelegt ist.
Auch Priorisierung ist nicht dasselbe wie Behebung. Eine Rangfolge der Funde hilft bei der Entscheidung, was zuerst geprüft werden sollte, beseitigt aber kein Risiko. Eine Empfehlung, ein virtueller Patch oder ein vorgeschlagener Codeeingriff sind mögliche Maßnahmen. Dass sie im Datenblatt des Dienstes erwähnt werden, belegt jedoch weder ihre Installation noch ihre Eignung für jede Umgebung. Die tatsächliche Umsetzung erfordert Kompatibilitätstests, Änderungsmanagement und eine Bestätigung, dass die Korrektur das Problem behoben hat, ohne neue Probleme einzuführen.
Diese Art von Aktivität sollte außerdem von der Klassifizierung und Bearbeitung von Warnmeldungen unterschieden werden. Erkennungs- und Reaktionsprozesse analysieren typischerweise Aktivitätssignale und kümmern sich um mögliche Sicherheitsvorfälle. Autorisierte offensive Tests suchen durch zuvor vereinbarte Maßnahmen nach Schwachstellen. Es kann Berührungspunkte geben, doch Zweck, Berechtigungen und Risiken sind nicht austauschbar.
Praktische Fragen vor einer Bewertung des Dienstes
Vor dem Abschluss eines Vertrags über kontinuierliche Tests sollten Sicherheitsverantwortliche den vertraglichen und operativen Umfang ebenso genau anfordern wie bei einem Penetrationstest. Eine häufige Ausführung ersetzt keine Autorisierung: Assets, Zeitfenster, ausgeschlossene Systeme, Abhängigkeiten von Drittanbietern und Kontakte zum Anhalten eines Tests sollten eindeutig festgelegt sein.
Sinnvoll ist auch, Beispiele für um sensible Daten bereinigte Berichte, Kriterien zur Bestätigung von Funden, Fehlalarmraten und eine Möglichkeit zur Reproduktion der Tests in einer kontrollierten Umgebung anzufordern. Kann der Anbieter nicht alle diese Informationen bereitstellen, sollte er erläutern, welche Angaben er unter welchen Bedingungen liefern kann und welche Einschränkungen eine externe Prüfung verhindern.
Bei der Nutzung von Modellen sollte geklärt werden, welche Kundendaten übermittelt werden, wo sie verarbeitet und wie lange sie gespeichert werden und ob sie zum Trainieren oder Anpassen von Modellen genutzt werden. Die geprüften Materialien beschreiben die genannten Modelle und Funktionen, beantworten diese Fragen aber nicht vollständig. Auch die Modellnamen allein reichen nicht aus: Konfiguration, angebundene Werkzeuge und Autorisierungsregeln beeinflussen, was das System tun kann.
Für Patches sind gesonderte Fragen nötig: Handelt es sich um eine Empfehlung, einen virtuellen Patch oder eine Codeänderung? Wer prüft Kompatibilität und Regressionen? Welche Freigabe ist für die Umsetzung erforderlich? Wie lässt sich eine Änderung zurücknehmen, falls sie Probleme verursacht? Konkrete Antworten helfen, automatisierte Analyse von tatsächlichem Änderungsmanagement zu unterscheiden.
Prüfliste für Käufer
| Bereich | Sinnvolle Frage |
|---|---|
| Autorisierung und Umfang | Welche Assets und Maßnahmen sind erlaubt, und wie werden Systeme außerhalb des vereinbarten Umfangs ausgeschlossen? |
| Betriebssicherheit | Welche Grenzen stoppen einen Test bei unerwarteten Auswirkungen, und wer kann sie aktivieren? |
| Qualität der Funde | Wie werden Schwachstellen, Duplikate und Fehlalarme überprüft? |
| Nachweise | Welche Protokolle ermöglichen es, jedes Ergebnis zu reproduzieren und zu prüfen? |
| Daten und Modelle | Welche Informationen werden übermittelt, gespeichert oder zum Trainieren verwendet? |
| Korrekturen | Welche Änderungen werden empfohlen und welche, falls überhaupt, automatisch umgesetzt? |
Was sich vorerst schlussfolgern lässt
Die Ankündigung belegt, dass Palo Alto Networks einen jährlichen Unit-42-Dienst anbietet, der Spezialisten, ein Multi-Modell-Harness und Funktionen zur Suche, Validierung und Empfehlung von Korrekturen kombiniert. Sie dokumentiert außerdem, welche Modelle das Unternehmen nennt und welche Leistungszahlen es seinen Tests zuschreibt. Die Berichterstattung liefert Kontext zur Ankündigung, macht aus diesen Ergebnissen aber keine unabhängige Bewertung.
Eine auf arXiv verfügbare Forschungsarbeit untersucht die Bewertung von Sprachmodellen für die Cybersicherheit anhand von Schwachstellentests. Sie ist als Kontext für die Bedeutung gut konzipierter Benchmarks relevant, bewertet jedoch weder diesen Dienst noch bestätigt sie die von Palo Alto Networks veröffentlichten Zahlen. Sie sollte nicht als Validierung des Produkts dargestellt werden.
Die vorsichtige Schlussfolgerung lautet nicht, dass der Dienst keinen Nutzen hat oder dass seine Angaben falsch sind. Vielmehr erlauben die geprüften öffentlichen Informationen keine unabhängige Messung seiner Abdeckung, Genauigkeit oder Betriebssicherheit. Für eine Entscheidung braucht jede Organisation Nachweise, die zu ihrer Umgebung passen, klare Autorisierungsgrenzen und Transparenz darüber, wie Menschen beteiligt sind und wie Änderungen umgesetzt werden. Bis prüfbare Ergebnisse oder spezifische externe Bewertungen veröffentlicht werden, sollten die Zahlen weiterhin dem Unternehmen zugeschrieben werden.
Offene Fragen
- Die geprüften Materialien enthalten keine vollständigen Testdatensätze und kein reproduzierbares Protokoll, mit denen sich die veröffentlichten Zahlen extern prüfen ließen.
- Aus den verfügbaren Informationen gehen weder die genaue Definition einer erkannten Schwachstelle noch die Berechnung der Überschneidung zwischen den Modellen hervor.
- Es ist nicht geklärt, welche Maßnahmen der Dienst automatisch ausführt und welche eine menschliche Validierung oder Freigabe durch den Kunden erfordern.
- Spezifische unabhängige Bewertungen von Unit 42 Continuous Frontier AI Defense wurden nicht vorgelegt.
Weiter entdecken
Verwendete Quellen
Korrekturen und Transparenz
Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.
Korrektur vorschlagen