Cisco Antares im Test: Lokale Schwachstellen-Triage ohne Code in die Cloud zu schicken

Cisco Antares ist kein autonomer Schwachstellen-Scanner, kein Patch-Generator und kein billiger Ersatz für einen Penetrationstest. Es ist ein kleines Open-Weight-Security-Modell für eine engere, wirtschaftlich nützliche Frage: Welche Dateien sollte ein Security Engineer zuerst prüfen, wenn Antares eine CWE-Beschreibung und read-only Zugriff auf ein Repository erhält?

Genau dieser enge Scope macht Antares interessant. Das veröffentlichte Antares-1B-Modell hat eine Milliarde Parameter, steht unter Apache 2.0, braucht weder Vektordatenbank noch externes Retrieval und kann hinter einem lokalen OpenAI-kompatiblen Endpoint laufen. Eine Community-Konvertierung als Q8_0 GGUF ist rund 1,96 GB groß und läuft mit llama.cpp. Damit wird eine private Triage-Spur für proprietären Code auf Workstations und kleinen On-Device-Systemen realistisch.

Der Haken gehört in denselben Absatz: Das beste Modell in Ciscos eigenem Benchmark erreicht nur 0,229 File F1. 190 von 500 Aufgaben werden von keinem getesteten Modell gelöst. Antares grenzt die Suche ein. Es beweist nicht, dass ein Repository sicher ist.

Was ist Cisco Antares?

Cisco Foundation AI stellte Antares am 21. Juli 2026 als Familie sicherheitsfokussierter Small Language Models vor. Antares-350M und Antares-1B sind öffentlich verfügbar. Antares-3B steht im technischen Report und Benchmark, wurde beim Launch aber noch als kommend bezeichnet.

Die Modelle basieren auf IBM Granite 4.0. Cisco trainiert darauf Cybersecurity Reasoning, Deep Research, Terminal-Nutzung und Code-Suche per Supervised Fine-Tuning. Danach optimiert Group Relative Policy Optimization komplette Such-Trajektorien durch Repositories. Vereinfacht gesagt lernt Antares nicht nur Begriffe aus der Security, sondern auch suchen, Dateien prüfen, schwache Spuren verwerfen und unter einem knappen Tool-Budget Pfade abgeben.

Der technische Antares-Report beschreibt eine read-only Repo-Umgebung ohne Netzwerk und mit maximal 15 Terminal-Kommandos. Das Modell erhält CWE-ID und generische Kategorienbeschreibung, nutzt Such- und Dateiwerkzeuge und liefert wahrscheinliche Implementierungsdateien oder meldet, dass es keine Schwachstelle gefunden hat.

Was bedeutet Vulnerability Localization?

Vulnerability Detection fragt, ob eine Schwachstelle existiert. Vulnerability Localization fragt, wo die relevante Implementierung liegt. Nach einem neuen Advisory kennt das Security-Team vielleicht die CWE-Schwächenklasse, verbringt aber trotzdem Stunden damit, CVE oder GitHub Security Advisory durch Wrapper, Adapter, Framework-Konventionen und Call Paths zu verfolgen.

Antares automatisiert den ersten Ausgrabungsschritt:

1. Mit einer begrenzten Hypothese beginnen. Übergib CWE und Beschreibung, nicht den vagen Auftrag, alle Bugs zu finden.
2. Repository erkunden. Das Modell sucht Muster, öffnet Kandidaten, folgt Imports und ändert seine Hypothese.
3. Kandidatendateien abgeben. Das Ergebnis ist eine priorisierte Review-Queue, kein Befund.
4. An deterministische Checks und Menschen übergeben. Engineers bestätigen Reachability, Exploitability, betroffene Versionen, Severity und Fix.

Dieser Scope konkurriert nicht mit unserem breiteren QA-Prozess für KI-generierten Code. Dort geht es um Autorisierung, Inputs, Secrets, Last, Concurrency, Dependencies und Regressionstests. Antares besitzt einen Schritt darin: lokale Kandidatendateien aus Security-Beschreibungen finden.

Wie gut ist Antares im Benchmark?

Der neue Vulnerability Localization Benchmark enthält 500 Aufgaben aus 290 echten Repositories, sechs Paket-Ökosystemen und 147 CWE-Kategorien. Jede Aufgabe rekonstruiert den Stand vor dem Security Fix. Die tatsächlich geänderten Implementierungsdateien bilden die Ground Truth. Modelle sehen nur eine generische CWE-Beschreibung und dürfen 15 Terminal Calls machen.

