Miksi Codex-tietoturva ei sisällä SAST-raporttia

Vuosikymmenten ajan staattinen sovellustietoturvatestaus (SAST) on ollut yksi tehokkaimmista tavoista, joilla tietoturvatiimit voivat laajentaa koodin tarkastusta. 

Mutta kun kehitimme Codex Securityn, teimme tietoisen suunnitteluratkaisun: emme aloittaneet tuomalla järjestelmään staattista analyysiraporttia ja pyytämällä agenttia luokittelemaan sen. Suunnittelimme järjestelmän alkamaan itse repositoriosta – sen arkkitehtuurista, luottamusrajoista ja tarkoitetusta toiminnasta – ja validoimaan löytämänsä ennen kuin se pyytää ihmistä käyttämään siihen aikaa. 

Syy on yksinkertainen: kaikkein vaikeimmat haavoittuvuudet eivät yleensä ole tietovuon ongelmia. Niitä esiintyy, kun koodi vaikuttaa pakottavan tietoturvatarkistuksen, mutta kyseinen tarkistus ei todellisuudessa takaa ominaisuutta, johon järjestelmä nojaa. Toisin sanoen haasteena ei ole pelkästään seurata, miten data liikkuu ohjelman läpi, vaan selvittää, toimivatko koodin suojaukset todella.

SAST esitetään usein selkeänä prosessina: tunnista epäluotettavan syötteen lähde, seuraa dataa ohjelman läpi ja merkitse tapaukset, joissa data päätyy arkaluonteiseen kohteeseen ilman puhdistusta. Se on tyylikäs malli, ja se kattaa monia todellisia virheitä.

Käytännössä SAST:n on tehtävä likimääräisiä arvioita pysyäkseen skaalautuvana – erityisesti oikeissa koodikannoissa, joissa on epäsuoria viittauksia, dynaamista kutsunvälitystä, takaisinkutsuja, reflektiota ja kehyspainotteista ohjausvirtaa. Nämä arvioinnit eivät ole kritiikkiä SAST:ta kohtaan; ne ovat todellisuutta, kun yritetään analysoida koodia suorittamatta sitä.

Se ei itsessään ole syy siihen, miksi Codex-tietoturva ei ala SAST-raportilla.

Syvällisempi kysymys on, mitä tapahtuu sen jälkeen, kun lähde on onnistuttu jäljittämään kohteeseen.

Vaikka staattinen analyysi jäljittäisi syötteen oikein useiden funktioiden ja kerrosten läpi, sen on silti vastattava kysymykseen, joka itse asiassa ratkaisee sen, onko haavoittuvuus olemassa:

Otetaan yleinen malli: koodi kutsuu esimerkiksi sanitize_html() ennen epäluotettavan sisällön renderöintiä. Staattinen analysoija näkee, että puhdistusohjelma suoritettiin. Se, mitä se yleensä ei pysty määrittämään, on se, onko tuo puhdistusohjelma todella riittävä kyseiseen renderöintikontekstiin, mallipohjamoottoriin, koodauskäyttäytymiseen ja mukana oleviin jatkokäsittelyn muunnoksiin nähden.

Siinä kohtaa asiat käyvät hankaliksi. Ongelma ei ole pelkästään siinä, saavuttaako data kohteen. Kyse on siitä, rajoittavatko koodin tarkistukset todellisuudessa arvoa sillä tavalla kuin järjestelmä olettaa niiden rajoittavan.

Toisin sanoen: ”koodi kutsuu puhdistusohjelmaa” ja ”järjestelmä on turvallinen”välillä on merkittävä ero.

Tässä on malli, joka esiintyy todellisissa järjestelmissä koko ajan.

Verkkosovellus vastaanottaa JSON-hyötykuorman, poimii redirect_url-kentän, validoi sen sallittujen luettelon regex-lauseketta vasten, URL-purkaa sen ja välittää tuloksen edelleen uudelleenohjauksen käsittelijälle.

Perinteinen lähde-kohde-raportti voi kuvata tiedon kulun:

epäluotettava syöte → regex-tarkistus → URL:n dekoodaus → uudelleenohjaus

Mutta varsinainen kysymys ei ole, onko tarkistus olemassa. Kyse on siitä, rajoittaako tarkistus edelleen arvoa sitä seuraavien muunnosten jälkeen.

