Microsoft-cto Russinovich vindt via Claude kwetsbaarheden in zijn antieke code

Cto Mark Russinovich van Microsoft Azure liet oude Apple II-software van zijn hand analyseren door Claude Opus 4.6. De AI-codetool vond meerdere kwetsbaarheden in de veertig jaar oude code. Claude moest die antieke software, geschreven in machinetaal, eerst decompileren.

De mogelijkheden van AI om kwetsbaarheden te vinden, zijn 'ongelofelijk' en de mogelijkheid om machinetaal te reverse-engineeren is 'schokkend'. Dit stelt cto Mark Russinovich van Microsofts clouddivisie, Azure, die ook bekend is als maker van de Windows-tools Sysinternals. Hij komt tot deze uitspraken na het loslaten van Claude Opus 4.6 op een tool die hij in 1986 schreef voor de Apple II-computer. Zijn oude software was geschreven in de machinetaal van de 8bit-6502-processor.

Tot zijn verbazing kon de AI-tool van Anthropic niet alleen die diepere legacyprogrammeertaal ontcijferen. Claude Opus reconstrueerde volgens hem ook de logica van zijn code 'met nauwkeurige labels en comments'. Russinovich stelt dat de AI-tool in wezen de intentie van de code las die hij veertig jaar geleden schreef.

'Nieuw tijdperk'

Vervolgens was hij nog meer onder de indruk van de securityaudit die Claude Opus uitvoerde. De AI identificeerde logische fouten in de code. Deze problemen kunnen leiden tot 'stil incorrect gedrag' van de software. Russinovich merkt op dat deze bugs niet direct neerkomen op kwetsbaarheden die gebruikers in gevaar brengen. Wel meent hij dat zijn experiment met AI een fundamentele verschuiving belicht.

Russinovich waarschuwt dat AI een nieuw tijdperk van softwarekwetsbaarheden inluidt. Het vinden van beveiligingsgaten in software wordt dankzij AI nog verder geautomatiseerd en daarbij ook versneld, schrijft hij op LinkedIn. Dit brengt fundamentele veranderingen met zich mee die zowel verdedigers als aanvallers benutten, aldus de technische topman bij Microsoft.

Claude. Bron: Anthropic

Reacties (92)

[DdeM]

Hoe weet hij zo zeker dat de kwetsbaarheden in de gedecompileerde "reverse-engineered" code óók in de originele code zaten? Leuk dat je de intentie van de code kan vergelijken met wat je zelf ooit bedoeld had, maar tenzij hij de originele niet gecompileerde code er naast heeft gehouden ter vergelijking is er 0 garantie dat die kwetsbaarheden er initieel gewoonweg niet in zaten.

[Prince]

Decompileren (machinecode naar assembler of C) is 100% identiek in wat de code doet.

De benamingen van de functies bepalen en veel "ontdoen van standaard optimalisaties van de compiler" is waar hier de magie zit. Maar dit betekent nog steeds niet dat hij zaken verzint.

Ook het feit dat hij comments kan achterhalen, betekent dat er debuginformatie in zat; als in deze comments uitleg zat en namen van gerelateerde functies, dan kan hij deze ook gebruiken.

[gixslayer]

Decompileren (machinecode naar assembler of C) is 100% identiek in wat de code doet.

Het "decompileren" naar assembly, i.e. disassembly, is in theorie 100% accuraat. In de praktijk kun je hier echter alsnog tegen problemen aanlopen. Zo is x86 bijvoorbeeld zo complex dat verschillende tools de binary blobs anders decoden, en zeker met Variable Length Instructions krijg je dan al snel totaal verschillende resultaten. Zie deze blog voor meer info. Ja natuurlijk is dit gewoon een bug in de tooling en/of ambigue specificaties, maar het geeft wel aan dat dit een serieus issue is waar een LLM ook last van kan hebben.

Als we het hebben over decompileren naar (pseudo) C, wat tools zoals IDA/Ghidra/Binja doen, dan nee. Dit is niet 100% accuraat. Er zijn scenarios waar de machine code/assembly gewoon niet goed naar C is te vertalen, of dat control flow een zooitje wordt. Een ander issue is het aanroepen van andere functies, die misschien niet de standaard calling convention volgen (bijvoorbeeld door compiler optimization voor niet externe functies). Dit was altijd erg duidelijk in bijvoorbeeld IDA. Je had soms wat code, en als je dan een functie bekeek die wordt aangeroepen, verandert je decompiled code opeens omdat er meer analyse had plaatsgevonden.