Die Headline stimmt: Spezialisierung lässt ein 1B-Modell auf diesem Harness viel größere Generalisten schlagen. Die falsche Lesart wäre, Antares finde 20,9 Prozent der Schwachstellen. File F1 kombiniert Precision und Recall auf Dateiebene in einem Benchmark, in dem jedes Phase-A-Repository garantiert eine Schwachstelle enthält. Das ist keine End-to-End Detection Rate in normalem Code.

Die Grenzen entscheiden über den Einkauf. Cisco meldet deutliche Einbrüche über 10 MB, Probleme bei Schwachstellen über fünf oder mehr Dateien und bessere Resultate bei markanten grep-fähigen Mustern als bei Berechtigungen, Locking oder Memory Leaks. Der Trainings-Cutoff ist der 10. April 2025. Das Modell erklärt außerdem nicht, warum eine Datei verwundbar ist, erzeugt keinen Exploit und schreibt keinen Patch.

Was ändert sich mit GGUF und llama.cpp?

Der offizielle Cisco Release liefert Transformers-kompatible Gewichte und eine CLI für einen frei konfigurierbaren OpenAI-kompatiblen Inference-Endpoint. llama.cpp stellt genau so einen lokalen Server bereit. Die Community-Konvertierung packt das 1B-Modell als rund 1,96 GB großes Q8_0 GGUF. Architektonisch passen die Teile zusammen.

Ein praktisches Setup kann Antares auf einem kompakten GB10-System neben einem größeren Coding-Modell laufen lassen. Ein schlanker Agent Skill treibt dann die Antares-CLI oder ihr Protokoll: Repo-Snapshot und CWE hinein, JSON oder SARIF heraus, Kandidatendateien zur Prüfung an den Hauptagenten. Weil Antares klein ist, muss es die Hardware des großen Assistenten nicht dauerhaft blockieren.

• Der offizielle Benchmark ist kein GGUF-Benchmark. Cisco berichtet rund 13 bis 15 Minuten für 500 Tasks auf einer H100 mit Parallelisierung. Daraus folgt keine GB10- oder llama.cpp-Latenz.
• Q8_0-Parität ist nicht belegt. Bis 22. Juli 2026 fanden wir keinen publizierten VLoc-A/B-Test der Originalgewichte gegen das GGUF.
• Das Community-Artefakt ist kein offizieller Cisco Release. Datei, Hash, Quellrevision und eigene historische Tests gehören in den Pilot.

Wie gehört Antares in Shift-left CI/CD?

1. Mit einem Security-Anlass starten. Nutze eine gemappte CWE aus CVE oder GHSA, eine gezielte Kampagne oder einen kleinen Satz Schwächenklassen. Kein “finde alle Schwachstellen”.
2. Read-only Snapshot bauen. Mounte nur Repository und nötige Metadaten in einen Container ohne Netzwerk. Secrets, Build Credentials und Kundendaten bleiben draußen.
3. Relevanten Slice prüfen. Bevorzuge geänderten Service oder Dependency Boundary. Das respektiert das 15-Command-Budget.
4. JSON und SARIF ausgeben. Die CLI unterstützt beides. GitHub importiert SARIF von Drittwerkzeugen als Code-Scanning-Alerts.
5. Menschliche Bestätigung verlangen. Ein Kandidat wird erst nach bestätigtem Verhalten zum Finding.
6. Akzeptierte Outcomes messen. Precision, Recall auf bekannten Fällen, Zeit bis zur ersten relevanten Datei, Review-Minuten und stille Misses zählen.

Erst wenn eigene Daten für eine konkrete Kategorie überzeugen, darf Antares ein blockierendes Gate werden. Auch dann braucht es einen benannten Bypass mit Audit Trail.

Wie unterstützt Antares CVE- und GHSA-Untersuchungen?

Antares macht kein externes Retrieval. Das ist Privacy-Vorteil und Workflow-Grenze zugleich. Es holt kein aktuelles Advisory und sollte wegen des Cutoffs auch nicht aus Erinnerung dazu befragt werden.