Jos regex suoritetaan ennen dekoodausta, rajoittaako se todella dekoodatun URL-osoitteen siten kuin uudelleenohjauskäsittelijä tulkitsee sen?

Tähän vastaaminen tarkoittaa päättelyä koko muunnosketjun osalta: mitä regex sallii, miten dekoodaus ja normalisointi toimivat, miten URL-jäsennys käsittelee reunatapauksia ja miten uudelleenohjauslogiikka ratkaisee skeemat ja auktoriteetit.

Monet käytännössä merkitykselliset haavoittuvuudet näyttävät tältä: toimintajärjestysvirheet, osittainen normalisointi, jäsentämisen monitulkintaisuudet sekä validoinnin ja tulkinnan väliset ristiriidat. Tietovirta on näkyvissä. Heikkous on siinä, miten rajoitteet etenevät – tai eivät etene – muunnosketjun läpi.

Tämä ei ole vain teoreettinen malli. CVE-2024-29041⁠(avautuu uudessa ikkunassa)-tapauksessa Expressiin vaikutti avoimen uudelleenohjauksen haavoittuvuus, jossa virheellisesti muotoillut URL-osoitteet saattoivat ohittaa yleiset sallittujen kohteiden luettelon (allowlist) toteutukset, koska uudelleenohjauskohteet koodattiin ja tulkittiin tietyllä tavalla. Tietovirta oli yksinkertainen. Vaikeampi kysymys, joka ratkaisi, oliko bugia olemassa, oli se, pitikö validointi edelleen paikkansa muunnosketjun jälkeen.

Codex Security on rakennettu yksinkertaisen tavoitteen ympärille: vähentää luokittelutyötä tuomalla esiin ongelmia vahvemman näytön avulla. Tuotteessa tämä tarkoittaa koodivarastokohtaisen kontekstin (mukaan lukien uhkamalli) käyttöä ja vahvan signaalin ongelmien validointia eristetyssä ympäristössä ennen niiden esiin tuomista. 

Kun Codex-tietoturva kohtaa rajan, joka näyttää ”validoinnilta” tai ”puhdistukselta,” se ei pidä sitä pelkkänä rastitettavana valintaruutuna. Se yrittää ymmärtää, mitä koodi pyrkii takaamaan – ja sitten se yrittää kumota tämän takuun.

Käytännössä se on yleensä sekoitus seuraavia:

• Luetaan asiaankuuluva koodipolku täydellisessä repositorion kontekstissa samalla tavalla kuin tietoturvatutkija ja etsitään ristiriitoja tarkoituksen ja toteutuksen välillä. Tämä sisältää kommentteja, mutta malli ei välttämättä usko niihin, joten lisäämällä //Halvar sanoo: tämä ei ole bugi -merkinnän lisääminen koodisi yläpuolelle ei aiheuta sekaannusta, jos kyseessä todella on bugi.
• Ongelman rajaaminen pienimpään testattavissa olevaan osaan (esimerkiksi yhden syötteen ympärillä oleva muunnosprosessi), jotta voit miettiä sitä ilman, että muu järjestelmä on tiellä. Tässä mielessä Codex-tietoturva poimii pieniä koodisiivuja ja kirjoittaa niille sitten mikro-fuzzereita.
• Rajoitusten tarkastelu muunnoksien välillä sen sijaan, että kutakin tarkistusta käsiteltäisiin erikseen. Tarvittaessa tähän voi kuulua muotoilu tyydyttävyyskysymyksenä. Toisin sanoen annamme mallille pääsyn Python-ympäristöön, jossa on z3-solver, ja malli osaa hyödyntää sitä tarvittaessa, aivan kuten ihminenkin joutuisi tekemään vastatessaan erityisen monimutkaiseen syöttörajoiteongelmaan. Tämä on erityisen hyödyllistä, kun tarkastellaan kokonaisluvun ylivuotoja tai vastaavia virheitä epätyypillisillä arkkitehtuureilla.
• Suorittamalla hypoteeseja mahdollisuuksien mukaan eristetyissä validointiympäristöissä, jotta voidaan erottaa “tämä voisi olla ongelma” ja “tämä on ongelma”. Mikään ei ole parempi todiste kuin täysin alusta loppuun tehty PoC, jossa koodi on käännetty virheenkorjaustilassa. 

