💻 computer science

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

Dit artikel stelt een op rollen gebaseerde agentische workflow voor en evalueert deze, bestaande uit Planner-, Analyzer-, Fixer- en Verifier-agents, om de kloof tussen geïsoleerde LLM-beveiligingstaken en de praktijk in de echte industrie te overbruggen, waarbij een detectie-accuratesse van 44% voor kwetsbaarheden en een fix-accuratesse van 19% wordt aangetoond op 25 real-world C/C++ kwetsbaarheden.

Oorspronkelijke auteurs: Srijita Basu, Miroslaw Staron

Gepubliceerd 2026-06-15

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Srijita Basu, Miroslaw Staron

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een heel oud, complex huis probeert te repareren (een softwareprogramma geschreven in C of C++) met verborgen scheuren en zwakke plekken (beveiligingskwetsbaarheden). In het verleden had je misschien één slimme detective ingehuurd (een standaard AI) om naar het huis te kijken, de scheuren te vinden en ze allemaal tegelijk te proberen te dichten. Soms kreeg deze detective het goed, maar vaak raakte hij overweldigd, miste hij subtiele aanwijzingen of dichtte hij de verkeerde muur af.

Dit artikel stelt een andere aanpak voor: het inhuren van een gespecialiseerd team van agenten in plaats van één eenzame detective. Ze werken samen in een strikte lopende band, waarbij iedereen een specifieke taak heeft.

Hier is hoe het team werkt, gebruikmakend van de bevindingen uit het artikel:

1. De Teamrollen (De "Agentic Workflow")

De onderzoekers zetten een digitaal team op met vier verschillende rollen, vergelijkbaar met een bouwploeg:

De Planner (De Projectleider): Voordat iemand begint met graven, scant deze agent de blauwdrukken (de code) om duidelijke probleemgebieden te spotten. Deze agent repareert niets; hij wijst het team alleen naar de gebieden die er verdacht uitzien, zoals "Controleer de achterdeur" of "Kijk naar de fundering."
- Belangrijkste bevinding: Het artikel stelde vast dat het hebben van deze "Projectleider" cruciaal was. Wanneer zij deze rol verwijderden, daalde het vermogen van het team om problemen te vinden met bijna de helft.
De Analyzer (De Inspecteur): Dit is de hoofddetective. Zij nemen de aanwijzingen van de Planner en de ruwe code en om uit te zoeken wat er precies kapot is, waarom het kapot is en hoe een inbreker naar binnen zou kunnen komen.
- Belangrijke bevinding: De onderzoekers probeerden deze agent een hoogtechnologische metaaldetector te geven (een tool genaamd CodeQL) om te helpen bij het vinden van scheuren. Verrassend genoeg hielp de metaaldetector niet altijd; soms gaf het te veel valse meldingen, wat de Inspecteur in verwarring bracht. De beste resultaten kwamen voort uit het feit dat het AI-model zelf diep nadacht, in plaats van zwaar te vertrouwen op de extra tool.
De Fixer (De Reparateur): Zodra de Inspecteur zegt: "Het deurkozijn is aan het rotten," probeert de Fixer een nieuwe deur te bouwen. Zij schrijven de code om het gat te dichten.
- Belangrijkste bevinding: Dit was de moeilijkste taak. Hoewel het team redelijk was in het vinden van het probleem (ongeveer 44% accuraat), was het daadwerkelijk correct repareren veel moeilijker (slechts 19% accuraat). Vaak dichtte de Fixer wel het gat, maar maakte hij per ongelage iets anders in de buurt kapot of voegde onnodige onderdelen toe.
De Verifier (De Veiligheidsinspecteur): Nadat de reparatie is voltooid, controleert deze agent het werk. Zij vragen: "Heb je het rot echt gerepareerd? Heb je het huis veiliger gemaakt, of heb je alleen de scheur overgeschilderd?"
- Belangrijkste bevinding: Deze rol was vrij goed in het opsporen van fouten en ontdekte ongeveer 69% van de fouten in de reparaties.

2. Het Experiment

De onderzoekers testten dit team op 25 echte beveiligingslekken die werden gevonden in populaire C/C++ software (zoals software die wordt gebruikt in veiligheidskritische systemen). Ze gebruikten drie verschillende "hersenen" (AI-modellen) om de teamleden aan te sturen.

Ze vergeleken twee versies van het team:

Team A: Alleen de vier rollen die met elkaar communiceren.
Team B: Dezelfde vier rollen, maar de Inspecteur kreeg de CodeQL metaaldetector om de scheuren te helpen vinden.

3. Wat ze ontdekten

