De afge­lopen maanden hebben we op onze eigen infra­struc­tuur een reeks op bevei­li­ging gerichte LLM’s getest. Deze LLM’s helpen ons moge­lijke kwets­baar­heden in onze eigen systemen op te sporen, zodat we die kunnen verhelpen – en ze laten ons ook zien wat aanval­lers met de nieuwste modellen kunnen doen.

Geen van deze LLM’s heeft meer aandacht getrokken dan Mythos Preview van Anthropic. Een paar weken geleden werden we uitge­no­digd om Mythos Preview te gebruiken als onder­deel van Project Glasswing. We richtten het model al snel op meer dan vijftig van onze eigen repo­si­to­ries – om te zien wat het zou vinden en om te zien hoe het werkt.

In deze blog delen we onze bevin­dingen: wat de modellen goed deden en wat niet, en hoe de archi­tec­tuur en de processen erom­heen moeten worden aange­past, zodat ze op grote schaal kunnen worden ingezet.

Wat is er veranderd door Mythos Preview

Mythos Preview is echt een grote stap vooruit, en het is de moeite waard om dat duide­lijk te zeggen voordat we dieper op andere zaken ingaan. We zijn al een tijdje bezig met het testen van modellen op onze code, en de sprong van wat er moge­lijk was met eerdere alge­mene fron­tier-modellen naar wat Mythos Preview vandaag de dag doet, is meer dan alleen een verfij­ning.

Mythos is een heel andere soort tool die voor andere doel­einden wordt gebruikt, en dat maakt een eerlijke verge­lij­king met eerdere modellen lastig. In plaats van Mythos Preview te verge­lijken met alge­mene state-of-the-art-modellen, is het zinvoller om te beschrijven wat het model daad­wer­ke­lijk kan, en er zijn twee kenmerken die ons tijdens het werk met Mythos Preview opvielen:

• Constructie van exploit­ke­tens - Een echte aanval profi­teert zelden van slechts één bug. Voor een aanval worden verschil­lende kleine aanvals­ele­menten tot een werkende exploit samen­ge­voegd. Zo zou het bijvoor­beeld een ‘use-after-free’-bug kunnen omzetten in een wille­keu­rige lees- en schrijf­op­dracht, de contro­le­stroom kunnen kapen en met behulp van ROP-ketens (Return-Oriented Program­ming) de volle­dige controle over een systeem kunnen over­nemen. Mythos Preview kan meer­dere van deze basis­ele­menten verwerken en bepalen hoe deze tot een geldig bewijs kunnen worden samen­ge­voegd. De rede­ne­ring die daarbij wordt gevolgd, lijkt meer op het werk van een ervaren onder­zoeker dan op de output van een geau­to­ma­ti­seerde scanner.
• Gene­ratie van bewijs­ma­te­riaal - Een bug vinden en aantonen dat deze misbruikt kan worden, zijn twee verschil­lende dingen, en Mythos Preview kan beide. Het model schrijft code die de vermoe­de­lijke bug zou acti­veren, compi­leert die code in een testom­ge­ving en voert deze uit. Als het programma doet wat het model voor­spelde, is dat het bewijs. Zo niet, dan regi­streert het model de fout, past het zijn hypo­these aan en probeert het opnieuw. De test­cy­clus is net zo belang­rijk als de bugs die ermee worden opge­spoord, want een vermoe­de­lijke fout zonder enig bewijs is slechts specu­latie, en Mythos Preview vult die leemte zelf op.

