Ciscos kleine KI-Modelle offenbaren einen größeren Sicherheitskompromiss

Cisco Foundation AI veröffentlichte im Juli zwei Open-Weight-Sicherheitsmodelle, obwohl selbst führende Systeme nachweislich die meisten anfälligen Code-Stellen weiterhin übersehen. In Google News erschien die Ankündigung als weitere monatliche Sammlung von Modellen, Benchmarks und Sicherheitsforschung. Doch die wichtige Geschichte ist nicht Ciscos Veröffentlichungstakt.

Cisco prüft, ob kleine, spezialisierte Modelle wiederkehrende Sicherheitsaufgaben wirtschaftlicher erledigen können als universelle Frontier-Systeme. Antares-350M und Antares-1B durchsuchen Software-Repositories nach Dateien, die mit bekannten Schwachstellenkategorien verbunden sind. Sie können lokal laufen, sodass sensibler Quellcode innerhalb der Umgebung einer Organisation bleibt.

Dieses Design stellt die Annahme infrage, dass jede schwierige KI-Aufgabe das größtmögliche verfügbare Modell erfordert. Microsoft und Google führten im selben Zeitraum eigene spezialisierte Cybersicherheitssysteme ein. Der entstehende Wettbewerb stellt nun fokussierte, lokal einsetzbare Modelle größeren Diensten mit umfassenderen Schlussfolgerungsfähigkeiten gegenüber.

Ciscos Benchmark-Ergebnisse stützen den spezialisierten Ansatz, offenbaren aber auch dessen Grenzen. Das beste System auf Ciscos primärem Benchmark erzielte einen File-F1-Score von unter 0,23. Fast zwei von fünf Benchmark-Aufgaben konnten von keinem der bewerteten Modelle gelöst werden.

Es handelt sich daher um einen Kompromiss, nicht um eine Siegesrunde. Kleinere Modelle bieten geringere Betriebsanforderungen, strengere Datenkontrolle und wiederholbare Repository-Analysen. Ihre unvollständigen Ergebnisse erfordern weiterhin erfahrene Analysten, etablierte Sicherheitstools und sorgfältige Validierung.

Was Cisco im Juli tatsächlich veröffentlicht hat

Cisco veröffentlichte ein fokussiertes Code-Suchsystem, keinen autonomen Schwachstellenjäger.

Am 21. Juli 2026 stellte Cisco Antares-350M und Antares-1B als Open-Weight Small Language Models vor. Ihr Zweck ist die Lokalisierung von Schwachstellen, also das Auffinden von Dateien, die eine beschriebene Schwäche enthalten könnten.

Die Unterscheidung ist wichtig, weil die Lokalisierung nur eine Stufe des Schwachstellenmanagements darstellt. Antares bestätigt weder selbstständig die Ausnutzbarkeit noch bestimmt es den Schweregrad, erstellt einen vollständigen Patch oder gibt Code für die Produktion frei.

Stattdessen erhält jedes Modell ein Repository und eine Beschreibung aus der Common Weakness Enumeration. Eine CWE ist eine standardisierte Kategorie für wiederkehrende Softwareschwächen, etwa eine fehlerhafte Eingabevalidierung.

Das Modell erkundet ein schreibgeschütztes Repository mit Terminalbefehlen. Es sucht nach relevanten Mustern, liest Kandidatendateien, bewertet die Hinweise und ändert die Richtung, wenn sich ein Suchpfad als unproduktiv erweist.

Cisco beschreibt dieses Verhalten in seiner Antares-Veröffentlichung. Das System liefert eine rangierte Liste wahrscheinlicher Dateien und eine Aufzeichnung der während der Erkundung verwendeten Befehle.

Diese Aufzeichnung ist für Sicherheitsabläufe wichtig. Ein Analyst kann nachvollziehen, wie das Modell zu seiner Antwort gelangt ist, statt ein unbelegtes Urteil über eine Schwachstelle zu erhalten.

Antares-350M richtet sich an ressourcenbeschränkte Rechenumgebungen und unterstützt ein Kontextfenster von 32.000 Tokens. Antares-1B unterstützt 128.000 Tokens und ist für den Betrieb auf einem einzelnen Grafikprozessor ausgelegt.