De "Manager" is het belangrijkst: Het belangrijkste deel van het proces was de Planner. Zonder een manager om het team te begeleiden waar ze moesten kijken, raakte de AI de weg kwijt. Met de manager presteerde het team net zo goed als een top-tier commerciële AI (GPT-5.5) bij het vinden van de bugs.
Tools zijn geen wondermiddel: Het geven van een fancy tool (CodeQL) aan de Inspecteur maakte hen niet automatisch beter. Sterker nog, het maakte het soms erger omdat de AI moeite had met het interpreteren van de gegevens van de tool. Het artikel suggereert dat voor programmeertalen op laag niveau (zoals C), de AI slim genoeg moet zijn om de aanwijzingen zelf te prioriteren.
Vinden versus Vinden: Het is veel makkelijker voor AI om een beveiligingslek te vinden dan om het te repareren. Het team vond de bugs ongeveer 44% van de tijd, maar repareerde ze slechts 19% van de tijd correct.
De menselijke touch is nog steeds nodig: Omdat de "Reparateur" (Fixer) vaak fouten maakte of onnodige wijzigingen aanbracht, concludeert het artikel dat je in echte beveiliging niet de AI het volledige proces kunt laten beheren. Je hebt een mens nodig die over de schouder van de AI meekijkt, de reparaties controleert en zeker weet dat het huis daadwerkelijk veilig is.

De Kernboodschap

Dit artikel beweert niet dat AI nu in staat is om software volledig zelfstandig te beveiligen. In plaats daarvan laat het zien dat het organiseren van AI in een gestructureerd team met duidelijke rollen een betere manier is om met beveiliging om te gaan dan één AI alles te laten doen. Echter, zelfs met een geweldig team blijft het "repareren" een lastig onderdeel, en zijn menselijke experts essentieel om het werk te verifiëren.

Technische Samenvatting: Beveiliging in een Workflow – Onderzoek naar Role-Based Agentic Architecturen voor Kwetsbaarheidsafhandeling

Probleemstelling

Veilige software engineering in de industriële praktijk omvat een gestructureerde, meerfasige workflow bestaande uit kwetsbaarheidsanalyse, remediëring en fix-verificatie. De huidige op Large Language Models (LLM)-gebaseerde benaderingen voor softwarebeveiliging zijn echter vaak gefragmenteerd en richten zich op geïsoleerde taken, zoals detectie of patchgeneratie, in plaats van de volledige end-to-end agentic workflows te reflecteren die worden gebruikt in real-world beveiligingsprocessen. Dit creëert een kloof tussen bestaande LLM-methoden en praktische veilige software engineering, met name voor low-level systemen talen zoals C en C++. In deze talen hangen kwetsbaarheden af van complexe geheugensemantiek, pointermanipulatie en bufferbeheer, wat diagnose en remediëring uitdagend maakt voor LLM's. Bovendien is er beperkt onderzoek gedaan naar tool-augmented agentic workflows en de integratie van Model Context Protocol (MCP) skills specifiek voor deze low-level contexten.

Methodologie

De auteurs stellen een role-based agentic workflow voor en evalueren deze, die ontworpen is om kwetsbaarheidsafhandeling te deconstrueren in expliciete fasen: investigatieplanning, kwetsbaarheidsanalyse, patchgeneratie en fix-verificatie.

Workflow Design

De studie implementeert twee workflow-varianten met behulp van het CrewAI-framework, geïnstancieerd met drie open-source LLM's: nemotron-cascade-2:30b, qwen3-coder-next en gpt-oss:120b. De workflows bestaan uit vier onderscheidende rollen:

Planner: Een regelgebaseerd statisch module (geen LLM) die de input C-code scant op vooraf gedefinieerde kwetsbaarheidspatronen (bijv. buffer overflows, null pointer dereferences) met behulp van reguliere expressies. Het genereert geprioriteerde investigatieregio's en thema's om de Analyzer te begeleiden.
Analyzer: Een LLM-agent verantwoordelijk voor technische diagnose. Deze bepaalt de primaire kwetsbaarheid, wijst de Common Weakness Enumeration (CWE) ID toe, identificeert kwetsbare regels, legt de oorzaak uit en volgt de source-to-sink flow.
- Workflow 1: De Analyzer vertrouwt uitsluitend op de begeleiding van de Planner.
- Workflow 2: De Analyzer wordt verrijkt met MCP CodeQL-integratie, wat statische analyse-mogelijkheden biedt tijdens de diagnose.
Fixer: Een LLM-agent die een minimale veilige patch genereert op basis van de diagnose van de Analyzer. Deze is beperkt tot het produceren van de patch en een beknopte uitleg, waarbij re-diagnose wordt vermeden.
Verifier: Een onafhankelijke LLM-agent die beoordeelt of de gegenereerde patch de geïdentificeerde kwetsbaarheid oplost, de oorzaak verwijdert en het introduceren van regressies voorkomt.

Experimentele Opzet

