Koodaajan tyyli paljastaa haavoittuvuuksia – mutta siinä on iso mutta

Jokaisella kehittäjällä on oma tapansa kirjoittaa koodia. Toiset sommittavat koodirakenteet millintarkasti. Toiset pitävät muuttujanimet lyhyinä ja ytimekkäinä. Joku uppoutuu syviin silmukkarakenteisiin, toinen hajottaa kaiken apufunktioihin. Nämä pienet tavat kertautuvat tuhansilla riveillä ja muodostavat uniikin jäljen, vähän kuin käsinkirjoitettu teksti.

UMass Dartmouthin tutkijat pohtivat kiehtovaa asiaa: Voiko näitä tyylipiirteitä hyödyntää haavoittuvuuksien löytämiseen ennen kuin koodi menee tuotantoon?

Riskin salattu kieli

Ajatus on nerokas. Jos kehittäjä sortuu huonoihin tapoihin – löyhään puskurinhallintaan, epätasaiseen osoitinten käsittelyyn tai sekaviin nimikäytäntöihin – ne toistuvat koko koodikannassa. Vaaralliset kuviot eivät ilmesty satunnaisesti, vaan ne ovat osa pysyvää tyyliä.

Tähän syntyi VulStyle, koneoppimismalli, joka näkee koodityylin turvasignaalina. Sen sijaan että se vain etsisi tuttuja vaarallisia komentoja tai API-kutsuja, se poimii tyylillisiä piirteitä: muuttujien julistustavat, lausekkeiden rakenteet, ehtolauseiden ja silmukoiden kuviot. Malli yhdistää tämän perinteiseen rakenteanalyysiin ja syntaksitietoihin.

Alustavat testit lupasivat paljon. Useilla haavoittuvuustesteillä tyylitietoinen malli päihitti pelkän syntaksin ja tokenien varassa toimivat versiot. Tutkijat toteavat, että rakenne kertoo mitä koodi tekee, tyyli taas kuinka kehittäjä sen toteuttaa. Yhdessä ne antavat tarkemman riskikuvan.

Vertailutesteissä iso ongelma

Sitten tuli pettymys.

VulStyle loistaa tietyillä dataseteillä, mutta kompastuu pahasti toisilla. DiverseVul-benchmarkissa, joka korjaa vanhojen testien virheitä, tulokset romahtavat. Itse tutkijat myöntävät, että monissa suosituissa testeissä on sotkuisia merkintöjä, jotka nostavat tuloksia keinotekoisesti.

Ongelma ei rajoitu VulStyleen. Koneoppimisen turvatutkimuksessa toistuu sama: malli rokkaa laboratoriossa, mutta pettää oikeassa maailmassa. Syynä ei ole malli, vaan testidatsetit – niiden rakentaminen, treenidata ja sen yhteys tuotantoon.

Turvajoukoille viesti on selvä: lukemat paperilla eivät takaa mitään.

AI-koodin nousu muuttaa pelin

Syvempi haaste koskee meitä koodaajia vuonna 2024.

VulStylen logiikka nojaa siihen, että kehittäjällä on tunnistettava tyyli. Mutta yhä useampi rivi koodia syntyy LLM-malleista: GitHub Copilot, ChatGPT, Claude. Tällainen koodi on:

• Tasaisen muotoiltua (ei henkilökohtaisia oikkuja)
• Syntaktisesti turvallista (ei erikoisia rakenteita)
• Ilman yksilöllisiä tapoja (tarkoituksella)

Kun koodi tulee koneelta, tyylijälki katoaa. Analysoitavaa sormenjälkeä ei ole.

Tutkijat tunnustavat rajan, mutta se on iso juttu: LLM-avusteinen kehitys syö tyylin turva-arvon nopeasti.

Haastajatuntemattomia kysymyksiä

Tutkijat väittävät, että tyylipohjainen havainnointi on vaikea kiertää – hyökkääjän pitäisi muuttaa useita signaaleja yhtä aikaa. Kuulostaa vakuuttavalta, mutta sitä ei testattu.

Entä jos pahantahtoinen kehittäjä ajaa koodinsa formatointiohjelmalla, vaihtaa nimet ja muokkaa rakenteita? Selviääkö tyylisignaali? Tätä ei tiedetä. Tutkimusaihe odottaa.

Mitä tämä tarkoittaa sun infraasi

VulStyle on vasta prototyyppi, et lataa sitä käyttöön. Silti idea puree: tyyli, rakenne ja sisällöt yhdessä parantavat bugien löytöä tietyissä tapauksissa.

Käytännön neuvot ovat varovaisempia:

1. Älä usko yhteen testiin – 95 % tarkkuus? Kysy datasettistä. Testaa omalla koodillasi.

2. Tiedosta datasettien vinouma – Suosikit eivät välttämättä kuvaa sun koodikantaa tai oikeita riskejä.

3. Valmistaudu AI-koodiin – Copilotin myötä tyylitarkistus heikkenee. Tarvitset muita keinoja.

4. Odota signaalin heikkenemistä – Kehittäjätapoihin nojaavat menetelmät kärsivät AI:n tasoittaessa eroja.

Tie eteenpäin

Haavoittuvuustutkimus kehittyy kovaa vauhtia, mutta se pakottaa kohtaamaan ikäviä faktoja. Yksittäiset piirteet eivät yleisty. Testit hämäävät. Ja koodin kirjoitustapa muuttuu koko ajan.

Paras suoja on monikerroksinen: staattinen analyysi, dynaamiset testit, koodiarvostelut, toimitusketjun tarkistus ja runtime-valvonta. Yksikään signaali – ei tyyli, ei syntaksi, ei rakenne – ei riitä yksin.

Kun ymmärrät, miksi signaalit toimivat, missä ne pettävät ja kuinka ne täydentävät toisiaan, rakennat kestävää turvaa.