Je kan opnieuw zeggen, oh maar dat is een tooling issue. En wellicht valt er een decompiler te schrijven die altijd accuraat is door erg low-level C code uit te spugen vol met e.g. compiler intrinsics, maar dan verlies je ook een beetje het nut van een decompiler en heb je meer een iets fancier disassembler. Daarnaast hebben veel van deze decompilers allemaal hun eigen set bugs, omdat het erg complex is, en krijg je met 5 verschillende decompilers soms 5 verschillende resultaten, die allemaal al dan niet correct kunnen zijn.

Dit is opnieuw voor een LLM niet magisch op te lossen lijkt me, en als het dus op basis van 'decompiled' code naar vulnerabilities zoekt dan heb je daar gewoon een extra laag zitten waar fouten kunnen optreden waardoor de analyse niet meer klopt.

Vervolgens kan je ook nog problemen hebben met source code die wel veilig is, maar door compiler bugs machine code uitspuugt die niet veilig is, of andersom. Of dat het alleen voor bepaalde targets (x86 vs arm vs risc5 etc) onveilige machine code uitspuugt.

Kortom er zitten hier nogal wat valkuilen waar een LLM ook niet zomaar omheen kan. Ja in veel gevallen zal het vast goed gaan, maar ik zou er niet blind op gaan vertrouwen.

[Stijnvi]

Daarnaast staan LLMs er natuurlijk ook om bekend regelmatig te hallucineren. Wikipedia loopt er bijvoorbeeld al tegenaan dat vertalingen door LLMs in een keer informatie bevatten die niet in het originele artikelen stonden, of juist informatie uit het originele artikel weglaten, en dat bronnen uit het originele artikelen ontbreken, of dat er nieuwe bronnen bij zijn verzonnen.

https://www.pcworld.com/article/3079595/wikipedia-has-an-ai-translation-problem.html

Als het al zo erg fout gaat bij het vertalen van een simpel stuk tekst van Wikipedia, dan wil ik niet weten wat een LLM doet wanneer hij code moet "vertalen".

[Lnaisd]

ligt wel aan welke AI je gebruikt naar mijn ervaring is claude heel nuchter ter vergelijking met chatGPT en Gemini.

[Mellow Jack]

Het ligt er vooral ook aan hoe je een LLM gebruikt. De hele poppenkast eromheen maakt het nuttig of juist niet. Oftewel, gooi je een heel document erin? Gebruik je een geoptimaliseerde bot of een algemene? Gebruik je een specifieke system prompt of niet?

Ergens ben ik bij Wikipedia een beetje bang dat het probleem niet zozeer in de techniek zit

[Bart.net]

Is het verschil in dit geval niet dat je de gedecomplileerde code weer moet kunnen compileren, en dat daar exact dezelfde code uit moet komen? Of kan de volgorde van de code per compiler verschillen?

[Hans1990]

Ook met ARM heb je compacte instructiesets zoals Thumb2 die door andere 32-bit ARM instructies kunnen worden gebruikt. RISC-V doet ditzelfde met de `c` extensie. Als je dan op de verkeerde byte begint met een instructiestream te decoderen heb je een grote kans dat er aardig wat instructies fout worden gedecodeerd. Op x86 is dit probleem enkel maar chaotischer, omdat elke instructie een andere lengte kan hebben.

Echter in mijn ervaring is dit vooral een probleem op embedded met een onbekende core en/of interrupt vector table die naar interrupt functies kunnen wijzen. Bovendien zitten deze programma's vaak ook vol met address constantes naar bijvoorbeeld global variables en/of peripheral addressen. Je kan dan lang niet alles zomaar als code aanwijzen.
Daarintegen: programma's op x86 PC's hebben bekende entry points omdat het al ELF/SO objecten zijn bijvoorbeeld. Met x86 kan je direct hele addressen in een instructie encoderen. En vaak hebben ze ook nog een lijst van imports/exports. Dat maakt de instructiestream ook weer stukje makkelijker om te parsen.. In mijn ervaring heb ik hiermee eigenlijk nooit problemen hier mee gezien. Enkel af en toe wat byte arrays, maar die zijn relatief makkelijk te herkennen.

Ik denk dat de merit van deze post dan ook mag zijn: in theorie kan een LLM veel sneller een train of thought opbouwen die mogelijk zelfs langer/uitgebreider is dan een gemiddeld mens dat kan. In mijn ervaring is reverse engineeren de eerste uren vooral door een doolhof wandelen, kijken waar je clues op kan pikken, om vervolgens 1 voor 1 mysteries te ontdekken, met verbazing te kijken "waarom hebben ze dit 5x geimplementeerd?!" en telkens kleine puzzels op lossen zodat je bij de stukjes info kan komen die je zocht.

