Project Glasswing: wat Mythos ons heeft laten zien

De afgelopen maanden hebben we op onze eigen infra­struc­tuur een reeks op bevei­li­ging gerichte LLM’s getest. Deze LLM’s helpen ons mogelijke 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 onderdeel 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 eromheen moeten worden aangepast, 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 duidelijk 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 mogelijk was met eerdere algemene frontier-modellen naar wat Mythos Preview vandaag de dag doet, is meer dan alleen een verfijning.

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 algemene 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 volledige controle over een systeem kunnen overnemen. Mythos Preview kan meerdere 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.
• Generatie 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 activeren, 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 hypothese 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 hierboven beschrijven, is niet helemaal 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, waardoor de eigen­lijke lus niet af was en de vraag open bleef of de bug misbruikt kon worden. Wat er met Mythos Preview is veranderd, is dat een model nu die bugs met een lage ernst­graad (die voorheen onzicht­baar in een backlog zouden blijven zitten) tot één enkele, ernsti­gere kwets­baar­heid kan samenvoegen. 

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 algemeen 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 waardoor soms legitieme verzoeken om veilig­heids­on­der­zoek worden afgewezen. Maar we hebben opgemerkt 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 onderzoek op dezelfde code na een wijziging van de projec­tom­ge­ving, die daar los van stond. Er was niets veranderd 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 codebase, 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 voorgelegd.

Dit is van belang, omdat de inge­bouwde afwij­zingen en restric­ties van het model weliswaar reëel zijn, maar niet consis­tent genoeg zijn om op zichzelf als volledige veilig­heids­grens te fungeren. Dat is precies de reden waarom elk degelijk cyber­fron­tier-model dat in de toekomst algemeen beschik­baar wordt gesteld, naast dit basis­ge­drag ook aanvul­lende veilig­heids­maat­re­gelen moet bevatten, zodat het geschikt is voor algemeen 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 situatie verder verergerd, en bij Cloud­flare hebben we meerdere fasen voor validatie achteraf ingebouwd 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 voorkomen. We zagen conse­quent meer valse posi­tieven bij projecten die in talen waren geschreven die niet geheu­gen­veilig zijn.
• Modelbias – 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, ongeacht of de code bugs bevat of niet. De bevin­dingen worden vaak afgezwakt met woorden als ‘mogelijk’, ‘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 rampzalig voor een triage-wachtrij, waar elke twij­fel­ach­tige bevinding mense­lijke aandacht vergt en tokens kost om te worden afgewezen. 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 meerdere kwets­baar­heden tot een werkend proof-of-concept te combi­neren in plaats van ze afzon­der­lijk te rappor­teren. Een bevinding die met een proof-of-concept wordt geleverd, is een bevinding waarop je kunt voort­bouwen, en dat betekent dat je veel minder tijd kwijt bent aan de vraag: “Is dit wel echt?”

Onze detec­tie­mid­delen zijn opzet­te­lijk afgesteld 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 merkbaar hogere kwaliteit te zijn: minder onzekere 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 generieke 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 oplevert, maar het slaagt er niet in om een goed beeld te geven van een echte codebase en om waar­de­volle bevin­dingen te iden­ti­fi­ceren. Daar zijn twee belang­rijke redenen voor:

• Context - Codeer­agents zijn afgestemd op één speci­fieke taak: een functie ontwik­kelen, een bug verhelpen of een refactor uitvoeren. Ze verwerken grote hoeveel­heden broncode, houden zich telkens aan één hypothese 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 specifiek onderwerp uit en bestu­deren dat grondig. Dat ene onderwerp 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-injecties, 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 codebase. 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, waardoor eerdere bevin­dingen die van belang zouden zijn geweest, mogelijk verloren gaan.
• Doorvoer - Een single-stream-agent voert één taak tegelijk uit, maar in echte codebases 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 handmatig onderzoek 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 eromheen.

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 noodzaak van een harnas dat de algehele uitvoe­ring aanstuurt:

• Kleinere 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-injection 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 onderwerp”, 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 bevinding 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 genereren, 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 presteert 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 presteren beter dan één alom­vat­tende agent - De dekking wordt beter wanneer veel agents aan duidelijk 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 behandelen.

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, aangezien 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 optimaal aansluiten bij de sterke punten van het systeem. Hieronder wordt beschreven hoe een harnas er in de praktijk 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 snelheid: sneller scannen, sneller patches instal­leren en de respon­s­cy­clus verkorten. Meerdere 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 tijdlijn 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 structuur van de pijplijn die de patch genereert. 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 meelevert als je regres­sie­testen overslaat, zijn doorgaans 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 uitgerold die de oorspron­ke­lijke bug weliswaar 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 betekent dat er bevei­li­gings­me­cha­nismen vóór de appli­catie staan die voorkomen 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 betekent dat je een oplossing 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 implementeren. 

We beseffen ook dat dit onderwerp 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 hierboven beschreven archi­tec­tuur­prin­cipes zijn precies de principes die onze producten ten behoeve van onze klanten toepassen. De komende weken zullen we meer infor­matie geven over wat dit voor onze klanten betekent.