Een deel van wat we hier­boven beschrijven, is niet hele­maal uniek voor Mythos Preview. Toen we andere geavan­ceerde modellen door hetzelfde harnas haalden, ontdekten ze een behoor­lijk aantal van dezelfde onder­lig­gende bugs, en in sommige gevallen gingen ze ook op het gebied van rede­ne­ring verder dan we hadden verwacht. Waar ze tekort­schoten, was bij het samen­voegen van de verschil­lende onder­delen. Een model spoorde een inte­res­sante bug op, gaf een goed door­dachte beschrij­ving van waarom die bug van belang was, en daar hield het mee op, waar­door de eigen­lijke lus niet af was en de vraag open bleef of de bug misbruikt kon worden. Wat er met Mythos Preview is veran­derd, is dat een model nu die bugs met een lage ernst­graad (die voor­heen onzicht­baar in een backlog zouden blijven zitten) tot één enkele, ernsti­gere kwets­baar­heid kan samen­voegen. 

Voorbeelden van afwijzingen bij legitiem kwetsbaarheidsonderzoek

Het Mythos Preview-model dat door Anthropic werd verstrekt in het kader van Project Glasswing, beschikte niet over de extra veilig­heids­maat­re­gelen die wel aanwezig zijn in alge­meen beschik­bare modellen (zoals Opus 4.7 of GPT‑5.5).

Deson­danks wijst het model bepaalde verzoeken op natuur­lijke wijze af. Net zoals de cyber­ca­pa­ci­teiten die het model geschikt maakten voor het opsporen van kwets­baar­heden, heeft het model zijn eigen, vanzelf ontstane restric­ties waar­door soms legi­tieme verzoeken om veilig­heids­on­der­zoek worden afge­wezen. Maar we hebben opge­merkt dat deze natuur­lijke afwij­zingen niet consis­tent zijn: indien anders gefor­mu­leerd of in een andere context gepre­sen­teerd, kan dezelfde taak tot totaal andere resul­taten leiden, zoals uit de onder­staande voor­beelden blijkt.

Zo weigerde het model aanvan­ke­lijk een kwets­baar­heids­on­der­zoek uit te voeren voor een project, maar ging vervol­gens akkoord met hetzelfde onder­zoek op dezelfde code na een wijzi­ging van de projec­tom­ge­ving, die daar los van stond. Er was niets veran­derd aan de code die werd geana­ly­seerd. In een ander geval ontdekte en beves­tigde het model verschil­lende ernstige geheu­gen­fouten in een code­base, maar weigerde vervol­gens een demon­stratie-exploit te schrijven. Hetzelfde verzoek, anders gefor­mu­leerd, leverde een ander antwoord op. Hetzelfde verzoek kan bij verschil­lende uitvoe­ringen zelfs tot verschil­lende resul­taten leiden vanwege het proba­bi­lis­ti­sche karakter van het model. Seman­tisch gelijk­waar­dige taken kunnen tot tegen­ge­stelde resul­taten leiden, afhan­ke­lijk van hoe en wanneer ze aan het model worden voor­ge­legd.

Dit is van belang, omdat de inge­bouwde afwij­zingen en restric­ties van het model welis­waar reëel zijn, maar niet consis­tent genoeg zijn om op zich­zelf als volle­dige veilig­heids­grens te fungeren. Dat is precies de reden waarom elk dege­lijk cyber­fron­tier-model dat in de toekomst alge­meen beschik­baar wordt gesteld, naast dit basis­ge­drag ook aanvul­lende veilig­heids­maat­re­gelen moet bevatten, zodat het geschikt is voor alge­meen gebruik buiten een gecon­tro­leerde onder­zoeks­om­ge­ving zoals Project Glasswing.

Het signaal-ruisprobleem

Een van de moei­lijkste aspecten bij het prio­ri­teren van bevei­li­gings­kwets­baar­heden is bepalen welke bugs daad­wer­ke­lijk bestaan, welke misbruikt kunnen worden en welke onmid­del­lijk verholpen moeten worden. Dit was zelfs in de tijd vóór de opkomst van AI al een lastig probleem. AI-kwets­baar­heids­scan­ners en door AI gege­ne­reerde code hebben de situ­atie verder verer­gerd, en bij Cloud­flare hebben we meer­dere fasen voor vali­datie achteraf inge­bouwd om dit aan te pakken.