Die lokale Ausführung ist ein weiteres prägendes Merkmal. Ein Unternehmen kann proprietären Code untersuchen, ohne sein Repository an einen gehosteten Modellanbieter zu übertragen. Diese Option berücksichtigt Datenschutz-, Standort- und Vertragsanforderungen, die cloudbasierte Sicherheitsanalysen häufig verhindern.

Cisco führte außerdem VLoc Bench zur Bewertung der Modelle ein. Der Benchmark enthält 500 Aufgaben aus 290 Repositories, sechs Paketökosystemen und 147 unterschiedlichen CWE-Kategorien.

Jede Aufgabe umfasst einen Repository-Schnappschuss mit einer bekannten Schwachstelle. Die Ground-Truth-Labels stammen aus den Dateien, die durch den zugehörigen Sicherheitspatch geändert wurden.

Der Benchmark trennt Lokalisierung von Verifikation. Bei der Lokalisierung muss ein Modell die mit der Schwäche verbundenen Dateien finden. Bei der Verifikation untersucht es das gepatchte Repository und sollte vermeiden, die behobene Schwachstelle fälschlich zu melden.

Diese Struktur ist enger gefasst als ein vollständiger Penetrationstest. Sie ist zugleich anspruchsvoller, als einen Code-Schnipsel aus einem vorbereiteten Prompt abzurufen.

Das Modell muss sich unter begrenzter Informationslage in unbekannten Repositories zurechtfinden. Das macht den Benchmark für die Triage von Advisories relevant, bei der Verteidiger die Schwachstellenkategorie oft kennen, bevor sie deren Implementierung lokalisieren.

Cisco positioniert Antares neben statischer Analyse, Software Composition Analysis, Secret Scanning, dynamischen Tests und menschlicher Prüfung. Die Modelle werden nicht als Ersatz für diese Kontrollen präsentiert.

Die unmittelbare Veränderung ist daher praktisch, aber begrenzt. Sicherheitsteams erhalten zwei herunterladbare Modelle, um ein großes Repository auf eine kleinere Menge möglicher Dateien zu reduzieren.

Diese erste Eingrenzung kann bei wiederkehrenden Untersuchungen Aufmerksamkeit sparen. Sie kann weder belegen, dass die ausgewählten Dateien anfällig sind, noch nachweisen, dass ausgelassene Dateien sicher sind.

Warum Google News die eigentliche Tragweite übersehen hat

Die Google-News-Schlagzeile stellte den Juli als Strom von Veröffentlichungen dar, während die eigentliche Verschiebung betrifft, wer sich kontinuierliche Code-Überprüfung leisten kann.

Teams für Anwendungssicherheit untersuchen ein Repository nicht nur einmal. Code ändert sich, Abhängigkeiten verschieben sich, Advisories treffen ein, und zuvor akzeptables Verhalten wird durch neue Angriffstechniken gefährlich.

Ein gehostetes Frontier-Modell kann bei diesen Prüfungen helfen. Wiederholte Analysen auf Repository-Ebene verbrauchen jedoch erhebliche Inferenzressourcen und können erfordern, dass sensibler Code die Infrastruktur des Unternehmens verlässt.

Kleine lokale Modelle verändern diese Betriebsökonomie. Sie können eine eng umrissene Aufgabe wiederholt erledigen, ohne dass jeder Scan von einem hochpreisigen externen Dienst abhängt.

Dieser Kompromiss setzt mehrere Gruppen zugleich unter Druck. Anbieter von Frontier-Modellen müssen zeigen, dass umfassenderes Schlussfolgern genug zusätzlichen Nutzen bringt, um höhere Betriebsanforderungen zu rechtfertigen.

Sicherheitsanbieter müssen entscheiden, ob spezialisierte Modelle in bestehende Scanner, Triage-Konsolen und Continuous-Integration-Pipelines gehören. Interne Sicherheitsteams müssen feststellen, ob von Modellen erzeugte Datei-Ranglisten die Arbeitslast von Analysten tatsächlich reduzieren.

