💻 computer science

Security in a Workflow: Exploring Role-Based Agentic Architectures for Vulnerability Handling

Dieses Paper schlägt einen rollenbasierten agentischen Workflow vor und evaluiert diesen, welcher aus den Agenten Planner, Analyzer, Fixer und Verifier besteht, um die Lücke zwischen isolierten LLM-Sicherheitsaufgaben und realen industriellen Praktiken zu schließen, wobei eine Genauigkeit der Schwachstellenerkennung von 44 % und eine Korrekturgenauigkeit von 19 % bei 25 realen C/C++-Schwachstellen nachgewiesen wird.

Ursprüngliche Autoren: Srijita Basu, Miroslaw Staron

Veröffentlicht 2026-06-15

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Srijita Basu, Miroslaw Staron

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie versuchen, ein sehr altes, komplexes Haus (ein Softwareprogramm in C oder C++) zu reparieren, das versteckte Risse und Schwachstellen (Sicherheitslücken) aufweist. In der Vergangenheit hätten Sie vielleicht einen einzelnen, superintelligenten Detektiv (eine Standard-KI) engagiert, um das Haus zu untersuchen, die Risse zu finden und zu versuchen, sie alle auf einmal zu flicken. Manchmal hat dieser Detektiv es richtig gemacht, aber oft war er überfordert, übersah subtile Hinweise oder flickte die falsche Wand.

Dieses Paper schlägt einen anderen Ansatz vor: das Einstellen eines spezialisierten Teams von Agenten anstatt eines einsamen Detektivs. Sie arbeiten gemeinsam in einer strengen Fließbandarbeit, bei der jeder eine spezifische Aufgabe hat.

So funktioniert das Team, basierend auf den Ergebnissen des Papers:

1. Die Rollen des Teams (Der „Agentic Workflow“)

Die Forscher haben ein digitales Team mit vier unterschiedlichen Rollen aufgebaut, ähnlich einer Baucrew:

Der Planer (Der Bauleiter): Bevor überhaupt jemand anfängt zu graben, scannt dieser Agent die Baupläne (den Code), um offensichtliche Schwachstellen zu entdecken. Er repariert nichts; er zeigt dem Team nur die Bereiche auf, die verdächtig aussehen, wie zum Beispiel: „Überprüfe die Hintertür“ oder „Schau dir das Fundament an.“
- Wichtigste Erkenntnis: Das Paper fand heraus, dass das Vorhandensein dieses „Bauleiters“ entscheidend war. Als sie diese Rolle entfernten, sank die Fähigkeit des Teams, Probleme zu finden, um fast die Hälfte.
Der Analysator (Der Inspektor): Dies ist der Hauptdetektiv. Er nimmt die Hinweise vom Planer und den rohen Code, um genau zu verstehen, was kaputt ist, warum es kaputt ist und wie ein Einbrecher hineinkommen könnte.
- Wichtigste Erkenntnis: Die Forscher versuchten, diesem Agenten einen hochmodernen Metalldetektor (ein Werkzeug namens CodeQL) zu geben, um ihm beim Finden von Rissen zu helfen. Überraschenderweise half der Metalldetektor nicht immer. Manchmal löste er zu viele Fehlalarme aus, was den Inspektor verwirrte. Die besten Ergebnisse wurden erzielt, wenn das KI-Modell selbst das tiefe Denken übernahm, anstatt sich stark auf das zusätzliche Werkzeug zu verlassen.
Der Fixer (Der Reparateur): Sobald der Inspektor sagt: „Der Türrahmen ist morsch“, versucht der Fixer, eine neue Tür zu bauen. Er schreibt den Code, um das Loch zu flicken.
- Wichtigste Erkenntnis: Dies war der schwierigste Job. Während das Team beim Finden der Probleme recht gut war (etwa 44 % Genauigkeit), war das tatsächliche korrekte Reparieren viel schwieriger (nur etwa 19 % Genauigkeit). Oft flickte der Fixer zwar das Loch, beschädigte aber versehentlich etwas anderes in der Nähe oder fügte unnötige Teile hinzu.
Der Verifizierer (Der Sicherheitsinspektor): Nachdem die Reparatur abgeschlossen ist, überprüft dieser Agent die Arbeit. Er fragt: „Hast du den Verfall tatsächlich behoben? Hast du das Haus sicherer gemacht oder nur den Riss übermalt?“
- Wichtigste Erkenntnis: Diese Rolle war ziemlich gut darin, Fehler aufzuspüren, und entdeckte etwa 69 % der Fehler in den Reparaturen.