Tämä on keskeinen muutos: sen sijaan, että pysähdytään kohtaan ”tarkistus on olemassa”, järjestelmä ohjaa kohti ”invariantti pätee (tai ei päde), ja tässä on todisteet”. Ja malli valitsee siihen tehtävään parhaiten sopivan työkalun.

Luonteva reaktio on: miksi et tekisi molempia? Aloita SAST-raportilla ja käytä sitten agenttia syvällisempään päättelyyn.

On tilanteita, joissa esilasketut löydökset ovat hyödyllisiä – erityisesti kapeissa ja tunnetuissa virheluokissa. Mutta agentille, joka on suunniteltu löytämään ja validoimaan haavoittuvuuksia kontekstissaan, SAST-raportista aloittaminen luo kolme ennustettavaa vikatilannetta.

Ensinnäkin se voi kannustaa ennenaikaiseen rajaamiseen Löydösluettelo on kartta siitä, missä työkalu on jo etsinyt Jos pidät sitä lähtökohtana, saatat saada järjestelmän keskittymään suhteettoman paljon samoihin alueisiin, käyttämään samoja abstraktioita ja jättämään huomiotta ongelmaluokat, jotka eivät sovi työkalun maailmankuvaan.

Toiseksi se voi tuoda mukanaan epäsuoria arvioita, joita on vaikea purkaa. Monet SAST-löydökset koodaavat oletuksia puhdistuksesta, validoinnista tai luottamusrajoista. Jos nämä oletukset ovat väärin – tai vain puutteellisia – niiden syöttäminen päättelysilmukkaan voi siirtää agentin tilasta ”tutki” tilaan ”vahvista tai hylkää”, mikä ei ole se, mitä haluamme agentin tekevän.

Kolmanneksi se voi vaikeuttaa päättelyjärjestelmän arvioimista. Jos prosessi alkaa SAST-tulosteesta, on vaikea erottaa, mitä agentti havaitsi oman analyysinsä kautta siitä, mitä se peri toiselta työkalulta. Tuo erottelu on tärkeää, jos haluat mitata järjestelmän kyvykkyyksiä tarkasti, mikä on tarpeen, jotta järjestelmä voi parantua ajan myötä.

Siksi rakensimme Codex Securityn aloittamaan siitä, mistä tietoturvatutkimus alkaa: koodista ja järjestelmän tarkoituksesta, ja käytämme validointia nostaaksemme luottamuksen rimaa ennen kuin keskeytämme ihmisen.

SAST-työkalut voivat olla erinomaisia siinä, mihin ne on suunniteltu: turvallisten koodausstandardien noudattamisen varmistamisessa, yksinkertaisten lähde-kohde-ongelmien havaitsemisessa sekä tunnettujen mallien havaitsemisessa laajamittaisesti ennustettavin kompromissein. Ne voivat olla vahva osa kerroksellista puolustusta.

Tämä julkaisu on rajatumpi: siinä käsitellään, miksi käyttäytymistä koskevaan päättelyyn ja löydösten vahvistamiseen suunnitellun agentin ei tulisi aloittaa työtään ankkuroituneena staattiseen löydösluetteloon.

On myös syytä tuoda esiin puhdasta lähde-kohde-ajattelutapaa koskeva rajoitus: kaikki haavoittuvuudet eivät ole tietovirtaongelmia. Monet todelliset epäonnistumiset ovat tila- ja invarianttiongelmia – työnkulun ohituksia, valtuutusaukkoja ja ”järjestelmä on väärässä tilassa” -bugeja. Tämän tyyppisissä bugeissa saastunut arvo ei päädy yhteenkään ”vaaralliseen kohteeseen”. Riski piilee siinä, mitä ohjelma olettaa olevan aina totta. 

Odotamme, että tietoturvatyökalujen ekosysteemi kehittyy edelleen: staattinen analyysi, fuzz-testaus, ajonaikaiset suojaukset ja agenttiset työnkulut tulevat kaikki olemaan osana kokonaisuutta.

Se, missä haluamme Codex Securityn olevan hyvä, on se osa, joka maksaa tietoturvatiimeille eniten: muuttaa ”tämä vaikuttaa epäilyttävältä” muotoon ”tämä on todellista, näin se pettää, ja tässä on korjaus, joka vastaa järjestelmän tarkoitusta.” 

Jos haluat oppia lisää siitä, miten Codex Security skannaa repositorioita, validoi löydökset ja ehdottaa korjauksia, tutustu dokumentaatioomme⁠(avautuu uudessa ikkunassa).