Dat creatieve stuk (bijvoorbeeld het architecturele/systeem plaatje uitzoeken) is een LLM wellicht niet zo handig in, maar de grind als: zit er een bug in deze code? Sja, als je weet naar welke patronen je op zoek bent, dan klinkt dat als gesneden koek... De "comments" waar dit artikel over heeft, lijkt ook gewoon puur een "read aloud" van de indviduele instructies te zijn. Het zijn allemaal cognitieve stappen die een LLM "automatisch" kan doen terwijl een mens er telkens een veelvoud aan tijd kwijt is.

Het grootste gevaar hierin zie ik dat LLMs nog de verkeerde conclusie kunnen maken, en daar vervolgens heel lang op door gaan borduren. Vooral als dit ook nog eens onontdekt gebeurd is dit bijzonder gevaarlijk. De "houd nu op met praten" knop in welke vorm van LLM software door mij de tweede knop die ik het meest gebruik (op plek 1 staat "bericht versturen" ), vooral bepaalde LLMs die graag nogal chatty zijn.

[Reactie gewijzigd door Hans1990 op 9 maart 2026 21:57]

[robvanwijk]

Dat is niet hoe debuginformatie werkt. Daarin zitten namen van functies en variabelen en referenties naar files en regelnummers, maar (voor zover ik weet) geen comments. Degene die de extra informatie gebruikt heeft meestal gewoon toegang tot de oorspronkelijke source code, dus het zou ook volkomen overbodig zijn om comments mee te compileren.

Zoals ik het artikel lees zijn de comments gegenereerd door de AI, niet teruggehaald uit de code. Het klinkt alsof ook de functienamen en variabelenamen van de AI komen:

de mogelijkheid om machinetaal te reverse-engineeren is 'schokkend'

Ik denk niet dat het "schokkend" is als AI erin slaagt om een goed-gedocumenteerd dataformaat te parsen. En het lijkt me onwaarschijnlijk dat dit puur over het herleiden van de structuur van de code gaat, want dat kan (ook al is het niet perfect) al jaren.

[yuckywucky]

Nee. Je gaat gewoon van machinecode naar leesbare assembly.
Decompileren is hier het foute woord, Eerder disassembleren.

Je weet honderd procent zeker dat de fout in je code zat.

[Olaf van der Spek]

Nee. Je gaat gewoon van machinecode naar leesbare assembly.

Je kunt dus ook naar leesbare C code..

[Noxious]

Niet echt. Sommige 'decompilers' zoals Ghidra geven wel een interpretatie van hoe het er waarschijnlijk uit ziet in C, maar dat is op basis van de assembly. In veel gevallen is dat een guesstimation op basis van herkenbare structuren en dat hoeft niet altijd accuraat te zijn.

[DdeM]

AI disassembleert noch decompiled, AI, of iig LLMs schrijven de code from scratch, dat is een beetje het punt. Dat staat overigens ook gewoon in de LinkedIn post, de code is gereconstrueerd, hij "begreep" de intentie van de code in de binary en heeft vervolgens code geschreven doe hetzelfde deed, maar dan mogelijk met bugs er in waar nergens wordt gezegd of deze óók in de originele binary zitten.

[Olaf van der Spek]

óók in de originele code zaten?

Je kunt controleren of de bugs in de binary zitten en dat is waar het echt om gaat. Als ze dan niet in de originele code zaten, zou dat een compiler bug kunnen zijn, maar dat is weer een apart issue.

[ErnstvV]

Uiteindelijk maakt het voor een kwetsbaarheid ook niet echt uit of het in de sourcecode ook aanwezig is. Wat de processor uit voert is de machinecode, als daar een kwetsbaarheid in zit, is dat het probleem.

[DdeM]

Dat kan inderdaad, maar als ik de LinkedIn post zo lees is salldat niet gedaan; iig niet op de originele binaries.

[pietje63]

dat kun je toch testen op de gecompileerde code?

[Blorgg]

Hoe weet hij zo zeker dat de kwetsbaarheden in de gedecompileerde "reverse-engineered" code óók in de originele code zaten?

Dit klinkt eerlijk gezegd meer als marketing om een beetje te verbloemen dat Claude verantwoordelijk lijkt te zijn voor de dood van 150 kinderen.