Ciscos Ansatz setzt auch Organisationen unter Druck, die KI-Sicherheit bislang als Beschaffungsentscheidung für einen Chatbot behandelt haben. Die Lokalisierung von Schwachstellen ist ein Workflow-Problem, das Repository-Zugriff, Beweissicherung, Berechtigungen und menschliche Eskalation umfasst.

Eine sinnvolle Bereitstellung würde Antares mit einem kontrollierten Repository-Schnappschuss verbinden. Sie würde die Suchaufzeichnung speichern, Kandidatendateien zurückgeben und diese an einen Analysten weiterleiten.

Der Analyst würde die Ausgabe mit Abhängigkeitsdaten, statischen Befunden, Tests und dem ursprünglichen Advisory vergleichen. Erst dann würde die Organisation entscheiden, ob eine Behebung erforderlich ist.

Diese Arbeitsteilung ist wichtig, weil Schwachstellenarbeit asymmetrische Folgen hat. Ein Fehlalarm bindet Zeit von Analysten, während ein falsch negatives Ergebnis gefährlichen Code unentdeckt lässt.

Die Juli-Veröffentlichungen legen nahe, dass kein einzelnes Modell den gesamten Prozess abdecken muss. Ein Modell könnte verdächtigen Code lokalisieren, während ein anderes die Ausnutzbarkeit bewertet oder eine Reparatur entwirft.

Google DeepMind vertrat eine ähnliche Auffassung, als es über sein CodeMender-Programm ein spezialisiertes Cyber-Modell vorstellte. Microsoft kündigte ebenfalls ein intern trainiertes Cybersicherheitsmodell und zugehörige Sicherheitsagenten an.

Ein Branchenvergleich beschrieb alle drei Unternehmen als Verfolger aufgabenspezifischer Systeme. Zu ihren gemeinsamen Motiven zählen Zugriffsrestriktionen und die Kosten, Frontier-Modelle im großen Maßstab zu betreiben.

Diese Konvergenz verleiht Ciscos Arbeit größere Bedeutung als einem einzelnen Produktstart. Spezialisierte Sicherheitsmodelle werden zu einer eigenständigen Schicht zwischen deterministischen Scannern und universellen KI-Assistenten.

Statische Tools bleiben wirksam, wenn Maintainer verlässliche Regeln definieren können. Frontier-Modelle bleiben nützlich, wenn eine Aufgabe breites Schlussfolgern, die Erstellung von Reparaturen oder Interaktion über viele Systeme hinweg erfordert.

Ein kleines Sicherheitsmodell passt dazwischen. Es kann investigative Suchmuster lernen und zugleich kompakt genug für einen kontrollierten, häufigen Einsatz bleiben.

Die Wettbewerbsfrage lautet nicht, ob Antares jedes größere Modell übertreffen kann. Sie lautet, ob ein Portfolio spezialisierter Systeme über routinemäßige defensive Workflows hinweg ausreichende Genauigkeit liefern kann.

Wenn dieses Modell funktioniert, werden Käufer KI anhand von Aufgabenökonomie und betrieblicher Eignung bewerten. Allgemeines Benchmark-Ansehen wird weniger Gewicht haben als messbare Verkürzungen der Triage-Zeit.

Kleine Sicherheitsmodelle stellen die Ökonomie von Frontier-Modellen infrage

Antares argumentiert, dass trainiertes Suchverhalten für eine eng definierte Sicherheitsaufgabe wichtiger sein kann als die Parameterzahl.

Universelle Coding-Modelle lernen Schwachstellenarbeit neben vielen nicht verwandten Fähigkeiten. Sie müssen Schreiben, Erklärungen, Planung, Codegenerierung und breites Software-Schlussfolgern unterstützen.

Antares grenzt das Ziel ein. Es lernt, zu suchen, Hinweise zu prüfen, einen Pfad zu überarbeiten und Dateien zu identifizieren, die mit einer bestimmten Schwachstellenbeschreibung verbunden sind.