2. Das Experiment

Die Forscher testeten dieses Team an 25 realen Sicherheitslücken, die in populärer C/C++-Software gefunden wurden (wie sie etwa in sicherheitskritischen Systemen verwendet wird). Sie nutzten drei verschiedene „Gehirne“ (KI-Modelle), um die Teammitglieder anzusteuern.

Sie verglichen zwei Versionen des Teams:

Team A: Nur die vier Rollen, die miteinander kommunizieren.
Team B: Dieselben vier Rollen, aber der Inspektor erhielt den CodeQL-Metalldetektor, um ihm beim Finden der Risse zu helfen.

3. Was sie herausfanden

Der „Manager“ ist am wichtigsten: Der wichtigste Teil des Prozesses war der Planer. Ohne einen Manager, der das Team leitet, wo es suchen soll, verlor sich die KI. Mit dem Manager erreichte das Team beim Finden der Bugs eine Leistung, die der einer Top-kommerziellen KI (GPT-5.5) entspricht.
Werkzeuge sind keine Magie: Dem Inspektor ein schickes Werkzeug (CodeQL) zu geben, machte ihn nicht automatisch besser. Tatsächlich machte es die Sache manchmal sogar schlechter, weil die KI Schwierigkeiten hatte, die Daten des Werkzeugs korrekt zu interpretieren. Das Paper legt nahe, dass die KI bei niederschwelligen Programmiersprachen (wie C) klug genug sein muss, die Hinweise selbst zu priorisieren.
Finden vs. Fixen: Es ist viel einfacher für eine KI, eine Sicherheitslücke zu finden, als sie zu beheben. Das Team fand die Bugs etwa 44 % der Zeit, konnte sie aber nur in 19 % der Fälle korrekt reparieren.
Die menschliche Komponente ist weiterhin notwendig: Da der „Reparateur“ (Fixer) oft Fehler machte oder unnötige Änderungen vornahm, kommt das Paper zu dem Schluss, dass man in der realen Sicherheit die KI nicht einfach das Ruder übernehmen lassen kann. Man braucht einen Menschen, der der KI über die Schulter schaut, die Reparaturen prüft und sicherstellt, dass das Haus tatsächlich sicher ist.

Das Fazit

Dieses Paper behauptet nicht, dass KI nun in der Lage ist, Software eigenständig perfekt abzusichern. Stattdessen zeigt es, dass die Organisation von KI in ein strukturiertes Team mit klaren Rollen ein besserer Weg ist, um Sicherheitsfragen zu handhaben, als eine einzige KI alles machen zu lassen. Dennoch bleibt selbst mit einem großartigen Team der Teil des „Reparierens“ schwierig, und menschliche Experten sind weiterhin essenziell, um die Arbeit zu verifizieren.

Technisches Resümee: Sicherheit in einem Workflow – Untersuchung rollenbasierter agentischer Architekturen für die Schwachstellenbehandlung

Problemstellung

Sichere Softwareentwicklung in der industriellen Praxis umfasst einen strukturierten, mehrstufigen Workflow, der aus Schwachstellenanalyse, Behebung und Fix-Verifizierung besteht. Aktuelle auf Large Language Models (LLM) basierende Ansätze zur Softwaresicherheit sind jedoch oft fragmentiert und konzentrieren sich auf isolierte Aufgaben wie Detektion oder Patch-Generierung, anstatt die End-to-End-agentischen Workflows abzubilden, die in realen Sicherheitsprozessen verwendet werden. Dies schafft eine Lücke zwischen bestehenden LLM-Methoden und der praktischen sicheren Softwareentwicklung, insbesondere für Low-Level-Systemsprachen wie C und C++. In diesen Sprachen hängen Schwachstellen von komplexen Speichersemantiken, Zeigermanipulationen und Pufferverwaltung ab, was die Diagnose und Behebung für LLMs erschwert. Darüber hinaus gibt es eine begrenzte Untersuchung von werkzeugaugmentierten agentischen Workflows und der Integration von Model Context Protocol (MCP)-Skills speziell für diese Low-Level-Kontexte.