Dataset: Een gecureerde set van 25 real-world C/C++ Common Vulnerabilities and Exposures (CVE's) verspreid over vijf CWE-categorieën: CWE-787 (Out-of-bounds Write), CWE-476 (Null Pointer Dereference), CWE-190 (Integer Overflow), CWE-125 (Out-of-bounds Read) en CWE-191 (Integer Underflow).
Ground Truth: Afgeleid van National Vulnerability Database (NVD) beschrijvingen en door ontwikkelaars geleverde gepatchte code.
Evaluatie: Handmatige, op een rubric gebaseerde beoordeling door twee auteurs (Cohen's kappa $\kappa = 0.83$ ) waarbij de output van de agents wordt vergeleken met de ground truth. De metrieken omvatten detectie-accuratesse (CWE-toewijzing, regelidentificatie, oorzaak) en fix-accuratesse (semantische gelijkenis met vertrouwde fixes).
Scope: De studie is een exploratieve, methodologie-georiënteerde beoordeling in plaats van een grootschalige benchmark, met een focus op 150 workflow-executies (25 CVE's $\times$ 3 modellen $\times$ 2 varianten).

Belangrijkste Bijdragen

Role-Based Agentic Architectuur: Voorstel en evaluatie van een end-to-end workflow die planning, analyse, fixing en verificatie scheidt, waarbij wordt aangetoond hoe expliciete rolverdeling beveiligingsactiviteiten kan structureren.
Statisch Planner Design: Implementatie van een regelgebaseerde planner om kwetsbaarheidsonderzoek in industrie-relevante C-projecten te begeleiden, wat de cruciale impact op de kwaliteit van detectie aantoont.
Gecureerde Referentieset: Voorziening van 25 real-world C/C++ kwetsbaarheidsinstanties met ground-truth metadata, developer fixes en LLM-gegenereerde outputs, samen met de open-source CrewAI framework code voor reproduceerbaarheid.
Tool Integratie Analyse: Onderzoek naar de effectiviteit van het integreren van MCP-gebaseerde statische analyse (CodeQL) in de analysefase van een multi-agent workflow.

Resultaten

De studie rapporteert de volgende prestatie-metrieken (gebruikmakend van nemotron-cascade-2:30b als primair model voor vergelijking):

Detectie Accuratesse:
- Workflow 1 (Geen CodeQL): Behaalde een detectie-accuratesse van 44%, vergelijkbaar met GPT-5.5 baselines.
- Workflow 2 (Met CodeQL): De accuratesse daalde naar 31%, wat suggereert dat tool-integratie alleen geen verbetering garandeert als de agent de tool-hints niet correct kan interpreteren of prioriteren.
- Ablatie: Het verwijderen van de Planner verminderde de detectie-accuratesse tot 25% (zonder CodeQL) en 19% (met CodeQL), wat de cruciale rol van de Planner onderstreept.
Fix Accuratesse:
- De algehele fix-accuratesse was laag op 19% voor Workflow 1 en 13% voor Workflow 2.
- Reparatie bleek aanzienlijk moeilijker dan detectie. Hoewel sommige patches "vergelijkbaar" of zelfs "beter" waren dan de ground truth (met name voor CWE-476 en CWE-787), bevatten veel patches onnodige logica of introduceerden ze nieuwe bugs.
Verifier Accuratesse:
- De Verifier behaalde een accuratesse van 69% met nemotron-cascade-2:30b, wat duidt op een sterkere capaciteit in post-remediatie beoordeling dan in generatie.
CWE Variabiliteit: CWE-787 en CWE-476 waren het makkelijkst te detecteren, terwijl CWE-191 (Integer Underflow) de moeilijkste bleef over alle modellen en settings heen.

Betekenis en Claims

Het artikel positioneert dit werk als een initiële exploratieve studie in plaats van een definitieve benchmark. De primaire betekenis ligt in:

Procesverbetering: Het aantonen dat het deconstrueren van beveiligingstaken in gestructureerde, role-based stadia (Planning, Analyse, Fixing, Verifying) beveiligingsactiviteiten reproduceerbaarder en transparanter kan maken.
Noodzaak van Human-in-the-Loop: Het versterken van het feit dat, ondanks de vooruitgang in LLM's, de ongelijke kwaliteit van gegenereerde patches en de gemengde effectiviteit van tool-integratie voortdurende menselijke supervisie noodzakelijk maken in beveiligingskritische omgevingen.
Workflow boven Model: De focus verschuiven van het selecteren van het "beste" model naar het verfijnen van de onderliggende workflow-architectuur en integratietechnieken. De auteurs merken op dat hoewel model screening essentieel is, het workflow-design zelf de primaire hefboom voor verbetering is.
Nuance in Tool Integratie: Het benadrukken dat het integreren van tools zoals CodeQL zorgvuldige agent-design vereist om ervoor te zorgen dat hints correct worden geprioriteerd; het simpelweg toevoegen van tools verhoogt de prestaties niet automatisch.

De auteurs concluderen dat role-based agentic architecturen een veelbelovende richting zijn voor de verbetering van veilige softwareprocessen, wat toekomstig werk stimuleert op het gebied van grotere datasets, repository-level analyse en verfijnde workflow-alternatieven (bijv. meerdere analyzers, refinement loops).