Dieses engere Trainingsziel erlaubt Cisco, Modellkapazität auf die Navigation in Repositories zu konzentrieren. Der Ansatz ähnelt einem geschulten Ermittler, der über Tools arbeitet, statt einem Chatbot, der Sicherheitsterminologie abruft.

Das Modell beginnt mit begrenzten Hinweisen. Es kann Dateinamen und Code-Muster durchsuchen, relevante Dateien untersuchen und neue Erkenntnisse nutzen, um spätere Befehle zu steuern.

Ein nützlicher Agent muss auch schwache Hypothesen verwerfen können. Ohne dieses Verhalten kann die Erkundung eines Repositorys zu einer kostspieligen Folge redundanter Suchen werden.

Ciscos Benchmark prüft diesen Prozess unter einer Befehlsgrenze. Die Repository-Struktur wird dadurch Teil der Aufgabe und nicht zu Hintergrundinformation, die in einem Prompt verborgen ist.

Die Ergebnisse stützen Ciscos Spezialisierungsthese. Antares-1B erzielte laut veröffentlichten Benchmark-Daten auf VLoc Bench einen File-F1-Score von 0,209.

Das unveröffentlichte Antares-3B erreichte 0,223. Die führende GPT-5.5-Konfiguration erzielte 0,229 und ließ damit auf Ciscos Bewertung nur einen kleinen numerischen Abstand.

Die Parameterzahl allein bestimmte die Rangfolge nicht. Cisco berichtet, dass sein zwecktrainiertes 3B-Modell universelle Systeme mit mehr als 100 Milliarden Parametern erreichte oder übertraf.

Der größere Punkt ist nicht, dass ein 3B-Modell einem Frontier-System nun allgemein gleichwertig wäre. Das ist es nicht. Der Vergleich umfasst eine eingeschränkte Aufgabe, ein Test-Harness und eine Bewertungsmethode.

Cisco testete dieselben Gewichte später auf CyberGym Localization und einer öffentlichen Rekonstruktion der Sicherheitsbewertung von Cognition. Dieser Schritt ist wichtig, weil Modelle auf Benchmarks ihrer Entwickler oft am stärksten aussehen.

CyberGym umfasst rund 1.500 Schwachstellen aus 188 Open-Source-Projekten. Der vollständige Benchmark bewertet die Erstellung von Exploits, doch Cisco isolierte den früheren Schritt der Lokalisierung.

Antares-1B erreichte in diesem Lokalisierungstest einen Recall von 67,2 Prozent. Das unveröffentlichte 3B-Modell kam auf 73,7 Prozent, während das führende Frontier-Modell 89,1 Prozent erreichte.

Diese Zahlen zeigen sowohl Übertragbarkeit als auch eine fortbestehende Fähigkeitslücke. Die kleineren Modelle behielten auf einer externen Aufgabe nützliches Verhalten bei, erreichten jedoch nicht das beste Frontier-Ergebnis.

Ciscos externe Benchmark-Tests umfassten außerdem eine Community-Rekonstruktion der Sicherheitsbewertung von Cognition. Nur 34 der ursprünglichen 50 Testfälle waren öffentlich verfügbar.

Cisco schätzte die Ergebnisse dieses Vergleichs durch Extrapolation aus der öffentlichen Teilmenge. Das Unternehmen bezeichnete die Zahlen ausdrücklich als richtungsweisend und nicht als echte direkte Gegenüberstellung.

Dieser Vorbehalt ist entscheidend. Verschiedene Agenten können unterschiedliche Prompts, Befehlslimits, Infrastrukturen, Verfahren zur Kontextverwaltung und Abbruchregeln nutzen.

Selbst wenn zwei Systeme dasselbe Repository erhalten, kann das umgebende Harness ihre Ergebnisse erheblich beeinflussen. Agenten-Benchmarks messen eine Kombination aus Modell und System, nicht isolierte Intelligenz.

Dennoch bleibt das wirtschaftliche Argument plausibel. Ein lokales Modell vermeidet nutzungsabhängigen Tokenverbrauch und ermöglicht wiederholte Analysen, ohne Quellcode zu exportieren.