Exclusive: AI Error Likely Led to Girl’s School Bombing in Iran

"AI is slechts een tool" wordt er vaak gezegd.

[WargamingPlayer]

Gelukkig zijn mensen niet verantwoordelijk voor miljoenen doden, zowel volwassenen en kinderen. En gelukkig maken mensen ook geen fouten bij het bepalen van doelen.

[Honytawk]

Waarom zou Claude verantwoordelijk zijn en niet de personen die een Large-Language-Model hebben ingezet om raketten af te schieten?

[Blorgg]

Waarom zou Claude verantwoordelijk zijn en niet de personen die een Large-Language-Model hebben ingezet om raketten af te schieten?

Beide is natuurlijk waar.

De mensen die AI inzetten met dodelijke afloop voor burgers zijn verantwoordelijk. De AI die de lijst met doelwitten heeft samengesteld is ook verantwoordelijk.

Het is echt bizar hoe gemakkelijk mensen de verantwoordelijkheid van AI wegwuiven met: "het is maar een tool". AI is structureel defect. Het hallucineert constant en geeft daardoor foute antwoorden. In dit geval werden kinderen vermoord dankzij Claude's bijdrage. Mensen vertrouwen op AI die met absolute stelligheid uitspraken doet.

Dat is niet anders dan dat je erop vertrouwd dat je auto goede remmen heeft, het gaspedaal niet klemt en het stuur blijft werken. Wat doen we met een structureel onveilige auto, of een boormachine, of een magnetron, of oordopjes, of welk ander onveilig product dan ook? En waarom doen we dat niet met AI?

In dit geval ging het direct om mensenlevens. Hoeveel schade in algemene zin zijn we bereid te accepteren? AI wordt immers steeds meer ingezet om te helpen met het maken van allerlei beslissingen. Van heel groot als waar droppen we de bommen, tot heel klein als in wat eten we vandaag. Maar er zit overduidelijk geen enkele noemenswaardige beveiliging of controle op om schadelijke uitkomsten te voorkomen. En we mogen van veel mensen AI niet aansprakelijk stellen wanneer het weer mis gaat want: "AI is slechts een tool". Maar die mensen zitten fout. Een onveilige product haal je van de markt. Dat is hoe je daarmee omgaat.

[SunnieNL]

Zolang Claude niet zelf op de knop heeft gedrukt om die bom daar bovenop te gooien kan hij ook niet verantwoordelijk zijn. Er zit nog steeds een mens tussen, daarom is AI slechts een tool. Het is de mens die besluit iets te doen met het inzicht wat hij van de tool krijgt en of hij de informatie wilt dubbelchecken of niet.

[xorpd]

Ja tuurlijk, geef de AI maar de schuld.

"[...] the Iranian regime targets civilians and children, not the United States of America.”

Zo, dan heb je lef hoor. Gaslighting van de bovenste plank.

[Martinspire]

Niet heel raar. De bugs zijn gevonden in de tussentijd en dat is code waarop ze getraind zijn. Grote kans dat als er geen bug van is gemaakt, dat ook Claude niks gaat melden over code waar duidelijk nog bugs in zitten. Ze zijn geen analisten. Ze doen gewoonweg code herkennen waar ze op getraind zijn.

[bwerg]

Dan heb je weinig ervaring met deze toepassing, want Claude werkt prima om nog niet bekende bugs te vinden. Ik zie ook bug reports van de catagorie "volgens de naam van de functie moet die functie dit en dat valideren, maar hij vergeet een geval". Als je dat schaart onder de categorie "is hij op getraind" dan kun je dat ook wel extrapoleren naar menselijke developers die uiteindelijk ook maar getraind zijn op de miljoen regels code die ze intussen gezien hebben.

Zo'n AI vindt uiteraard niet alles, en niet alles wat die vindt is ook echt een bug, maar de ratio aan ruis versus daadwerkelijk nuttige bug-reports is goed genoeg om daadwerkelijk bruikbaar te zijn.

[Martinspire]

Dan nog is de bug die het vind niet iets nieuws maar gewoon een bij-effect die hij al vaker heeft gezien. Je moet niet onderschatten hoeveel code Claude e.d. te zien hebben gekregen voor de initiële modellen en hoeveel ze er vervolgens nog bij krijgen via eigen API's en de repo's die het nog online kan zien. Ze hebben vele terabytes aan regels code voorgeschoven gekregen. Daar zit echt wel ergens jouw bugs bij.

[bwerg]

