Kāpēc Codex Security neietver SAST ziņojumu

Jau gadu desmitiem statiskā lietojumprogrammu drošības testēšana (SAST) ir bijusi viens no efektīvākajiem veidiem, kā drošības komandas paplašina koda pārskatīšanu. 

Taču, veidojot Codex Security, mēs izdarījām apzinātu projektēšanas izvēli – mēs nesākām ar statiskās analīzes ziņojuma importēšanu un neprasījām aģentam to pārbaudīt. Mēs izstrādājām sistēmu tā, lai tā sāktu ar pašu repozitoriju – tā arhitektūru, uzticamības robežām un paredzēto uzvedību – un validētu atrastos rezultātus, pirms prasa cilvēkam tam veltīt laiku.

Iemesls ir vienkāršs: visgrūtākās ievainojamības parasti nav datu plūsmas problēmas. Tās rodas, kad kods šķietami nodrošina drošības pārbaudi, taču šī pārbaude patiesībā negarantē īpašību, uz kuru sistēma paļaujas. Citiem vārdiem sakot, izaicinājums nav tikai izsekot, kā dati plūst caur programmu, bet gan noteikt, vai kodā esošie aizsardzības mehānismi patiešām darbojas.

SAST bieži tiek attēlots kā tīrs process: identificēt neuzticamas ievades avotu, izsekot datus caur programmu un atzīmēt gadījumus, kad tie bez sanitizācijas nonāk pie sensitīva uztvērēja. Tas ir elegants modelis, kas aptver daudzas reālas kļūdas.

Praksē SAST ir jāveic aptuvinājumi, lai saglabātu pārvaldāmību mērogā – jo īpaši reālās kodu bāzēs ar netiešām atsaucēm, dinamisku maršrutēšanu, atzvanēm, refleksiju un ietvarstruktūru balstītu vadības plūsmu. Šie aptuvinājumi nav pārmetums SAST; tā ir realitāte, mēģinot analizēt kodu, to neizpildot.

Tas pats par sevi nav iemesls, kāpēc Codex Security nesāk ar SAST pārskatu.

Dziļākā problēma ir tas, kas notiek pēc tam, kad avots veiksmīgi izsekots līdz uztvērējam.

Pat tad, ja statiskā analīze pareizi izseko ievadi vairākās funkcijās un slāņos, tai joprojām jāatbild uz jautājumu, kas patiesībā nosaka, vai ievainojamība pastāv:

Ņemsim izplatītu modeli: kods pirms neuzticama satura renderēšanas izsauc kaut ko līdzīgu sanitize_html().. Statiskās analīzes rīks var konstatēt, ka sanitizācijas funkcija tika izsaukta. Taču tas parasti nespēj noteikt, vai šī funkcija ir pietiekama konkrētajam renderēšanas kontekstam, veidņu dzinējam, kodēšanas uzvedībai un turpmākajām transformācijām.

Te nu viss kļūst sarežģīti. Problēma nav tikai tajā, vai dati sasniedz uztvērēju. Jautājums ir, vai kodā esošās pārbaudes patiešām ierobežo vērtību tā, kā sistēma pieņem.

Citiem vārdiem sakot: pastāv liela atšķirība starp "kods izsauc sanitizatoru" un "sistēma ir droša."

Šāds modelis reālās sistēmās parādās pastāvīgi.

Tīmekļa lietojumprogramma saņem JSON datu kopu, iegūst redirect_url, pārbauda to pret atļauto vērtību saraksta regulāro izteiksmi, dekodē URL un nodod rezultātu pāradresācijas apstrādātājam.

Klasiska avota–uztvērēja atskaite var aprakstīt plūsmu:

neuzticams ievades avots → regex pārbaude → URL dekodēšana → pāradresācija

Bet patiesais jautājums nav par to, vai šī pārbaude pastāv. Tas ir par to, vai šī pārbaude pēc turpmākajām transformācijām joprojām ierobežo vērtību.

Ja regulārā izteiksme tiek palaista pirms dekodēšanas, vai tā patiešām ierobežo dekodēto URL tā, kā to interpretē pāradresācijas apstrādātājs?