Twee factoren bepalen de mate van ruis:

• Program­meer­taal – C en C++ bieden directe controle over het geheugen, maar brengen daarmee ook een reeks veel­voor­ko­mende bugs met zich mee, zoals buffer­over­schrij­dingen en het lezen of schrijven buiten de toege­stane grenzen, die in geheu­gen­vei­lige talen zoals Rust al tijdens het compi­leren worden voor­komen. We zagen conse­quent meer valse posi­tieven bij projecten die in talen waren geschreven die niet geheu­gen­veilig zijn.
• Model­bias – Goede mense­lijke onder­zoe­kers vertellen wat ze hebben gevonden en hoe zeker ze van hun zaak zijn. Modellen doen dat niet. Vraag een model om bugs op te sporen, dan worden die gevonden, onge­acht of de code bugs bevat of niet. De bevin­dingen worden vaak afge­zwakt met woorden als ‘moge­lijk’, ‘poten­tieel’ en ‘in theorie’, en deze afge­zwakte bevin­dingen zijn veel talrijker dan de onom­sto­te­lijke. Dat is een aanvaard­bare bias voor een verken­nende tool. Dat is echter ramp­zalig voor een triage-wachtrij, waar elke twij­fel­ach­tige bevin­ding mense­lijke aandacht vergt en tokens kost om te worden afge­wezen. Deze kosten lopen bij duizenden bevin­dingen alleen maar op.

Mythos Preview is een duide­lijke verbe­te­ring, met name wat betreft de moge­lijk­heid om kwets­baar­heden aan elkaar te koppelen, door meer­dere kwets­baar­heden tot een werkend proof-of-concept te combi­neren in plaats van ze afzon­der­lijk te rappor­teren. Een bevin­ding die met een proof-of-concept wordt gele­verd, is een bevin­ding waarop je kunt voort­bouwen, en dat bete­kent dat je veel minder tijd kwijt bent aan de vraag: “Is dit wel echt?”

Onze detec­tie­mid­delen zijn opzet­te­lijk afge­steld om te veel te rappor­teren, zodat we meer zien (en minder missen), wat met veel meer ruis gepaard gaat. Maar bij de eerste beoor­de­ling blijkt de output van Mythos Preview van merk­baar hogere kwali­teit te zijn: minder onze­kere bevin­dingen, duide­lij­kere repro­duc­tie­stappen en minder werk om tot een besluit te komen over het verhelpen of afwijzen van de bug.

Waarom het niet werkt om een generieke codeeragent op een repository te richten

Toen we vorig jaar voor het eerst begonnen met AI-onder­steund kwets­baar­heids­on­der­zoek, volgden we ons instinct: we lieten een gene­rieke codeer­agent een wille­keu­rige repo­si­tory door­zoeken en vroegen hem om kwets­baar­heden op te sporen. Deze aanpak werkt wel, in die zin dat het model bevin­dingen ople­vert, maar het slaagt er niet in om een goed beeld te geven van een echte code­base en om waar­de­volle bevin­dingen te iden­ti­fi­ceren. Daar zijn twee belang­rijke redenen voor:

• Context - Codeer­agents zijn afge­stemd op één speci­fieke taak: een functie ontwik­kelen, een bug verhelpen of een refactor uitvoeren. Ze verwerken grote hoeveel­heden bron­code, houden zich telkens aan één hypo­these en testen die herhaal­de­lijk. Dat is precies de verkeerde aanpak voor kwets­baar­heids­on­der­zoek, dat van nature beperkt en parallel van aard is. Mense­lijke onder­zoe­kers kiezen één speci­fiek onder­werp uit en bestu­deren dat grondig. Dat ene onder­werp kan een enkele complexe functie zijn, het over­schrijden van bevei­li­gings­grenzen, of een speci­fieke kwets­baar­heids­ca­te­gorie, zoals command-injec­ties, waarbij input van een aanvaller uitein­de­lijk als een shell-commando wordt uitge­voerd. Vervol­gens doen ze dat opnieuw, voor een andere functie, bevei­li­gings­grens of kwets­baar­heids­klasse, en dat wel duizenden keren voor de hele code­base. Een sessie met één agent (zelfs met subagents) op een repo­si­tory van honderd­dui­zend regels kan op een zinvolle manier misschien een tiende van een procent van het geheel bestrijken, voordat het context­ven­ster van het model vol raakt en de compri­me­ring in werking treedt, waar­door eerdere bevin­dingen die van belang zouden zijn geweest, moge­lijk verloren gaan.
• Door­voer - Een single-stream-agent voert één taak tege­lijk uit, maar in echte code­bases zijn er vaak veel hypo­thesen nodig die tege­lij­ker­tijd op verschil­lende compo­nenten worden getoetst, met de moge­lijk­heid om verder uit te breiden wanneer er iets inte­res­sants opduikt. Je kunt één agent wel harder laten werken, maar op een gegeven moment word je niet langer beperkt door het model, maar door de aard van de inter­actie zelf. Het recht­streekse gebruik van het model in een codeer­agent blijkt prima te werken voor hand­matig onder­zoek wanneer een onder­zoeker al een aankno­pings­punt heeft en een tweede mening wil. Het is echter de verkeerde tool voor een hoge dekking. Toen we dat eenmaal hadden geac­cep­teerd, hebben we Mythos Preview niet langer voor de verkeerde taak ingezet, en zijn we begonnen met het bouwen van het harnas erom­heen.

De functie van een harnas

We hebben vier lessen geleerd door het werk op schaal uit te voeren, die stuk voor stuk wezen op de nood­zaak van een harnas dat de alge­hele uitvoe­ring aanstuurt:

• Klei­nere scope leidt tot betere resul­taten - Als je tegen het model zegt: “Zoek kwets­baar­heden in deze repo­si­tory”, gaat het dwalen. Als je tegen het systeem zegt: “Zoek naar command-injec­tion in deze speci­fieke functie, met deze vertrou­wens­grens erboven; hier is het archi­tec­tuur­do­cu­ment en hier vind je eerdere bericht­ge­ving over dit onder­werp”, zorg je ervoor dat het systeem iets doet wat veel dichter in de buurt komt van wat een mense­lijke onder­zoeker zou doen.
• Advers­a­riële controle vermin­dert ruis – Door tussen de eerste bevin­ding en de wachtrij een tweede agent in te zetten, een agent met een andere prompt, een ander model en zonder de moge­lijk­heid om zelf bevin­dingen te gene­reren, wordt veel van de ruis opge­vangen die de eerste agent zou missen als die alleen zijn eigen werk zou contro­leren. Het blijkt dat het veel effec­tiever is om twee agents opzet­te­lijk met elkaar in conflict te brengen, dan om slechts één agent te vragen om voor­zichtig te zijn.
• Door de keten over verschil­lende agents te verdelen, ontstaat een betere rede­ne­ring - De vragen “Bevat deze code bugs?” en “Kan een aanvaller deze fout daad­wer­ke­lijk van buiten het systeem omzeilen?” zijn heel verschil­lend, en het model pres­teert bij beide beter als je ze afzon­der­lijk stelt, omdat elke vraag speci­fieker is dan de gecom­bi­neerde versie.
• Paral­lelle, beperkte taken pres­teren beter dan één alom­vat­tende agent - De dekking wordt beter wanneer veel agents aan duide­lijk afge­ba­kende vragen werken en we alle gedu­pli­ceerde resul­taten achteraf verwij­deren, in plaats van één agent te vragen alles uitput­tend te behan­delen.