Methodik

Die Autoren schlagen einen rollenbasierten agentischen Workflow vor und evaluieren diesen, der die Schwachstellenbehandlung in explizite Phasen unterteilt: Untersuchungsplanung, Schwachstellenanalyse, Patch-Generierung und Fix-Verifizierung.

Workflow-Design

Die Studie implementiert zwei Workflow-Varianten unter Verwendung des CrewAI-Frameworks, instanziiert mit drei Open-Source-LLMs: nemotron-cascade-2:30b, qwen3-coder-next und gpt-oss:120b. Die Workflows bestehen aus vier distinkten Rollen:

Planner (Planer): Ein regelbasierter statischer Modul (kein LLM), der den Eingabe-C-Code nach vordefinierten Schwachstellenmustern (z. B. Pufferüberläufe, Nullpointer-Dereferenzierungen) mittels regulärer Ausdrücke scannt. Er gibt priorisierte Untersuchungsregionen und Themen aus, um den Analyzer zu leiten.
Analyzer (Analysator): Ein LLM-Agent, der für die technische Diagnose verantwortlich ist. Er bestimmt die primäre Schwachstelle, weist die entsprechende Common Weakness Enumeration (CWE) ID zu, identifiziert die vulnerablen Zeilen, erklärt die Ursache und verfolgt den Source-to-Sink-Fluss.
- Workflow 1: Der Analyzer verlässt sich ausschließlich auf die Anleitung des Planners.
- Workflow 2: Der Analyzer wird durch eine MCP-CodeQL-Integration ergänzt, die während der Diagnose statische Analysefähigkeiten bereitstellt.
Fixer (Beheber): Ein LLM-Agent, der basierend auf der Diagnose des Analyzers einen minimalen, sicheren Patch generiert. Er ist darauf beschränkt, den Patch und eine prägnante Erklärung zu produzieren, um eine erneute Diagnose zu vermeiden.
Verifier (Verifizierer): Ein unabhängiger LLM-Agent, der bewertet, ob der generierte Patch die identifizierte Schwachstelle behebt, die Ursache entfernt und keine Regressionen einführt.

Experimenteller Aufbau