Atbildēt uz to nozīmē analizēt visu transformāciju ķēdi: ko regulārā izteiksme atļauj, kā darbojas dekodēšana un normalizācija, kā URL parsētājs apstrādā robežgadījumus un kā pāradresācijas loģika atrisina shēmas un autoritātes.

Lielākā daļa praktiski nozīmīgo ievainojamību izskatās tieši šādi: darbību secības kļūdas, daļēja normalizācija, parsēšanas neskaidrības un neatbilstības starp validāciju un interpretāciju. Datu plūsma ir redzama. Vājā vieta ir tajā, kā ierobežojumi izplatās – vai neizplatās – caur transformāciju ķēdi.

Tas nav tikai teorētisks paraugs. CVE-2024-29041⁠(atveras jaunā logā) gadījumā Express skāra atvērtās pāradresācijas ievainojamība, kurā nepareizi veidoti URL varēja apiet parastas atļauto sarakstu implementācijas atkarībā no tā, kā pāradresācijas mērķi tika kodēti un pēc tam interpretēti. Datu plūsma bija vienkārša. Grūtāks jautājums – un tas, kas noteica, vai kļūda pastāv – bija, vai validācija joprojām ir spēkā pēc transformāciju ķēdes.

Codex Security ir veidots ap vienkāršu mērķi: samazināt atradumu kārtošanas slogu, izceļot problēmas ar spēcīgākiem pierādījumiem. Produktā tas nozīmē izmantot repozitorijam specifisku kontekstu (tostarp draudu modeli) un validēt augsta signāla problēmas izolētā vidē, pirms tās tiek izceltas. 

Kad Codex Security saskaras ar robežu, kas izskatās kā "validācija" vai "sanitizācija", tas to neuztver kā atzīmi sarakstā. Tas mēģina saprast, kādu garantiju kods cenšas nodrošināt – un pēc tam mēģina šo garantiju falsificēt.

Praksē tas parasti izskatās kā dažādu elementu kombinācija:

• Attiecīgā koda ceļa lasīšana ar pilnu repozitorija kontekstu – tāpat kā to darītu drošības pētnieks – un neatbilstību meklēšana starp nolūku un ieviešanu. Tas ietver komentārus, taču modelis komentāriem automātiski netic, tāpēc pievienojot //Halvar says: this is not a bug virs koda, modelis netiek maldināts, ja kļūda patiešām pastāv.
• Problēmas sašaurināšana līdz mazākajam pārbaudāmajam griezumam (piemēram, transformāciju konveijeram ap vienu ievadi), lai jūs varētu par to spriest, netraucējot pārējai sistēmai. Šajā ziņā Codex Security izvelk sīkas koda šķēles un tām raksta mikrofazerus.
• Spriestspēja par ierobežojumiem dažādās transformācijās, nevis katras pārbaudes atsevišķa izskatīšana. Ja tas ir piemēroti, tas var ietvert formalizāciju kā apmierināmības jautājumu. Citiem vārdiem sakot, modelim tiek nodrošināta piekļuve Python videi ar z3-solver, un tas to labi izmanto, kad vajadzīgs – tāpat kā cilvēkam nāktos to darīt, atbildot uz sevišķi sarežģītu ievades ierobežojumu uzdevumu. Tas ir īpaši noderīgi veselu skaitļu pārpildes un līdzīgu kļūdu analīzē nestandarta arhitektūrā.
• Ja iespējams, hipotēžu pārbaude izolētā validācijas vidē, lai nošķirtu "tā varētu būt problēma" no "tā ir problēma". Nav labāka pierādījuma par pilnu end-to-end PoC ar kodu, kas kompilēts atkļūdošanas režīmā. 

Šī ir galvenā pārmaiņa: tā vietā, lai apstātos pie "pārbaude pastāv", sistēma virzās uz "invariants ir spēkā (vai nav), un šeit ir pierādījumi". Un modelis izvēlas piemērotāko rīku šim uzdevumam.