Das macht Spezialisierung für die Prüfung großer Mengen attraktiv. Ein größeres Modell kann sich dann mit der kleineren Gruppe von Repositories oder Dateien befassen, die eine tiefere Untersuchung erfordern.

Die wahrscheinliche Architektur ist daher hierarchisch. Günstige spezialisierte Modelle übernehmen die breite Lokalisierung, während teure Systeme und menschliche Experten mehrdeutige Fälle prüfen.

Dieser Ansatz spiegelt etablierte Sicherheitsabläufe wider. Unternehmen nutzen bereits kostengünstige automatisierte Kontrollen, um Aktivitäten zu filtern, bevor unsichere Befunde eskaliert werden.

Antares entfernt Frontier-Modelle nicht aus dem Prozess. Es verändert, an welcher Stelle Teams sie möglicherweise gezielt einsetzen.

Der Benchmark-Erfolg kommt mit einer Warnung

Ciscos stärkste Belege zeigen zugleich, warum Antares ohne umfassende lokale Validierung nicht zu einem Sicherheits-Gate werden darf.

Der Schlagzeilenvergleich zwischen Antares-3B und GPT-5.5 klingt beeindruckend. Die absoluten Werte zeichnen jedoch ein weniger beruhigendes Bild.

Das leistungsstärkste System auf VLoc Bench erreichte lediglich 0,229 File F1. File F1 kombiniert Präzision und Recall, wenn vorhergesagte Dateien mit den durch einen bekannten Patch geänderten Dateien verglichen werden.

Ein niedriger Wert kann auf übersehene relevante Dateien, irrelevante Vorschläge oder beides hinweisen. Jeder dieser Fehler verursacht zusätzliche Arbeit oder Risiken für das Sicherheitsteam, das das Ergebnis erhält.

Die veröffentlichten Ergebnisse des Benchmarks zeigen, dass 190 von 500 Aufgaben von keinem der bewerteten Modelle gelöst wurden. Das entspricht 38 Prozent des gesamten Datensatzes.

Die Leistung sank zudem um das Dreizehnfache, wenn man von den kleinsten zu den größten Repositories überging. Cisco kam zu dem Schluss, dass die strukturelle Komplexität Schwierigkeiten stärker vorhersagte als die Kategorie der Schwachstelle.

Dieses Ergebnis führt zur zentralen Umkehrung der Geschichte. Spezialisierung hilft kleinen Modellen, mit deutlich größeren zu konkurrieren, macht die Erkennung von Schwachstellen auf Repository-Ebene jedoch nicht zuverlässig.

Dieselbe Einschränkung zeigt sich an der Produktgrenze. Antares identifiziert Kandidatendateien, doch Analysten müssen weiterhin feststellen, ob die Schwachstelle tatsächlich besteht und ausnutzbar ist.

Ein Repository kann mehrere Implementierungen eines Musters enthalten. Generierter Code, Wrapper, Tests, eingebundene Abhängigkeiten und Kompatibilitätsschichten können die Suche verwirren.

Ein Sicherheits-Patch liefert außerdem nur eine unvollständige Form von Ground Truth. Maintainer ändern bisweilen unterstützende Dateien, die nicht unmittelbar verwundbar sind, oder lassen verwandte Fundstellen bei der ersten Korrektur aus.

Benchmarks können daher Übereinstimmung mit einem historischen Patch belohnen, ohne Sicherheitsverständnis vollständig zu messen. Sie bleiben nützlich, doch ihre Werte sollten nicht als universelle Erkennungsraten behandelt werden.

Ciscos externe Tests verringern Bedenken hinsichtlich vollständigen Benchmark-Overfittings. Sie ersetzen jedoch nicht die unabhängige Replikation in Unternehmens-Repositories.

Ein Unternehmen, das Antares einführt, sollte mit retrospektiven Fällen beginnen. Teams können zuvor behobene Schwachstellen bereitstellen und messen, ob das Modell die bekannten Dateien identifiziert.