Wat bedoel je met "jouw bug"? Exact die paar regels code, letter voor letter? Die kans lijkt me ongeveer 0. Extrapoleren en abstraheren doet hij toch echt.

Deze discussie doet me een beetje denken aan "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim": zodra een AI een miljoen regels code gebruikt om te leren is het "nep" en zodra een developer tien jaar code leest is die analytisch.

[Argantonis]

Nee dan onderschat je echt wat het kan. Ik zou er eerst eens ervaring mee opdoen voordat je zoiets zegt.

[Martinspire]

Ik werk er dagelijks mee, ik weet heus wel wat het wel en niet kan. Dit is niet een slimme AI. Het past gewoon regels en voorbeelden toe die het in het verleden heeft gezien.

[Argantonis]

Zoals een mens dus.

En uiteraard is het een ander soort ‘begrip’ dat een mens kan toepassen, maar zo uniek zijn bugs niet hoor. Dit is meer dan afdoende om een grote hoeveelheid bugs te vinden. Zelfs in complexe frameworks die meer zijn dan de code die het an sich kan lezen, zoals in Spring Boot. Een tool als Aikido heeft dit echt met veel nut toegepast.

[Martinspire]

Maar net als met nieuwe code, nieuwe frameworks en nieuwe versies die na migraties anders werken, kan AI daar veel minder goed mee om gaan en valt het altijd terug op dingen die het al weet.

Bugs vinden in oude code is iets waar het wel goed in is, maar bugs vinden in nieuwe code werkt gewoon een stuk minder goed. Het zal altijd informatie gevoed moeten worden over de programmeertaal waar het mee moet werken en voorbeelden van goede en foute code om te weten wat gebruikers van de AI verwacht. Als het nog geen informatie heeft over nieuwe talen en unieke code, dan gaat het daar echt geen bugs in vinden. Stel er komt een nieuwe taal genaamd E++ uit die anders werkt dan al het andere en je vraagt het daar bugs in te vinden, dan komt er toch veel false positives uit en kan het niet helemaal snappen wat de code doet (ook al zegt ie dat wel).

[Honytawk]

Claude is ook getrained op bugs van andere code.
En dat kan die toepassen op deze code.
Zo kan die wel degelijk nieuwe bugs vinden in deze code.

[Reactie gewijzigd door Honytawk op 10 maart 2026 10:22]

[Martinspire]

Ja maar de bugs zijn dus niet nieuw. Ze zijn elders al gevonden. En dat is ook mijn punt. Als over een paar jaar veel minder bugs gedeeld worden, dan zal AI ook minder nuttig worden.

[TwiekertBOB]

Ik vond het stukje van reverse engineeren van machinetaal en dat omzetten in code met begrijpelijke namen etc. wel iets dat heel mooi is.

Ik lees hier steeds mensen die laatdunkend doen over de prestaties van dit soort LLM's, maar ik vind het ergens nog steeds een beetje magisch dat we al zo ver zijn. En dit is natuurlijk nog steeds maar het begin van het traject. AI gaat ons nog zoveel meer brengen. tot het moment dat we het werkelijk AI kunnen noemen.

[onok]

Ik heb claude code ook al een keer losgelaten op een paar van mijn wat oudere projectjes. Ik was ook best onder de indruk waar die allemaal mee aan komt zetten. Niet alles klopt 100%, maar hij kan er toch echt dingen uithalen waar ik niet snel opgekomen was.

[gixslayer]

wat ik me dan wel afvraag is hoe de resultaten van Claude zich verhouden tot bestaande tooling zoals static analyzers en iets zoals Valgrind. Zijn er bugs die Claude wel vindt, maar de tools niet, of andersom? Hoe staat het met de false positives? Gebruikt Claude wellicht 'under the hood' niet gewoon dit soort tools?

Het laaghangend fruit zou dit soort tooling er redelijk betrouwbaar uit moeten kunnen halen. Wat ik me vooral afvraag is of iets als Claude ook complexe bugs kan vinden met een enigszins acceptabel false positive rate, zeker op grote en complexe code bases.

[Stoney3K]

Ik ben er toch terughoudend in om Claude los te laten op projecten van het werk, want je weet niet wat er met die data gebeurt. Het zou toch best lullig zijn als ik ineens onbedoeld een AI model ergens aan de andere kant van de wereld loop te trainen op onze bedrijfsgeheimen.

[RayNbow]

de mogelijkheid om machinetaal te reverse-engineeren is 'schokkend'.

