💻 computer science

Residual Risk Analysis in Benign Code: How Far Are We? A Multi-Model Semantic and Structural Similarity Approach

Deze studie introduceert Residual Risk Scoring (RRS), een kader dat semantische en structurele code-kenmerken combineert om aan te tonen dat ongeveer 61% van de zogenaamd 'gepatchte' functies nog steeds kwetsbaarheden bevat, wat een nieuwe methode biedt voor het prioriteren van beveiligingscontroles na het aanbrengen van patches.

Oorspronkelijke auteurs: Mohammad Farhad, Shuvalaxmi Dass

Gepubliceerd 2026-04-24

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Mohammad Farhad, Shuvalaxmi Dass

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

🛠️ De "Schijnveilige" Patches: Een Onderzoek naar Verborgen Risico's

Stel je voor dat je een oude, lekke auto hebt. Je brengt hem naar de garage, en de monteur plakt een nieuwe band op de plek waar de lekke zat. De auto rijdt weer, en de lekke is weg. Je denkt: "Perfect, de auto is veilig!"

Maar wat als de monteur alleen de band heeft vervangen, maar de rest van de auto (de remmen, de motor, de slijtage) nog precies hetzelfde is als toen hij nog leegliep? Misschien is er een verborgen probleem dat de monteur niet zag, of dat hij bewust heeft laten zitten omdat hij alleen de lekke wilde repareren. De auto lijkt veilig, maar er sluimeren nog steeds risico's.

Dit is precies wat deze wetenschappers onderzochten in software.

1. Het Probleem: De "Kleine Prik"

In de digitale wereld worden softwarefouten (vulnerabilities) vaak "gepatcht". Een ontwikkelaar ziet een fout, maakt een kleine aanpassing in de code en denkt dat het probleem opgelost is.

De aanname: Zodra er een patch is, is de code "veilig" (benign).
De realiteit: Vaak is de patch zo klein en gericht, dat de code er na de reparatie nog steeds heel erg op lijkt als de oude, gebrekkige versie.

De auteurs noemen dit Restrisico (Residual Risk). Het is het gevaar dat overblijft, zelfs nadat je denkt dat je het probleem hebt opgelost.

2. De Oplossing: Een Drie-Lagen Detectie

De onderzoekers (Mohammad Farhad en Shuvalaxmi Dass) hebben een nieuwe manier bedacht om te meten hoe "veilig" een gepatchte code echt is. Ze noemen hun methode RRS (Residual Risk Scoring).

Stel je voor dat ze een code niet alleen met het blote oog bekijken, maar met drie verschillende soorten "brillen":

De Semantische Brillen (De Betekenis):
Ze gebruiken slimme AI-modellen (zoals CodeBERT) die de betekenis van de code begrijpen. Het is alsof je twee verhalen leest en vraagt: "Vertellen deze twee verhalen hetzelfde verhaal, of is er een groot verschil?"
- Vergelijking: Als je een zin verandert van "Ik heb een appel gegeten" naar "Ik at een appel", is de betekenis bijna hetzelfde. De AI ziet dit als een hoge gelijkenis.
De Structurele Brillen (De Bouw):
Ze kijken ook naar de opbouw van de code (de "Abstract Syntax Tree" of AST). Dit is als kijken naar het skelet van de auto.
- Het probleem: Als je alleen naar het hele skelet kijkt, zie je misschien dat 99% hetzelfde is. Maar wat als er op één klein botje een barst zit?
- De oplossing: Ze kijken specifiek naar de lokale veranderingen. Ze zoomen in op het stukje waar de patch is aangebracht, in plaats van de hele auto te vergelijken.
De AI-Consensus (De Meningsvorming):
Ze gebruiken niet één, maar vijf verschillende AI-modellen. Als al deze verschillende "experts" het erover eens zijn dat de oude en nieuwe code bijna identiek zijn, dan is dat een sterk signaal.
- Vergelijking: Als vijf verschillende detectives zeggen: "Deze verdachte is bijna identiek aan de dader van gisteren", dan moet je toch even op je hoede zijn.

3. Wat Vonden Ze? (De Schokkende Resultaten)

Toen ze duizenden voorbeelden van "gepatchte" code analyseerden, zagen ze iets opvallends:

De code blijft bijna hetzelfde: In veel gevallen is de gepatchte code semantisch en structuren 99% identiek aan de oude, kwetsbare code. De ontwikkelaars hebben vaak alleen een heel klein stukje aangepast (zoals het toevoegen van een controle), maar de rest van de logica is onveranderd gebleven.
Het "Valse Veiligheidsgevoel": Omdat de code zo op elkaar lijkt, denken veel systemen dat het probleem volledig opgelost is.
De Verborgen Gaten: Toen ze de "veiligste" code (die hoge scores had op hun Risico-Score) lieten controleren door geavanceerde veiligheidstools, vonden ze dat 61% van deze code nog steeds gevaarlijke fouten had!
- Denk aan: geheugenlekken, fouten met nul-pointer (waar de software probeert iets te doen dat niet bestaat), of onveilige geheugenallocatie.

4. Waarom is dit belangrijk?

Vroeger dachten we: "Als er een patch is, is het veilig."
Deze studie zegt: "Nee, wacht even. Soms is de patch zo klein, dat de code nog steeds de 'geest' van de oude fout draagt."

De grote les:
Het is als het schilderen van een muur waar een muurspeld in zit. Je schildert eroverheen, en de muur ziet er mooi uit. Maar als je er hard op duwt, breekt de muurspeld er nog steeds doorheen. Je moet niet alleen kijken of de muur mooi is (de patch), maar ook of de onderliggende structuur nog steeds kwetsbaar is.

5. Conclusie in Eén Zin

De onderzoekers hebben een nieuwe "risicometer" bedacht die helpt om te zien welke softwarepatches misschien te oppervlakkig zijn, zodat ontwikkelaars die specifieke stukjes code extra goed kunnen controleren voordat ze ze in de echte wereld gebruiken.

Het is een waarschuwing: Soms is "veilig" alleen maar een schijnveiligheid, en moeten we dieper graven dan alleen de oppervlakkige veranderingen.

Probleemstelling

Softwarebeveiliging vertrouwt op het detecteren en patchen van kwetsbaarheden. Echter, een cruciale maar vaak over het hoofd geziene uitdaging is het bepalen of een patch het risico volledig elimineert. Bestaande benchmarks behandelen gepatchte (benigne) functies vaak als van nature veilig, zonder rekening te houden met residuele risico's.

In de praktijk zijn patches vaak minimaal en lokaal gericht om functionaliteit te behouden en bijwerkingen te voorkomen. Hierdoor behouden benigne functies vaak belangrijke semantische en structurele kenmerken van de oorspronkelijke kwetsbare implementatie. Deze "representatieve continuïteit" betekent dat een code-patch correct kan zijn voor de specifieke fout, maar dat het onderliggende risico (bijv. onveilig geheugenbeheer of null-pointer dereferenties) kan blijven bestaan. Bestaande methoden (zoals traditionele SAST-tools of puur semantische modellen) zijn vaak niet in staat om deze subtiele, maar kritieke, persistentie van risico's na het patchen te kwantificeren.

Methodologie

De auteurs stellen een nieuwe aanpak voor genaamd Residual Risk Scoring (RRS). Dit is een unificerend framework dat de gelijkenis tussen een kwetsbare functie ( $f_v$ ) en een benigne (gepatchte) functie ( $f_b$ ) analyseert via drie pijlers:

Semantische Similariteit (Embedding-based):
- Er worden meerdere vooraf getrainde Code Language Models (Code LMs) gebruikt, waaronder encoder-modellen (CodeBERT, UniXCoder, GraphCodeBERT) en encoder-decoder-modellen (CodeT5-base, CodeT5-770M).
- De functies worden omgezet in dichte vectoren (embeddings).
- De semantische gelijkenis wordt gemeten via Cosine Similarity. De auteurs tonen aan dat deze metric robuuster is dan andere afstandsmaten (zoals Euclidische afstand) voor het vastleggen van functionele equivalentie.
Structurele Similariteit (AST-based):
- Om fijne structurele veranderingen te vangen, wordt gebruik gemaakt van Abstract Syntax Trees (AST) gegenereerd door Tree-sitter.
- In plaats van een globale Tree Edit Distance (TED) te gebruiken (die vaak te streng is omdat hij de hele boom vergelijkt), focussen de auteurs op Localized TED Similarity (LTS).
- LTS isoleert de gemodificeerde subbomen die direct corresponderen met de patch. Dit geeft een nauwkeuriger beeld van de daadwerkelijke wijzigingen zonder de onveranderde delen van de code te laten "verwateren" in de meting.
Cross-Model Overeenstemming:
- Om de betrouwbaarheid van de semantische meting te versterken, wordt de variantie tussen de scores van verschillende modellen berekend.
- Een lage variantie (hoge overeenstemming) tussen modellen suggereert dat de semantische gelijkenis robuust is en niet slechts een artefact van één specifiek model.

