Sa loob ng ilang dekada, ang static application security testing (SAST) ay isa sa mga pinakaepektibong paraan para mapalawak ng mga security team ang code review.
Pero noong binuo namin ang Codex Security, may sadya kaming ginawa sa disenyo: hindi kami nagsimula sa pag-import ng static analysis report at paghiling sa agent na i-triage ito. Idinisenyo namin ang system para magsimula sa mismong repository—sa arkitektura nito, mga hangganan ng tiwala, at nilalayong pag-uugali—at para i-validate ang anumang makikita nito bago nito hilingin sa isang tao na maglaan ng oras dito.
Simple lang ang dahilan: kadalasan, hindi mga problema sa dataflow ang pinakamahihirap na kahinaan. Nangyayari ang mga ito kapag tila nagpapatupad ang code ng isang security check, pero hindi naman talaga ginagarantiyahan ng check na iyon ang property na inaasahan ng system. Sa madaling sabi, ang hamon ay hindi lang ang pagsubaybay kung paano gumagalaw ang data sa isang program—kundi ang pagtukoy kung talagang gumagana ang mga depensa sa code.
Madalas ilarawan ang SAST bilang isang malinis na pipeline: tukuyin ang pinagmumulan ng hindi mapagkakatiwalaang input, subaybayan ang data sa buong programa, at i-flag ang mga kaso kung saan ang data na iyon ay nakakarating sa isang sensitibong sink nang walang sanitization. Isa itong eleganteng modelo, at nasasaklaw nito ang maraming totoong bug.
Sa praktika, kailangang gumawa ang SAST ng mga pagtatantiya para manatiling madaling pamahalaan sa malaking saklaw—lalo na sa mga totoong codebase na may indirection, dynamic dispatch, mga callback, reflection, at control flow na puro framework. Ang mga pagtatantiyang iyon ay hindi batikos sa SAST; iyon ang realidad ng pagsubok na unawain ang code nang hindi ito isinasagawa.
Kung iyon lang mismo, hindi iyon ang dahilan kung bakit hindi nagsisimula ang Codex Security sa isang SAST report.
Ang mas malalim na isyu ay kung ano ang mangyayari pagkatapos mong matagumpay na ma-trace ang isang source patungo sa isang sink.
Kahit na wastong nate-trace ng static analysis ang input sa maraming function at layer, kailangan pa rin nitong sagutin ang tanong na talagang magpapasya kung may umiiral na kahinaan:
Isaalang-alang ang isang karaniwang pattern: tinawag ng code ang isang bagay tulad ng sanitize_html() bago mag-render ng hindi pinagkakatiwalaang content. Nakikita ng static analyzer na tumakbo ang sanitizer. Ang karaniwang hindi nito matukoy ay kung sapat ba talaga ang sanitizer na iyon para sa partikular na konteksto ng pag-render, template engine, gawi sa pag-encode, at mga downstream transformation na sangkot.
Dito nagiging mahirap ang mga bagay. Ang problema ay hindi lang kung umaabot ang data sa isang sink. Iyon ay kung talagang nalilimitahan ng mga check sa code ang value sa paraang inaakala ng system.
Sa ibang salita: may malaking pagkakaiba sa pagitan ng “tinawag ng code ang isang sanitizer” at “ligtas ang system.”
Narito ang isang pattern na palaging lumilitaw sa mga tunay na system.
Ang isang web application ay tatanggap ng JSON payload, mag-e-extract ng redirect_url, iva-validate ito kumpara sa isang allowlist regex, ide-decode ito ng URL, at ipapasa ang resulta sa isang redirect handler.
Mailalarawan ng isang klasikong source-to-sink na report ang flow:
hindi pinagkakatiwalaang input → regex check → URL decode → redirect
Pero ang tunay na tanong ay hindi kung umiiral ang check. Ito ay kung nalilimitahan pa rin ng check na iyon ang value pagkatapos ng mga kasunod na pagbabago.
Kung papatakbuhin ang regex bago mag-decode, talagang nililimitahan ba nito ang na-decode na URL sa paraan kung paano ito binibigyang-kahulugan ng redirect handler?
Ang pagsagot diyan ay nangangahulugang pangangatwiran tungkol sa buong transformation chain: kung ano ang pinahihintulutan ng regex, kung paano kumikilos ang decoding at normalization, kung paano itinuturing ng URL parsing ang mga edge case, at kung paano nireresolba ng redirect logic ang mga scheme at authority.
Marami sa mga kahinaang mahalaga sa pagsasagawa ay ganito ang hitsura: mga pagkakamali sa pagkakasunod-sunod ng mga operasyon, bahagyang pag-normalize, mga kalabuan sa pag-parse, at mga hindi pagtutugma sa validation at interpretasyon. Nakikita ang dataflow. Ang kahinaan ay nasa kung paano kumakalat ang mga limitasyon—o nabigong kumalat—sa buong transformation chain.
Hindi lang ito isang teoretikal na pattern. Sa CVE-2024-29041(magbubukas sa bagong window), naapektuhan ang Express ng isyu ng open redirect kung saan ang mga maling anyong URL ay puwedeng makalusot sa mga karaniwang implementasyon ng allowlist dahil sa kung paano na-encode ang mga redirect target at pagkatapos ay na-interpret. Direkta ang dataflow. Ang mas mahirap na tanong—at ang siyang nagpasya kung umiiral ang bug—ay kung nanatili ang validation pagkatapos ng transformation chain.
Ang Codex Security ay binuo sa isang simpleng layunin: bawasan ang triage sa pamamagitan ng pag-surface ng mga isyung may mas matitibay na ebidensya. Sa produkto, nangangahulugan iyon ng paggamit ng kontekstong partikular sa repo (kabilang ang modelo ng banta) at pag-validate ng mga high-signal na isyu sa isang isolated na kapaligiran bago i-surface ang mga ito.
Kapag nakatagpo ang Codex Security ng hangganang mukhang “validation” o “sanitization,” hindi nito iyon itinuturing bilang isang checkbox. Sinusubukan nitong unawain kung ano ang sinusubukang garantiyahan ng code—at pagkatapos ay sinusubukan nitong pabulaanan ang garantiyang iyon.
Sa aktwal na gawain, karaniwan itong nagmumukhang halo ng:
- Pagbabasa ng kaugnay na code path na may buong konteksto ng repository, tulad ng gagawin ng isang mananaliksik sa seguridad, at paghahanap ng mga hindi pagkakatugma sa layunin at pagpapatupad. Kasama rito ang mga komento, pero hindi naman kinakailangang pinaniniwalaan ng modelo ang mga komento kaya ang pagdaragdag ng //Halvar says: this is not a bug sa ibabaw ng code mo ay hindi nakakapagpalito rito, kung talagang may bug.
- Pagbawas ng problema sa pinakamaliit na nasusubok na hiwa (halimbawa, ang transformation pipeline sa paligid ng iisang input), para mapangatuwiranan mo ito nang hindi nakahahadlang ang iba pang bahagi ng sistema. Sa ganitong diwa, kumukuha ang Codex Security ng maliliit na hiwa ng code at pagkatapos ay nagsusulat ng mga micro-fuzzer para sa mga ito.
- Pangangatuwiran tungkol sa mga hadlang sa iba't ibang transpormasyon, sa halip na ituring ang bawat pagsusuri nang magkakahiwalay. Kung saan naaangkop, maaaring kabilang dito ang pormalisasyon bilang tanong ukol sa kasiyahan. Sa madaling salita, binibigyan namin ang modelo ng access sa Python environment na may z3-solver at mahusay ito sa paggamit nito kapag kinakailangan, tulad ng tao kapag sumasagot sa partikular na komplikadong problema sa input na may mga hadlang. Lalo itong kapaki-pakinabang para sa pagtingin sa mga pag-overflow ng integer o katulad na mga bug sa mga hindi pamantayang arkitektura.
- Pagpapatupad ng mga teorya sa naka-sandbox na environment ng pagpapatunay sa tuwing posible para maihiwalay ang “posibleng maging problema ito” mula sa “problema na ito”. Walang mas mahusay na patunay kaysa sa kumpletong PoC mula simula hanggang katapusan na may code na naka-compile sa debug mode.
Ito ang pangunahing pagbabago: sa halip na huminto sa “may umiiral na check,” tinutulak ng system patungo sa “nananatili ang invariant (o hindi), at narito ang ebidensya.” At pinipili ng modelo ang pinakamahusay na tool para sa trabahong iyon.
Isang makatuwirang reaksyon: bakit hindi gawin ang pareho? Magsimula sa ulat ng SAST, pagkatapos ay gamitin ang agent para mag-isip nang mas malalim.
May mga kaso kung saan nakakatulong ang mga precomputed na finding—lalo na para sa makikitid at kilalang klase ng mga bug. Ngunit para sa agent na dinisenyo upang matuklasan at mapatunayan ang mga kahinaan sa konteksto, ang pagsisimula mula sa ulat ng SAST ay lumilikha ng tatlong inaasahang mode ng pagkabigo.
Una, maaari nitong hikayatin ang maagang pagpapaliit ng saklaw. Ang listahan ng mga natuklasan ay isang mapa kung saan tumingin na ang isang tool. Kung ituturing mo itong panimulang punto, maaari mong i-bias ang sistema na maglaan ng hindi proporsyonal na pagsisikap sa parehong mga rehiyon, gamit ang parehong abstraksyon, at paglimot sa mga uri ng isyu na hindi akma sa pananaw ng tool.
Ikalawa, maaari itong magpakilala ng mga di-tahasang paghatol na mahirap iwasto. Maraming mga nadiskubre sa SAST ang nag-e-encode ng mga palagay sa pag-sanitize, pagpapatunay, o mga hangganan ng tiwala. Kung mali ang mga palagay na iyon—o hindi lang kumpleto—ang pagdaragdag ng mga ito sa loop ng pangangatuwiran ay maaaring makapagpalipat sa agent mula sa “magsiyasat” patungo sa “kumpirmahin o ibasura,” at hindi iyon ang gusto naming gawin ng agent.
Pangatlo, maaari nitong pahirapan ang pagsusuri sa sistema ng pangangatuwiran. Kung nagsisimula ang pipeline sa SAST output, nagiging mahirap ang paghihiwalay sa kung ano ang natuklasan ng agent sa sarili nitong pagsusuri at kung ano ang minana nito mula sa ibang tool. Mahalaga ang paghihiwalay na iyon kung gusto ninyong masukat nang tumpak ang mga kakayahan ng sistema, na kinakailangan upang humusay ang sistema sa pagdaan ng panahon.
Kaya binuo namin ang Codex Security para magsimula sa kung saan nagsisimula ang pananaliksik sa seguridad: mula sa code at layunin ng sistema, gamit ang pagpapatunay para itaas ang antas ng kumpiyansa bago namin abalahin ang tao.
Maaaring maging napakahusay ng SAST tool sa kung para saan dinisenyo ang mga ito: pagpapatupad ng mga ligtas na pamantayan sa pag-code, pagkuha ng mga tuwiran at source-to-sink na isyu, at pagtukoy ng mga kilalang pattern sa malakihang saklaw na may mahuhulaang kapalit. Maaari silang maging matatg na bahagi ng malalimang depensa.
Mas makitid ang pokus ng post na ito: tungkol ito sa kung bakit ang agent na dinisenyong mangatuwiran tungkol sa pagkilos at magpatunay ng mga natuklasan ay hindi dapat magsimula ng trabaho nito na nakaangkla sa static na listahan ng mga nadiskubre.
Karapat-dapat ding banggitin ang kaugnay na limitasyon ng purong source-to-sink na pag-iisip: hindi lahat ng kahinaan ay problema sa dataflow. Marami sa totoong pagkabigo ay mga problema sa estado at invariant—mga pag-iwas sa daloy ng trabaho, mga puwang sa awtorisasyon, at mga bug na “nasa maling estado ang system”. Para sa mga ganitong uri ng bug, ang nadungisang value ay hindi umaabot sa kahit isang “dangerous sink.” Ang panganib ay nasa kung ano ang ipinapalagay ng programa na palaging magiging totoo.
Inaasahan naming patuloy na mapapabuti ang ecosystem ng tooling ng seguridad: magkakaroon ng kani-kaniyang papel ang static analysis, fuzzing, runtime guards, at mga agentic na daloy ng trabaho.
Gusto naming maging mahusay ang Codex Security sa bahaging may pinakamalaking gastos para sa mga team ng seguridad: gawing “mukhang kahina-hinala ito” na “totoo ito, narito kung paano ito pumapalya, at narito ang pag-aayos na tumutugma sa layunin ng sistema.”
Kung gusto mong madagdagan ang nalalaman tungkol sa kung paano iniinspeksyon ng Codex Security ang mga repository, sinusuri ang mga natuklasan, at nagmumungkahi ng mga pag-aayos, tingnan ang aming dokumentasyon(magbubukas sa bagong window).