Datensatz: Ein kuratierter Satz von 25 realen C/C++ Common Vulnerabilities and Exposures (CVEs), die fünf CWE-Kategorien abdecken: CWE-787 (Out-of-bounds Write), CWE-476 (Null Pointer Dereference), CWE-190 (Integer Overflow), CWE-125 (Out-of-bounds Read) und CWE-191 (Integer Underflow).
Ground Truth (Referenzwert): Abgeleitet aus NVD-Beschreibungen (National Vulnerability Database) und von Entwicklern bereitgestelltem behobenem Code.
Evaluierung: Manuelle, rubrikbasierte Bewertung durch zwei Autoren (Cohen's Kappa $\kappa = 0,83$ ), welche die Agenten-Outputs mit der Ground Truth vergleicht. Zu den Metriken gehörten die Detektionsgenauigkeit (CWE-Zuweisung, Zeilenidentifikation, Ursachenanalyse) und die Fix-Genauigkeit (semantische Ähnlichkeit zu vertrauenswürdigen Fixes).
Umfang: Die Studie ist eine explorative, methodenorientierte Untersuchung statt eines groß angelegten Benchmarks, wobei der Fokus auf 150 Workflow-Ausführungen liegt (25 CVEs $\times$ 3 Modelle $\times$ 2 Varianten).

Zentrale Beiträge

Rollenbasierte agentische Architektur: Vorschlag und Evaluierung eines End-to-End-Workflows, der Planung, Analyse, Behebung und Verifizierung trennt, um zu zeigen, wie eine explizite Rollentrennung Sicherheitsaktivitäten strukturieren kann.
Design des statischen Planners: Implementierung eines regelbasierten Planers zur Leitung der Schwachstellenuntersuchung in industrie-relevanten C-Projekten, was dessen kritischen Einfluss auf die Qualität der Detektion zeigt.
Kuratierter Referenzsatz: Bereitstellung von 25 realen C/C++ Schwachstelleninstanzen mit Ground-Truth-Metadaten, Entwickler-Fixes und LLM-generierten Outputs sowie dem Open-Source CrewAI-Framework-Code zur Reproduzierbarkeit.
Analyse der Werkzeugintegration: Untersuchung der Wirksamkeit der Integration von MCP-basierter statischer Analyse (CodeQL) in die Analysephase eines Multi-Agenten-Workflows.

Ergebnisse

Die Studie berichtet die folgenden Leistungsmetriken (unter Verwendung von nemotron-cascade-2:30b als primäres Modell für den Vergleich):

Detektionsgenauigkeit:
- Workflow 1 (Ohne CodeQL): Erreichte eine Detektionsgenauigkeit von 44%, vergleichbar mit GPT-5.5 Baselines.
- Workflow 2 (Mit CodeQL): Die Genauigkeit sank auf 31%, was darauf hindeutet, dass die Tool-Integration allein keine Verbesserung garantiert, wenn der Agent die Tool-Hinweise nicht korrekt interpretieren oder priorisieren kann.
- Ablation: Das Entfernen des Planners reduzierte die Detektionsgenauigkeit auf 25% (ohne CodeQL) und 19% (mit CodeQL), was die kritische Rolle des Planners unterstreicht.
Fix-Genauigkeit:
- Die allgemeine Fix-Genauigkeit war mit 19% für Workflow 1 und 13% für Workflow 2 gering.
- Die Reparatur erwies sich als signifikant schwieriger als die Detektion. Während einige Patches „vergleichbar“ oder sogar „besser“ als die Ground Truth waren (insbesondere bei CWE-476 und CWE-787), enthielten viele unnötige Logik oder führten neue Bugs ein.
Verifier-Genauigkeit:
- Der Verifier erreichte eine Genauigkeit von 69% mit nemotron-cascade-2:30b, was auf eine stärkere Fähigkeit in der Post-Remediation-Bewertung im Vergleich zur Generierung hindeutet.
CWE-Variabilität: CWE-787 und CWE-476 waren am einfachsten zu detektieren, während CWE-191 (Integer Underflow) über alle Modelle und Einstellungen hinweg am schwierigsten blieb.

Bedeutung und Behauptungen

Das Paper positioniert diese Arbeit als eine erste explorative Studie und nicht als einen definitiven Benchmark. Die primäre Bedeutung liegt in:

Prozessverbesserung: Demonstration, dass die Zerlegung von Sicherheitsaufgaben in strukturierte, rollenbasierte Phasen (Planung, Analyse, Behebung, Verifizierung) Sicherheitsaktivitäten reproduzierbarer und transparenter machen kann.
Notwendigkeit des Human-in-the-Loop: Bestätigung, dass trotz Fortschritten bei LLMs die ungleichmäßige Qualität generierter Patches und die gemischte Wirksamkeit der Tool-Integration die fortgesetzte menschliche Aufsicht in sicherheitskritischen Umgebungen notwendig machen.
Workflow vor Modell: Verschiebung des Fokus von der Auswahl des „besten“ Modells hin zur Verfeinerung der zugrunde liegenden Workflow-Architektur und der Integrationstechniken. Die Autoren stellen fest, dass während das Modell-Screening essenziell ist, das Workflow-Design der primäre Hebel zur Verbesserung ist.
Nuancierte Tool-Integration: Hervorhebung, dass die Integration von Tools wie CodeQL ein sorgfältiges Agenten-Design erfordert, um sicherzustellen, dass Hinweise korrekt priorisiert werden; das bloße Hinzufügen von Tools verbessert die Leistung nicht automatisch.

Die Autoren kommen zu dem Schluss, dass rollenbasierte agentische Architekturen ein vielversprechender Weg zur Verbesserung sicherer Softwareprozesse sind, was zukünftige Arbeiten zu größeren Datensätzen, Repository-Level-Analysen und verfeinerten Workflow-Alternativen (z. B. mehrere Analysatoren, Verfeinerungsschleifen) motiviert.