Al deze obser­va­ties hebben betrek­king op het gedrag van het model, en samen geven ze een beeld van iets dat geen chatin­ter­face meer is. Het is een harnas dat je helpt om de gewenste resul­taten te behalen. De eerste stappen bij het bouwen van een harnas zijn eenvoudig, aange­zien je het model om hulp kunt vragen, en dat is precies wat wij hebben gedaan. We hebben Mythos Preview gebruikt om onze oorspron­ke­lijke harnassen uit te breiden, aan te passen en te verbe­teren, zodat ze opti­maal aansluiten bij de sterke punten van het systeem. Hier­onder wordt beschreven hoe een harnas er in de prak­tijk uitziet.

Ons harnas voor het opsporen van kwetsbaarheden

Zo ziet ons systeem voor het opsporen van kwets­baar­heden er staps­ge­wijs uit. Het werd gebruikt om live code te scannen in onze runtime, het edge-datapad, de proto­col­stack, de control plane en de open-sour­ce­pro­jecten waarvan we afhan­ke­lijk zijn.

Wat dit voor beveiligingsteams betekent

De meest uitge­sproken reactie van andere bevei­li­gings­ver­ant­woor­de­lijken op Mythos Preview had betrek­king op snel­heid: sneller scannen, sneller patches instal­leren en de respon­s­cy­clus verkorten. Meer­dere teams waarmee we hebben gesproken, hebben nu een SLA van twee uur tussen de release van een CVE en de imple­men­tatie van de patch in de produc­tie­om­ge­ving. Dat instinct is begrij­pe­lijk: als de tijd­lijn van de aanvaller korter wordt, moet die van de verde­diger ook korter worden. Sneller alleen echter is niet genoeg, en wij denken dat veel teams op het punt staan om hun neus te stoten, ondanks de tijd, moeite en het geld dat hieraan wordt besteed.

Sneller patchen heeft geen invloed op de struc­tuur van de pijp­lijn die de patch gene­reert. Als regres­sie­testen een dag in beslag nemen, kun je een SLA van twee uur niet halen zonder deze testen over te slaan, en de bugs die je meele­vert als je regres­sie­testen over­slaat, zijn door­gaans ernstiger dan de bugs die je juist probeerde te verhelpen. We hebben dit gemerkt toen we het model zijn eigen patches lieten schrijven en zagen dat er een paar werden uitge­rold die de oorspron­ke­lijke bug welis­waar verhielpen, maar stil­le­tjes iets anders kapot­maakten waar de code van afhan­ke­lijk was.

De moei­lij­kere vraag is hoe de archi­tec­tuur rondom de kwets­baar­heid eruit moet zien. Het uitgangs­punt is om het voor een aanvaller moei­lijker te maken om misbruik te maken van een kwets­baar­heid, zelfs als er een bug in het systeem zit, zodat het tijds­ver­schil tussen het moment waarop een kwets­baar­heid wordt ontdekt en het moment waarop deze wordt verholpen, minder belang­rijk wordt. Dat bete­kent dat er bevei­li­gings­me­cha­nismen vóór de appli­catie staan die voor­komen dat de bug wordt bereikt. Dit houdt in dat de appli­catie zo moet worden ontworpen dat een fout in een bepaald deel van de code een aanvaller geen toegang geeft tot andere delen. Het bete­kent dat je een oplos­sing tege­lij­ker­tijd op alle plaatsen waar de code draait, kunt imple­men­teren, in plaats van te moeten wachten tot afzon­der­lijke teams deze zelf imple­men­teren. 

We beseffen ook dat dit onder­werp twee kanten heeft. Dezelfde moge­lijk­heden die ons hebben geholpen om bugs in onze eigen code op te sporen, zullen in verkeerde handen de aanvallen op alle appli­ca­ties op het internet alleen maar in de hand werken. Cloud­flare fungeert als een soort buffer voor miljoenen van die appli­ca­ties, en de hier­boven beschreven archi­tec­tuur­prin­cipes zijn precies de prin­cipes die onze producten ten behoeve van onze klanten toepassen. De komende weken zullen we meer infor­matie geven over wat dit voor onze klanten bete­kent.