De RRS-score:
De uiteindelijke score wordt berekend als een gewogen som van deze drie signalen:
$RRS = \alpha \cdot \bar{S}_{sem} + \beta \cdot R_{struct} + \gamma \cdot C_{agree}$
Waarbij $\bar{S}_{sem}$ de gemiddelde semantische gelijkenis is, $R_{struct}$ de structurele gelijkenis (LTS), en $C_{agree}$ de overeenstemmingsscore tussen modellen. Een hoge RRS-score duidt op een hoog residueel risico: de code is semantisch en structureel zeer vergelijkbaar met de kwetsbare versie, wat suggereert dat de patch mogelijk onvoldoende diepgaand is.

Belangrijkste Bijdragen

Formalisatie van Residueel Risico: Dit is het eerste werk dat residueel risico formeel definieert als de representatieve nabijheid (semantisch en structureel) tussen kwetsbare en benigne code.
RRS Framework: Introductie van een unificerend score-systeem dat embedding-gebaseerde semantiek, gelokaliseerde AST-analyse en cross-model consensus combineert.
Validatie met Static Analysis: Empirische validatie waarbij hoog-risico functies (hoge RRS) worden getest met state-of-the-art static analysis tools (Cppcheck, Clang-Tidy, Facebook Infer) om te bewijzen dat hoge gelijkenis correleert met detecteerbare beveiligingsproblemen.
Inzicht in Patch-gedrag: Het aantonen dat globale AST-metrics (zoals NTED) de werkelijke impact van patches kunnen overschatten of onderschatten, en dat gelokaliseerde analyse essentieel is.

Resultaten

De studie is uitgevoerd op het PrimeVul dataset, bestaande uit 3.789 paren van kwetsbare en benigne C/C++-functies.

Hoge Gelijkenis: De analyse toont aan dat benigne functies extreem sterk lijken op hun kwetsbare tegenhangers. De gemiddelde cosine similarity ligt vaak tussen 0,97 en 0,99, en de structurele gelijkenis (LTS) is gemiddeld 0,82 (met een mediaan van 0,93). Dit bevestigt dat patches vaak zeer lokaal zijn.
Risicokwadranten: De auteurs partitioneren de data in vier kwadranten. Het kritieke kwadrant (Hoog Semantisch + Hoog Structureel) bevat ongeveer 29,5% van de paren. Deze functies ondergingen minimale veranderingen en vormen de beste kandidaten voor residueel risico.
Validatie met Static Tools: Van de functies met een hoge RRS-score (uit het kritieke kwadrant) werd ongeveer 61% gemarkeerd door ten minste één static analysis tool als bevattende beveiligingskwesties.
- 43% werd door twee tools gemarkeerd.
- 27% werd door alle drie de tools (Cppcheck, Clang-Tidy, Infer) gemarkeerd.
- De geïdentificeerde problemen omvatten 13 categorieën, waaronder null-pointer dereferenties, onbeveiligd geheugenbeheer, ongedefinieerd gedrag en bufferoverlopen.
Robuustheid: Sensitiviteitsanalyses tonen aan dat de rangschikking van risico's stabiel blijft, ongeacht de specifieke gewichten ( $\alpha, \beta, \gamma$ ) die aan de componenten worden gegeven.

Betekenis en Conclusie

De studie concludeert dat de aanname dat gepatchte code van nature veilig is, gevaarlijk kan zijn. De hoge semantische en structurele gelijkenis tussen kwetsbare en benigne code is een praktisch signaal dat niet automatisch betekent dat het risico is weggenomen.

Prioritering: De RRS-methode biedt een schaalbaar mechanisme om post-patch inspectie te prioriteren. In plaats van alle gepatchte code te controleren, kunnen teams zich richten op functies met een hoge RRS-score, waar de kans op residuele kwetsbaarheden het grootst is.
Complementaire Analyse: Het paper benadrukt dat semantische modellen en structurele analyse complementair zijn; alleen semantische gelijkenis kan structurele nuances missen, en alleen structurele analyse kan functionele equivalentie missen.
Toekomst: Dit werk opent de weg voor representatiebewuste analyse in softwarebeveiliging, wat kan leiden tot betrouwbaardere kwetsbaarheidstriage en betere validatie van automatische patches.

Kortom, de auteurs tonen aan dat we nog ver moeten komen voordat we kunnen garanderen dat een patch het risico volledig elimineert, en dat het meten van "hoeveel de code is veranderd" (of juist niet) een cruciale indicator is voor resterende beveiligingsrisico's.