Sie sollten außerdem irrelevante Vorschläge, übersehene Dateien, Befehlsnutzung, Laufzeit und die Prüfzeit der Analysten erfassen. Unterschiedliche Codebasen werden unterschiedliche Fehlermuster hervorbringen.

Das Kontextfenster des Modells garantiert kein vollständiges Verständnis des Repositories. Antares navigiert mittels Terminalbefehlen; sein Erfolg hängt daher davon ab, die richtigen Suchen und Belege auszuwählen.

Große Monorepositories stellen besondere Herausforderungen dar. Eine Beschreibung einer Schwachstelle kann sich über Services, generierte Clients, gemeinsam genutzte Bibliotheken und mehrere Implementierungssprachen hinweg erstrecken.

Der Benchmark bestätigt dieses Problem der Repository-Größe. Er legt zudem nahe, dass eine bloße Erhöhung der Parameterzahl nicht jedes strukturelle Hindernis beseitigen wird.

Sicherheitsverantwortliche sollten sich dagegen wehren, Modellvertrauen in Richtlinienautorität zu verwandeln. Antares sollte weder eigenständig einen Release blockieren, ein Schwachstellen-Ticket schließen noch einen Patch zertifizieren.

Eine vorsichtige Umsetzung würde seine Ausgabe als Empfehlung behandeln. Hoch eingestufte Dateien erhielten frühere menschliche Aufmerksamkeit, während herkömmliche Kontrollen weiterhin die breitere Codebasis untersuchen.

Unabhängige Berichterstattung kam zu einem ähnlichen Schluss. Eine Einschätzung zum Einsatz stellte fest, dass die Modelle weder Schwachstellen bestätigen noch Schweregrade zuweisen oder Korrekturen erzeugen.

Der Bericht hob zudem hervor, dass die Analyseumgebung isoliert werden muss. Lokale Ausführung hält Code vor Ort, sichert jedoch nicht automatisch das umgebende System.

Ein Modell mit Terminalzugriff interagiert weiterhin mit sensiblen Repositories und Inferenzabhängigkeiten. Administratoren benötigen Zugriffe nach dem Least-Privilege-Prinzip, Netzwerkbeschränkungen, Logs und verifizierte Modellartefakte.

Offene Gewichte schaffen Optionen für Prüfung und Bereitstellung. Sie bieten jedoch keine Garantie gegen Manipulation, unsichere Integrationen oder unangemessene Berechtigungen.

Offene Gewichte bedeuten kein uneingeschränktes Vertrauen

Cisco wägt breiteren defensiven Zugang gegen die Möglichkeit ab, dass Sicherheitsmodelle Angreifer unterstützen können.

Das Unternehmen bezeichnet Antares als Open Weight, weil qualifizierte Nutzer die trainierten Parameter erhalten können. Das Verhalten des Modells kann dann auf Infrastruktur außerhalb von Ciscos gehosteten Diensten ausgeführt werden.

Der Download der veröffentlichten Modelle erfordert jedoch Kontaktinformationen und eine Genehmigung. Cisco erklärte, den Zugang zu prüfen, um das Risiko zu verringern, dass Kriminelle die Werkzeuge erhalten.

Diese kontrollierte Verteilung verkompliziert die übliche Open-versus-Closed-Debatte. Antares bietet lokale Bereitstellung und überprüfbare Gewichte, ohne anonymen, sofortigen Zugang zu ermöglichen.

Cisco soll US-Regierungsbehörden zu Modellsicherheit und Veröffentlichungsentscheidungen konsultiert haben. Dies spiegelt den Dual-Use-Charakter der Schwachstellenforschung wider.

Ein Lokalisierungsmodell kann Verteidigern helfen, exponierten Code zu finden. Dieselbe Fähigkeit kann einem Angreifer helfen, die Suche nach einer bekannten Schwachstelle in einem verfügbaren Repository einzugrenzen.

Ciscos Modelle enden vor der Exploit-Generierung, doch diese Grenze beseitigt Missbrauch nicht. Das Auffinden der relevanten Datei ist oft ein wichtiger erster Schritt bei der Entwicklung eines Exploits.

