Pse Codex Security nuk përfshin një raport SAST

Për dekada, testimi statik i sigurisë së aplikacioneve (SAST) ka qenë një nga mënyrat më efektive që ekipet e sigurisë të rrisin shkallën e shqyrtimit të kodit. 

Por kur ndërtuam Codex Security, bëmë një zgjedhje të qëllimshme të dizajnit: nuk filluam duke importuar një raport të analizës statike dhe duke i kërkuar agjentit ta shqyrtonte atë. Ne e projektuam sistemin që të fillojë me vetë depo — arkitekturën e saj, kufijtë e besimit dhe sjelljen e synuar — dhe të vërtetojë atë që gjen përpara se t’i kërkojë një njeriu të shpenzojë kohë për të. 

Arsyeja është e thjeshtë: dobësitë më të vështira zakonisht nuk janë probleme të fluksit të të dhënave. Ato ndodhin kur kodi duket se zbaton një kontroll sigurie, por ai kontroll në fakt nuk garanton vetinë te e cila mbështetet sistemi. Me fjalë të tjera, sfida nuk është thjesht të gjurmosh se si lëvizin të dhënat nëpër një program — është të përcaktohet nëse mbrojtjet në kod funksionojnë vërtet.

SAST shpesh paraqitet si një proces i pastër: identifiko një burim të inputit të pabesueshëm, ndiq të dhënat nëpër program dhe shëno rastet kur ato të dhëna arrijnë te një “sink” i ndjeshëm pa sanitizim. Është një model elegant, dhe mbulon shumë probleme reale.

Në praktikë, SAST duhet të bëjë përafrime për të mbetur i zbatueshëm në përshkallëzim — sidomos në baza reale të kodit me indireksion, shpërndarje dinamike, thirrje të kthimit, reflektim dhe fluks kontrolli të ngarkuar me korniza. Ato përafrime nuk janë një kritikë ndaj SAST; ato janë realiteti i përpjekjes për të arsyetuar mbi kodin pa e ekzekutuar atë.

Kjo, më vete, nuk është arsyeja pse Codex Security nuk fillon me një raport SAST.

Çështja më e thellë është se çfarë ndodh pasi të gjurmoni me sukses një burim deri te një pikë përfundimtare.

Edhe kur analiza statike ndjek saktë hyrjen përmes funksioneve dhe shtresave të shumta, ajo ende duhet t'i përgjigjet pyetjes që përcakton nëse ekziston një dobësi:

Merrni një motiv të zakonshëm: kodi thërret diçka si sanitize_html() përpara se të shfaqë përmbajtje të pasigurt. Një analizues statik mund të shohë se sanitizuesi u ekzekutua. Ajo që zakonisht nuk mund të përcaktojë është nëse ai sanitizues është vërtet i mjaftueshëm për kontekstin specifik të shfaqjes, motorin e shablloneve, sjelljen e kodimit dhe transformimet pasuese të përfshira.

Aty gjërat bëhen të vështira. Problemi nuk është vetëm nëse të dhënat arrijnë në një destinacion. Bëhet fjalë për faktin nëse kontrollet në kod kufizojnë vlerën ashtu siç sistemi supozon.

Me fjalë të tjera: ekziston një ndryshim i madh midis “kodi përdor një sanitizues” dhe “sistemi është i sigurt.”

Ja një motiv që shfaqet shpesh në sisteme reale.

Një aplikacion uebi merr një ngarkesë JSON, nxjerr një redirect_url, e kontrollon atë me një shprehje të rregullt të listës së lejuar, e dekodon URL-n dhe më pas rezultatin ia kalon një trajtuesi të ridrejtimit.

Një raport klasik burim-sink mund të përshkruajë rrjedhën:

hyrje e pasigurt → kontroll regex → dekodim URL → ridrejtim

Por pyetja e vërtetë nuk është nëse ekziston kontrolli. Është nëse ai kontroll ende kufizon vlerën pas transformimeve që pasojnë.

Nëse regex ekzekutohet para dekodimit, a e kufizon vërtet URL e dekoduar ashtu siç e interpreton mbajtësi i ridrejtimit?