Maar hoe schokkend is het daadwerkelijk? Als ik naar het oorspronkelijke artikel kijk, is het een BASIC-programma dat machine-instructies in het geheugen poket en een verwijzing naar deze code installeert op de ampersand-vector ($3F5). Als je een beetje rondzoekt kun je genoeg voorbeelden vinden op het internet (zowel sites als gescande boeken) die deze techniek beschrijven.

Wat wel een gemiste kans is, is dat bijv. het taalmodel met de volgende disassembly kwam:

LDA ($B8),Y ; A = token at TXTPTR

Mooier was geweest:

LDA (TXTPTR),Y

Dan was het commentaar overbodig geweest.

[MneoreJ]

Tja, maar hoe vaak schrijven programmeurs code met technieken die nergens beschreven zijn? En hoe lang duurt dat "beetje rondzoeken" voordat je zelf de kennis bij elkaar gesprokkeld hebt om te concluderen waar het over gaat?

Zodra we machinaal iets kunnen doen dat voorheen volstrekt onmogelijk machinaal te doen was mag je het wel schokkend noemen, vind ik. Het lijkt erop dat mensen nogal snel in de bagatelliseermodus springen en roepen "ja maar dat had een mens uiteindelijk ook wel gekund, hoor" of "kijk eens, ik heb hier toch nog wel een onvolkomenheid gevonden". Daar gaat het natuurlijk niet om, het gaat erom hoe makkelijk en snel het zonder die mens gaat.

[RayNbow]

En hoe lang duurt dat "beetje rondzoeken" voordat je zelf de kennis bij elkaar gesprokkeld hebt om te concluderen waar het over gaat?

Het rondzoeken was vooral om te kijken hoe verspreid de boel gedocumenteerd was. Verder heb je niet veel tijd nodig om uit te zoeken wat er gebeurt, de ampersand-vector ($03F5) staat beschreven in de Applesoft BASIC programmeerhandleiding.

Daar gaat het natuurlijk niet om, het gaat erom hoe makkelijk en snel het zonder die mens gaat.

Maar dan ook valt het mee wat het taalmodel hier gedaan heeft. Het disassembleren is niet de kunst, daar hebben we al disassemblers voor. De enige verdienste hier is het extra commentaar en beschrijvende uitleg die het model erbij doet, maar dat is nu ook niet echt nieuw te noemen? Dat doen de taalmodellen al een tijdje (met varierend succes, afhankelijk van hoe exotisch de code is; zo heeft bijv. ChatGPT nog steeds moeite om het buffergedrag in LASzip's ArithmeticEncoder correct uit te leggen).

[claudibunsen]

De definitie "kwetsbaarheden" voelt wel een beetje aan als "marketing fluff" imo.

Persoonlijk zou een kop als "ai vind bug in 40 jaar oude code" een stuk beter klinken.

Zoals ook de in-depth pdf onder de LinkedIn post zelf al uitlegt

[kuurtjes]

Wij van WC-eend


_{(Claude is beschikbaar via Github wat van Microsoft is)}

[dasiro]

De vraag is niet hoe indrukwekkend dit is, maar hoe relevant zulke oude code en de mogelijke exploits ervan nog zijn. In dat tijdperk was security van software die uitsluitend op lokale niet-geconnecteerde systemen draaide immers veel irrelevanter dan nu. Input validatition en garbage collection van je variabelen en memory (waar het in dit geval om gaat) waren eerder noodzakelijk omwille van hardware-beperkingen en "propere" code, omdat de taal waarin ze geschreven was met zulke scenario's geen rekening houdt.

[LiMy]

Nou… stel dat je een systeem hebt waar je bewust al dan niet onbewust in kan… dan is het nu ineens wel een heel stuk makkelijker om via dit soort audits de tekortkomingen te ontdekken om alsnog toegang te kunnen krijgen.

Irrelevant of het nu online of airgapped systemen zijn.

[Marctraider]

Het blijft een token predictor, geen intelligentie. Handig? Wellicht. Een fout zit in een klein hoekje, ook bij een 'AI' audit.

[Nystran]

Dit is vast waar, maar ook een keihard promo-praatje, zie "Claude en Microsoft werken samen" nieuwsbericht van vandaag op Tweakers:
nieuws: Microsoft voegt functionaliteit van Claude Cowork toe aan Copilot

[JakkoFourEyes]

Een moderne tool vind bugs in 40 jaar oude software. Dat klinkt niet zo heel verbazend. Had een andere (niet-LLM) tool dit ook kunnen vinden? Een statische analyse tool ofzo?