Die Berichterstattung zur Veröffentlichung beschreibt Antares als Teil einer breiteren Bewegung hin zu offenen Sicherheitswerkzeugen. Capital One veröffentlichte im selben Zeitraum einen separaten, auf Schwachstellen fokussierten Agenten.

Offene Sicherheitsforschung bietet seit Langem Vorteile. Gemeinsame Regeln, Benchmarks und Testfälle ermöglichen es Verteidigern, Ergebnisse zu reproduzieren und Systeme zu vergleichen.

Sie erhöht auch die Prüfung. Forschende können Bewertungsfehler, verborgene Annahmen und unsichere Standardkonfigurationen erkennen, die ein geschlossener Dienst möglicherweise verbergen würde.

Das Risiko steigt, wenn Werkzeuge mehr Autonomie erhalten. Ein Modell, das nur Dateien einstuft, besitzt weniger Handlungsmacht als ein Agent, der Code ausführen, Netzwerke erreichen oder Repositories verändern darf.

Bereitstellungsteams sollten diese begrenzte Handlungsmacht bewahren. Schreibgeschützter Repository-Zugriff, Sandbox-Ausführung, begrenzte Befehle und überprüfbare Ablaufspuren sollten Standardkontrollen bleiben.

Ciscos breitere Forschung unterstreicht diese Vorsicht. Die Bewertung von 15 proprietären Frontier-Modellen ergab große Unterschiede zwischen Einzelturn- und adaptiven Multi-Turn-Angriffen.

Die Erfolgsraten bei Multi-Turn-Angriffen reichten von 7,89 Prozent bis 88,30 Prozent. Die Einzelturn-Raten innerhalb derselben Gruppe lagen zwischen 2,19 Prozent und 64,91 Prozent.

Die Multi-Turn-Forschung argumentiert, dass Sicherheitstests mit einem Prompt Angreifer nicht abbilden, die sich nach jeder Zurückweisung anpassen. Diese Erkenntnis gilt auch für defensive Agenten.

Ein Repository-Suchagent arbeitet über eine Abfolge von Beobachtungen und Aktionen. Die Prüfung einer einzelnen isolierten Ausgabe kann nicht jede unsichere Entwicklung oder jeden Berechtigungsfehler aufdecken.

Das macht die Antares-Benchmark-Strategie interessanter als die Modellveröffentlichung allein. Cisco entwickelt Modelle, aufgabenspezifische Bewertungen und Spezifikationen für kontrollierte Agentensysteme.

Diese Elemente ergeben ein Argument dafür, wie KI-Sicherheit eingekauft werden sollte. Käufer benötigen Belege zu definierten Workflows, Angriffsszenarien, Berechtigungen und Ausfallraten.

Eine Modellkarte oder allgemeine Rangliste kann diese operativen Fragen nicht beantworten. Ebenso wenig kann das eine positive Google-News-Schlagzeile.

Sicherheitsteams benötigen Bewertungsartefakte, die ihren Repositories und Beschränkungen ähneln. Sie benötigen außerdem Aufzeichnungen darüber, wann das Modell die Richtung änderte und warum es eine Datei auswählte.

Diese Belege können Audits und Incident-Reviews unterstützen. Sie können auch offenlegen, wenn ein Modell sich auf oberflächliche Namen statt auf bedeutungsvolle Codebeziehungen stützte.

Offene Gewichte erleichtern solche lokalen Tests. Kontrollierter Zugang begrenzt jedoch die Beteiligung der Community und kann unabhängige Replikationen verlangsamen.

Cisco muss zeigen, dass sein Prüfprozess legitimen Forschenden praktischen Zugang gewährt. Andernfalls bleiben die Aussagen über Offenheit enger, als das Label vermuten lässt.

Worauf Sicherheitsteams als Nächstes achten sollten

Die nächsten drei Signale werden entscheiden, ob spezialisierte Sicherheitsmodelle zu Infrastruktur werden oder beeindruckende Forschungsdemonstrationen bleiben.

Das erste Signal ist die unabhängige Replikation von Benchmarks. Forschende sollten Antares mit Repositories, Sprachen und Schwachstellenklassen testen, die Cisco nicht ausgewählt hat.