1. CVE oder GHSA in einem getrennten, kontrollierten Intake abrufen.
2. Komponente, Versionsbereich, CWE-Mapping und Advisory-Text verifizieren.
3. Nur geprüfte CWE-Beschreibung und freigegebenen Kontext an Antares geben.
4. Kandidatendateien für Source Review, Dependency Tracing und Patch-Verifikation priorisieren.
5. Advisory-Revision, Modell-Hash, Prompt, Repo-Commit, Trace und Review-Entscheidung protokollieren.

Macht lokale Inference den Workflow sicher?

Lokal ist eine sinnvolle Datengrenze, kein Sicherheitszertifikat. Die Model Card empfiehlt isolierte Sandbox, deaktiviertes Netzwerk, Zugang nur für autorisiertes Security-Personal, vollständige Trajectory-Logs und Human Oversight. Diese Controls zählen, weil das Modell ein Terminal bedient und keine eigenständige Conversational-Safety-Ausrichtung erhielt.

Der GGUF-Pfad ergänzt eine Supply-Chain-Grenze. llama.cpp veröffentlichte Security Advisories zu bösartigen Modelldateien, darunter einen Buffer Overflow durch ein manipuliertes GGUF-Vokabular. Runtime aktuell halten, Datei und Hash pinnen und nicht vertrauenswürdige Gewichte nur gehärtet laden.

Prüfe auch Crash Reporting, Paketinstallation, Remote Logs, CI-Artefakte, SARIF-Upload und den Hauptagenten, der Resultate übernimmt. Ein lokales Modell schützt keinen Code, den das Harness an anderer Stelle versendet.

Was Antares ergänzt, aber nicht ersetzt

Für autonome Red-Team-Harnesses besitzt unser T3MP3ST Review die separate Suchintention. Für die Wirtschaftlichkeit lokaler Modelle gegen APIs gilt unser Break-even-Guide für lokale Modelle. Antares bleibt bei lokaler Vulnerability Localization.

Ein kommerzieller 14-Tage-Pilot

1. 25 historische Untersuchungen wählen. Pre-fix und patched Snapshots, Single- und Multi-File, kleine und große Repos und langsame Alt-Fälle.
2. Stack einfrieren. Quellrevision, GGUF-Hash, llama.cpp Build, CLI-Version, Prompt, Tool-Budget und Hardware festhalten.
3. Blind testen. Patchdateien und bekannte Orte bleiben Modell und Erstprüfer verborgen.
4. Mit Baseline vergleichen. Antares plus Analyst gegen den heutigen SAST-plus-Analyst-Prozess messen.
5. Go/No-go festlegen. Kürzere mediane Triage, kein unvertretbarer Critical Miss, prüfbare Traces und tragbare False Positives verlangen.

Die Entscheidungsmetrik ist nicht Tokens pro Sekunde. Sie lautet Analystenminuten pro korrekt lokalisierter Untersuchung, mit False Negatives direkt daneben.

Own your AI, inklusive der langweiligen Teile

Die Gewichte zu besitzen ist ein Anfang. Operative Ownership umfasst Inference-Endpoint, Repo-Grenze, Logs, Updates von Modell und Runtime, Eval-Set, Failure Policy und Exit-Pfad. Ein Modell auf dem Schreibtisch mit stiller Vendor-Abhängigkeit ist nicht vollständig lokal. Ein lokales Modell ohne Benchmark ist noch kein kontrolliertes Produktionssystem.

Cloud AI optimiert für das Unternehmen, das die Cloud betreibt. Das kann die richtige Entscheidung sein, wenn Capability, Support und Tempo schwerer wiegen als Datengrenze und Portabilität. Der Fehler liegt darin, Vendor-Alignment mit dem eigenen gleichzusetzen. Antares macht eine Alternative praktikabel: Die enge Security-Aufgabe, den Code und die Evidenz in einer selbst kontrollierten Grenze halten.

Primärquellen und Prüfdatum

• Launch-Post von Cisco Foundation AI
• Technischer Antares-Report
• Offizielle Antares-1B Model Card
• VLoc-Bench-Methodik und Ergebnisse
• llama.cpp Repository

Status, Model Cards, Benchmarks, Lizenzen und Security Advisories wurden am 22. Juli 2026 geprüft. Der Review ist unabhängig und nicht gesponsert. Wir haben weder Ciscos H100-Benchmark reproduziert noch einen GGUF-Paritätslauf publiziert.