Saprotama reakcija būtu: kāpēc gan nedarīt abus? Sākt ar SAST pārskatu, tad izmantot aģentu padziļinātai analīzei.

Ir gadījumi, kad iepriekš aprēķināti atradumi ir noderīgi – jo īpaši šaurām, zināmām kļūdu klasēm. Taču aģentam, kas paredzēts ievainojamību atklāšanai un validēšanai kontekstā, sākšana no SAST pārskata rada trīs paredzamus kļūmes režīmus.

Pirmkārt, tas var veicināt priekšlaicīgu sašaurināšanu. Atradumu saraksts ir karte, kurā norādīts, kur rīks jau ir skatījies. Uztverot to kā sākumpunktu, var ievirzīt sistēmu nesamērīgi lielā uzmanībā tiem pašiem apgabaliem, izmantojot tās pašas abstrakcijas, un palaist garām kļūdu klases, kas neiekļaujas rīka skatījumā.

Otrkārt, tas var ieviest netiešus spriedumus, kurus ir grūti atšķetināt. Daudzi SAST atradumi satur pieņēmumus par sanitizāciju, validāciju vai uzticamības robežām. Ja šie pieņēmumi ir nepareizi vai nepilnīgi, to ievadīšana analīzes ciklā var novirzīt aģentu no "izmeklēt" uz "apstiprināt vai noraidīt" – kas nav tas, ko mēs no aģenta vēlamies.

Treškārt, tas var apgrūtināt spriešanas sistēmas novērtēšanu. Ja process sākas ar SAST izvadi, kļūst grūti nošķirt to, ko aģents atklāja pats savā analīzē, no tā, ko tas pārņēma no cita rīka. Šī nošķiršana ir svarīga, lai precīzi novērtētu sistēmas spējas – kas savukārt ir nepieciešams, lai sistēma laika gaitā uzlabotos.

Tāpēc mēs veidojām Codex Security tā, lai tas sāktu tur, kur sākas drošības izpēte: no koda un sistēmas nolūka, izmantojot validāciju, lai paaugstinātu pārliecības latiņu, pirms iesaistām cilvēku.

SAST rīki var būt izcili tajā, kam tie paredzēti: drošas programmēšanas standartu ievērošanas nodrošināšanā, vienkāršu avots–uztvērējs problēmu atklāšanā un zināmu paraugu identificēšanā mērogā ar paredzamiem kompromisiem. Tie var būt spēcīgs padziļinātas drošības aizsardzības elements.

Šī ziņa ir šaurāka: tā ir par to, kāpēc aģentam, kas paredzēts, lai spriestu par uzvedību un apstiprinātu secinājumus, nevajadzētu sākt darbu, pamatojoties uz statisku secinājumu sarakstu.

Vērts izcelt arī saistītu tīras avots–uztvērējs domāšanas ierobežojumu: ne katra ievainojamība ir datu plūsmas problēma. Daudzas reālas kļūmes ir stāvokļa un invariantu problēmas – darbplūsmas apiešana, autorizācijas nepilnības un kļūdas "sistēma ir nepareizā stāvoklī". Šādos kļūdu tipos piesārņotā vērtība nenonāk pie viena "bīstama uztvērēja". Risks ir tajā, ko programma pieņem par vienmēr patiesu. 

Mēs gaidām, ka drošības rīku ekosistēma turpinās attīstīties: statiskajai analīzei, fazingam, izpildlaika aizsardzības mehānismiem un aģentiskajām darbplūsmām visām būs sava loma.

Tas, ko mēs vēlamies no Codex Security, ir labi veikt to daļu, kas drošības komandām izmaksā visvairāk: pārvērst "tas izskatās aizdomīgi" par "tas ir reāli – lūk, kā tas nedarbojas, un lūk labojums, kas atbilst sistēmas nolūkam." 

Ja vēlies uzzināt vairāk par to, kā Codex Security skenē repozitorijus, validē konstatējumus un ierosina labojumus, skati mūsu dokumentāciju⁠(atveras jaunā logā).