T’i përgjigjesh kësaj do të thotë të bësh arsyetim për të gjithë zinxhirin e transformimit: çfarë lejon regex-i, si funksionojnë dekodimi dhe normalizimi, si i trajton analizimi i URL rastet kufitare dhe si i zgjidh logjika e ridrejtimit skemat dhe autoritetet.

Shumë nga dobësitë që kanë rëndësi në praktikë duken kështu: gabime në rendin e veprimeve, normalizim i pjesshëm, paqartësi në analizimin sintaksor dhe mospërputhje midis validimit dhe interpretimit. Fluksi i të dhënave është i dukshëm. Dobësia është te mënyra se si kufizimet përhapen — ose dështojnë të përhapen — përmes zinxhirit të transformimit.

Ky nuk është vetëm një model teorik. Në CVE-2024-29041⁠(hapet në një dritare të re), Express u prek nga një problem ridrejtimi i hapur ku URL e keqformuara mund të anashkalonin implementimet e zakonshme të listës së lejimit për shkak të mënyrës se si kodoheshin dhe interpretoheshin objektivat e ridrejtimit. Fluksi i të dhënave ishte i thjeshtë. Pyetja më e vështirë — dhe ajo që përcaktoi nëse ekzistonte gabimi — ishte nëse validimi vazhdonte të ishte i vlefshëm pas zinxhirit të transformimeve.

Codex Security është ndërtuar rreth një qëllimi të thjeshtë: të reduktojë triazhin duke nxjerrë në pah problemet me prova më të forta. Në produkt, kjo do të thotë përdorimi i kontekstit specifik për depon (duke përfshirë një model kërcënimi) dhe verifikimi i çështjeve me sinjal të lartë në një mjedis të izoluar përpara se t’i bëjë të dukshme. 

Kur Codex Security ndesh një kufi që duket si “verifikim” ose “sanitizim,” nuk e trajton atë si një kutizë zgjedhjeje. Ai përpiqet të kuptojë se çfarë po përpiqet të garantojë kodi — dhe pastaj përpiqet ta rrëzojë atë garanci.

Në praktikë, kjo priret të duket si një përzierje e:

• Duke lexuar shtegun përkatës të kodit me kontekst të plotë të depos, ashtu siç do të bënte një studiues sigurie, dhe duke kërkuar për mospërputhje midis qëllimit dhe zbatimit. Kjo përfshin komente, por modeli nuk u beson domosdoshmërisht komenteve, kështu që shtimi //Halvar thotë: ky nuk përbën gabim sipër kodit tuaj nuk e ngatërron, nëse vërtet ka një gabim.
• Duke e reduktuar problemin në segmentin më të vogël të testueshëm (p.sh. linjën e transformimit rreth një inputi të vetëm), në mënyrë që të mund të arsyetoni për të pa pjesën tjetër të sistemit që të pengojë. Në këtë kuptim, Codex Security nxjerr copa të vogla kodi dhe pastaj shkruan micro-fuzzers për to.
• Arsyetimi rreth kufizimeve përgjatë transformimeve, në vend që çdo kontroll të trajtohet më vete. Kur është e përshtatshme, kjo mund të përfshijë formalizimin si një problem përmbushjeje (SAT). Me fjalë të tjera, ne i japim modelit akses në një mjedis Python me z3-solver dhe ai e përdor mirë kur nevojitet, njësoj siç do t’i duhej edhe një njeriu kur i përgjigjet një problemi veçanërisht të ndërlikuar me kufizime të hyrjes. Kjo është veçanërisht e dobishme për të analizuar tejkalimet (overflows) e numrave të plotë ose gabime të ngjashme në arkitektura jo standarde.
• Kur është e mundur, ekzekutimi i hipotezave në një mjedis verifikimi të izoluar dhe të kufizuar, për të dalluar “ky mund të jetë problem” nga “ky është problem”. Nuk ka provë më të mirë se një PoC i plotë nga fillimi në fund me kodin e kompiluar në modalitet debugimi. 

Ky është ndryshimi kyç: në vend që të ndalet te “ekziston një kontroll,” sistemi shtyn drejt “invarianti vlen (ose jo) dhe ja provat.” Dhe modeli zgjedh mjetin më të mirë për atë detyrë.