Ergebnisse außerhalb der Verteilung auf CyberGym liefern bereits nützliche Hinweise. Breitere Tests sollten Präzision, False Negatives, Laufzeit und Analystenaufwand unter konsistenten Harnesses messen.

Ein günstiges Ergebnis würde Ciscos Spezialisierungsthese stärken. Große Leistungseinbrüche würden darauf hindeuten, dass die Modelle benchmarkspezifische Suchmuster statt übertragbarer Untersuchungsfähigkeiten gelernt haben.

Das zweite Signal ist die Produktionsintegration. Antares wird operativ relevant, wenn Sicherheitsplattformen seine eingestuften Dateien in bestehende Untersuchungs- und Behebungsworkflows einordnen können.

Teams sollten auf Integrationen mit Continuous-Integration-Systemen, statischen Scannern, Plattformen für das Advisory-Management und standardisierten SARIF-Befunden achten. SARIF ist ein gängiges Format für den Austausch von Ergebnissen statischer Analysen.

Integration allein ist keine Einführung. Cisco oder seine Partner müssen zeigen, dass Analysten Untersuchungen schneller abschließen, ohne mehr übersehene Schwachstellen in Kauf zu nehmen.

Die nützlichsten Belege würden die Analystenzeit vor und nach der Bereitstellung vergleichen. Fallstudien sollten außerdem Repository-Größe, Sprachabdeckung und den Prozess der menschlichen Prüfung offenlegen.

Unternehmen, die Pilotprojekte durchführen, sollten eigene Bewertungsnotizen, Code-Kontext, Advisories und Entscheidungen der Prüfer aufbewahren. Eine durchsuchbare Wissensdatenbank kann Teams helfen, diese Belege über wiederholte Tests hinweg zu bewahren.

Das dritte Signal ist die Reaktion des Wettbewerbs. Microsoft, Google, OpenAI, Sicherheitsanbieter und Open-Source-Forschende erkunden allesamt spezialisierte Cybermodelle oder Agenten.

Beobachten Sie, ob sie auf Aufgabenebene Benchmarks mit reproduzierbaren Harnesses veröffentlichen. Beobachten Sie auch, ob ihre Systeme Lokalisierung, Verifizierung, Ausnutzung und Behebung voneinander trennen.

Eine klare Trennung würde Ciscos modulares Verständnis von Sicherheitsagenten unterstützen. Gebündelte Systeme mit durchgängig stärkeren End-to-End-Ergebnissen würden das Argument für ein dediziertes Lokalisierungsmodell schwächen.

Antares-3B ist ein weiterer konkreter Test innerhalb dieses Signals. Cisco nahm seine Ergebnisse auf, hatte seine Gewichte jedoch bei Veröffentlichung der Juli-Evaluierungen noch nicht freigegeben.

Sobald sie verfügbar sind, können unabhängige Forschende prüfen, ob sich seine nahezu führende Leistung im VLoc Bench auf unterschiedliche Repositories übertragen lässt. Sie können sein Verhalten zudem mit den veröffentlichten 350M- und 1B-Varianten vergleichen.

Sicherheitsverantwortliche sollten nicht auf einen universellen Sieger warten. Die bisherigen Erkenntnisse deuten bereits darauf hin, dass die Modellwahl von Aufgabenumfang, Datenschutzanforderungen, Repository-Komplexität und verfügbaren Prüfkapazitäten abhängen wird.

Google News wird diese Veröffentlichungen weiterhin auf Modellankündigungen und Benchmark-Ranglisten verdichten. Praktiker sollten eine schwierigere Frage stellen: Verringert das System verifizierte Sicherheitsarbeit, ohne neue Fehlermuster zu verschleiern?

Führen Sie einen klar abgegrenzten Pilotversuch anhand historischer Fälle durch, bewahren Sie jede Suchspur auf und vergleichen Sie die Ergebnisse mit Ihren bestehenden Kontrollen. Diese Evidenz wird zeigen, ob spezialisierte KI in Ihre Sicherheitspipeline gehört.