Një reagim i arsyeshëm është: pse të mos i bëjmë të dyja? Filloni me një raport SAST, pastaj përdorni agjentin për të arsyetuar më thellë.

Ka raste kur gjetjet e parapërllogaritura janë të dobishme, veçanërisht për klasa të ngushta dhe të njohura të gabimeve. Por për një agjent të projektuar për të zbuluar dhe validuar mangësi teknike në kontekst, nisja nga një raport SAST krijon tri mënyra të parashikueshme të dështimit.

Së pari, mund të inkurajojë ngushtimin e parakohshëm. Një listë gjetjesh është një hartë se ku një mjet tashmë ka kërkuar. Nëse e trajton si pikënisje, mund ta anësosh sistemin që të shpenzojë përpjekje joproporcionale në të njëjtat zona, duke përdorur të njëjtat abstraksione, dhe duke humbur klasa problemesh që nuk përputhen me botëkuptimin e mjetit.

Së dyti, mund të sjellë gjykime të nënkuptuara që janë të vështira për t'u zhbërë. Shumë gjetje SAST përmbajnë supozime për sanitizimin, validimin ose kufijtë e besimit. Nëse ato supozime janë të gabuara — ose thjesht të paplota — futja e tyre në ciklin e arsyetimit mund ta zhvendosë agjentin nga “heto” te “konfirmo ose hidhe poshtë,” gjë që nuk është ajo që duam që agjenti të bëjë.

Së treti, kjo mund ta bëjë më të vështirë vlerësimin e sistemit të arsyetimit. Nëse linja fillon me rezultatet e SAST, bëhet e vështirë të dallosh atë që agjenti zbuloi përmes analizës së vet nga ajo që trashëgoi nga një mjet tjetër. Ajo ndarje është e rëndësishme nëse dëshironi të matni me saktësi aftësitë e sistemit, gjë që nevojitet për përmirësimin e tij me kalimin e kohës.

Kështu ndërtuam Codex Security që të fillojë aty ku fillon kërkimi i sigurisë: nga kodi dhe synimi i sistemit, me validim të përdorur për të ngritur nivelin e besimit para se të ndërpresim një njeri.

Mjetet SAST mund të jenë të shkëlqyera në atë për të cilën janë krijuar: zbatimin e standardeve të kodimit të sigurt, kapjen e problemeve të drejtpërdrejta nga burimi te destinacioni dhe zbulimin e modeleve të njohura në shkallë të gjerë me kompromise të parashikueshme. Ato mund të jenë një pjesë e fortë e mbrojtjes në thellësi.

Ky postim është më i ngushtë: shpjegon pse një agjent i projektuar për të arsyetuar mbi sjelljen dhe për të verifikuar gjetjet nuk duhet ta nisë punën e tij i ankoruar te një listë statike gjetjesh.

Vlen gjithashtu të theksohet një kufizim i lidhur i të menduarit thjesht burim-sink: jo çdo dobësi është një problem i rrjedhës së të dhënave. Shumë dështime reale janë probleme të gjendjes dhe të invarianteve — anashkalime të flukseve të punës, boshllëqe në autorizim dhe defekte “sistemi është në gjendjen e gabuar”. Për këto lloje defektesh, një vlerë e kontaminuar nuk arrin në një të vetëm “sink të rrezikshëm.” Rreziku qëndron në atë që programi supozon se do të jetë gjithmonë e vërtetë. 

Ne presim që ekosistemi i mjeteve të sigurisë të vazhdojë të përmirësohet: analiza statike, fuzzing, mbrojtje në kohë ekzekutimi dhe procese pune me agjentë do të kenë të gjitha rol.

Ajo që duam që Codex Security të bëjë më mirë është pjesa që u kushton më shumë ekipeve të sigurisë: të shndërrojë “kjo duket e dyshimtë” në “kjo është reale, ja si dështon dhe ja një rregullim që përputhet me qëllimin e sistemit.” 

Nëse dëshironi të mësoni më shumë rreth mënyrës se si Codex Security skanon depot, vërteton gjetjet dhe propozon rregullime, shikoni dokumentacionin tonë⁠(hapet në një dritare të re).